https://RustRocket.rs -- Cloud Monk Losang Jinpa, Ph.D., MCSE / MCT, https://Rustaceans.rs, Full Stack Cloud Native Rust DevOps Engineer - Rocket Framework Rust Microservices on Kubernetes-AWS-Azure-GCP

(D) /slang/ “Slicing off a small amount from each transaction. This kind of theft was made worthwhile by automation. Given a high transaction flow, even rounding down to the nearest cent and putting the 'extra' in a bogus account can be very profitable.” [NCSSG]

Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated Usage under “Green Book”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

salt

(I) A data value used to vary the results of a computation in a security mechanism, so that an exposed computational result from one instance of applying the mechanism cannot be reused by an attacker in another instance. (Compare: initialization value.)

Example: A password-based access control mechanism might protect against capture or accidental disclosure of its password file by applying a one-way encryption algorithm to passwords before storing them in the file. To increase the difficulty of off-line, dictionary attacks that match encrypted values of potential passwords against a copy of the password file, the mechanism can concatenate each password with its own random salt value before applying the one-way function.

([[Fair Use]] [[Source]]: [[RFC 4949])

SAML

(N) See: Security Assertion Markup Language (SAML).

([[Fair Use]] [[Source]]: [[RFC 4949])

sandbox

(I) A restricted, controlled execution environment that prevents potentially malicious software, such as mobile code, from accessing any system resources except those for which the software is authorized.

Shirey Informational Page 258]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

sanitize

1. (I) Delete sensitive data from a file, device, or system. (See: erase, zeroize.)

2. (I) Modify data so as to be able either (a) to completely declassify it or (b) to downgrade it to a lower security level.

([[Fair Use]] [[Source]]: [[RFC 4949])

SAP

(O) See: special access program.

([[Fair Use]] [[Source]]: [[RFC 4949])

SASL

(I) See: Simple Authentication and Security Layer.

([[Fair Use]] [[Source]]: [[RFC 4949])

SCA

(I) See: subordinate certification authority.

([[Fair Use]] [[Source]]: [[RFC 4949])

scavenging

(I) /threat action/ See: secondary definition under “exposure”.

([[Fair Use]] [[Source]]: [[RFC 4949])

SCI

(O) See: sensitive compartmented information.

([[Fair Use]] [[Source]]: [[RFC 4949])

SCIF

(O) See: sensitive compartmented information facility.

([[Fair Use]] [[Source]]: [[RFC 4949])

SCOMP

(N) Secure COMmunications Processor; an enhanced, MLS version of the Honeywell Level 6 minicomputer. It was the first system to be rated in TCSEC Class A1. (See: KSOS.)

([[Fair Use]] [[Source]]: [[RFC 4949])

screen room

(D) /slang/ Synonym for “shielded enclosure” in the context of electromagnetic emanations. (See: EMSEC, TEMPEST.)

Deprecated Term: To avoid international misunderstanding, IDOCs SHOULD NOT use this term.

([[Fair Use]] [[Source]]: [[RFC 4949])

screening router

(I) Synonym for “filtering router”.

([[Fair Use]] [[Source]]: [[RFC 4949])

script kiddy

(D) /slang/ A cracker who is able to use existing attack techniques (i.e., to read scripts) and execute existing attack software, but is unable to invent new exploits or manufacture the tools to perform them; pejoratively, an immature or novice cracker.

Shirey Informational Page 259]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated Usage under “Green Book”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

SDE

(N) See: Secure Data Exchange.

([[Fair Use]] [[Source]]: [[RFC 4949])

SDNS

(O) See: Secure Data Network System.

([[Fair Use]] [[Source]]: [[RFC 4949])

SDU

(N) See: “service data unit” under “protocol data unit”.

([[Fair Use]] [[Source]]: [[RFC 4949])

seal

1. (I) To use asymmetric cryptography to encrypt plain text with a public key in such a way that only the holder of the matching private key can learn what was the plain text. [Chau] (Compare: shroud, wrap.)

Deprecated Usage: An IDOC SHOULD NOT use this term with definition 1 unless the IDOC includes the definition, because the definition is not widely known and the concept can be expressed by using other, standard terms. Instead, use “salt and encrypt” or other terminology that is specific with regard to the mechanism being used.

Tutorial: The definition does *not* say “only the holder of the matching private key can decrypt the cipher text to learn what was the plain text”; sealing is stronger than that. If Alice simply encrypts a plain text P with a public key K to produce cipher text C = K(P), then if Bob guesses that P = X, Bob could verify the guess by checking whether K(P) = K(X). To “seal” P and block Bob's guessing attack, Alice could attach a long string R of random bits to P before encrypting to produce C = K(P,R); if Bob guesses that P = X, Bob can only test the guess by also guessing R. (See: salt.)

2. (D) To use cryptography to provide data integrity service for a data object. (See: sign.)

Deprecated Definition: IDOCs SHOULD NOT use this term with definition 2. Instead, use a term that is more specific with regard to the mechanism used to provide the data integrity service; e.g., use “sign” when the mechanism is digital signature.

Shirey Informational Page 260]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

secret

1a. (I) /adjective/ The condition of information being protected from being known by any system entities except those that are intended to know it. (See: data confidentiality.)

1b. (I) /noun/ An item of information that is protected thusly.

Usage: This term applies to symmetric keys, private keys, and passwords.

([[Fair Use]] [[Source]]: [[RFC 4949])

secret key

(D) A key that is kept secret or needs to be kept secret.

Deprecated Term: IDOCs SHOULD NOT use this term; it mixes concepts in a potentially misleading way. In the context of asymmetric cryptography, IDOCs SHOULD use “private key”. In the context of symmetric cryptography, the adjective “secret” is unnecessary because all keys must be kept secret.

([[Fair Use]] [[Source]]: [[RFC 4949])

secret-key cryptography

(D) Synonym for “symmetric cryptography”.

Deprecated Term: IDOCs SHOULD NOT use this term; it could be confused with “asymmetric cryptography”, in which the private key is kept secret.

Derivation: Symmetric cryptography is sometimes called “secret-key cryptography” because entities that share the key, such as the originator and the recipient of a message, need to keep the key secret from other entities.

([[Fair Use]] [[Source]]: [[RFC 4949])

Secure BGP (S-BGP)

(I) A project of BBN Technologies, sponsored by the U.S. DoD's Defense Advanced Research Projects Agency, to design and demonstrate an architecture to secure the Border Gateway Protocol (RFC 1771) and to promote deployment of that architecture in the Internet.

Tutorial: S-BGP incorporates three security mechanisms: - A PKI supports authentication of ownership of IP address blocks, autonomous system (AS) numbers, an AS's id[[entity, and a BGP router's id[[entity and its authorization to represent an AS. This PKI parallels and takes advantage of the Internet's existing IP address and AS number assignment system. - A new, optional, BGP transitive path attribute carries digital signatures (in “attestations”) covering the routing information in a BGP UPDATE. These signatures along with certificates from the S-BGP PKI enable the receiver of a BGP routing UPDATE to

Shirey Informational Page 261]

RFC 4949 Internet Security Glossary, Version 2 August 2007

validate the attribute and gain trust in the address prefixes and path information that it contains. - IPsec provides data and partial sequence integrity, and enables BGP routers to authenticate each other for exchanges of BGP control traffic.

([[Fair Use]] [[Source]]: [[RFC 4949])

Secure Data Exchange (SDE)

(N) A LAN security protocol defined by the IEEE 802.10 standard.

([[Fair Use]] [[Source]]: [[RFC 4949])

Secure Data Network System (SDNS)

(O) An NSA program that developed security protocols for electronic mail (see: MSP), OSIRM Layer 3 (see: SP3), OSIRM Layer 4 (see: SP4), and key establishment (see: KMP).

([[Fair Use]] [[Source]]: [[RFC 4949])

secure distribution

(I) See: trusted distribution.

([[Fair Use]] [[Source]]: [[RFC 4949])

Secure Hash Algorithm (SHA)

(N) A cryptographic hash function (specified in SHS) that produces an output (see: “hash result”) – of selectable length of either 160, 224, 256, 384, or 512 bits – for input data of any length < 2**64 bits.

([[Fair Use]] [[Source]]: [[RFC 4949])

Secure Hash Standard (SHS)

(N) The U.S. Government standard [FP180] that specifies SHA.

([[Fair Use]] [[Source]]: [[RFC 4949])

Secure Hypertext Transfer Protocol (S-HTTP)

(I) An Internet protocol [R2660] for providing client-server security services for HTTP communications. (Compare: https.)

Tutorial: S-HTTP was originally specified by CommerceNet, a coalition of businesses interested in developing the Internet for commercial uses. Several message formats may be incorporated into S-HTTP clients and servers, particularly CMS and MOSS. S-HTTP supports choice of security policies, key management mechanisms, and cryptographic algorithms through option negotiation between parties for each transaction. S-HTTP supports modes of operation for both asymmetric and symmetric cryptography. S-HTTP attempts to avoid presuming a particular trust model, but it attempts to facilitate multiply rooted, hierarchical trust and anticipates that principals may have many public-key certificates.

([[Fair Use]] [[Source]]: [[RFC 4949])

Secure/MIME (S/MIME)

(I) Secure/Multipurpose Internet Mail Extensions, an Internet protocol [R3851] to provide encryption and digital signatures for Internet mail messages.

Shirey Informational Page 262]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

secure multicast

(I) Refers generally to providing security services for multicast groups of various types (e.g., 1-to-N and M-to-N) and to classes of protocols used to protect multicast packets.

Tutorial: Multicast applications include video broadcast and multicast file transfer, and many of these applications require network security services. The Multicast Security Reference Framework [R3740] covers three functional areas: - Multicast data handling: Security-related treatment of multicast data by the sender and the receiver. - Group key management: Secure distribution and refreshment of keying material. (See: Group Domain of Interpretation.) - Multicast security policy: Policy translation and interpretation across the multiple administrative domains that typically are spanned by a multicast application.

([[Fair Use]] [[Source]]: [[RFC 4949])

Secure Shell(trade mark) (SSH(trade mark))

(N) Refers to a protocol for secure remote login and other secure network services.

Usage: On the Web site of SSH Communication Security Corporation, at http://www.ssh.com/legal_notice.html, it says, “SSH [and] the SSH logo … are either trade marks or registered trade marks of SSH.” This Glossary seeks to make readers aware of this trade mark claim but takes no position on its validity.

Tutorial: SSH has three main parts: - Transport layer protocol: Provides server authentication, confidentiality, and integrity; and can optionally provide compression. This layer typically runs over a TCP connection, but might also run on top of any other reliable data stream. - User authentication protocol: Authenticates the client-side user to the server. It runs over the transport layer protocol. - Connection protocol: Multiplexes the encrypted tunnel into several logical channels. It runs over the user authentication protocol.

([[Fair Use]] [[Source]]: [[RFC 4949])

Secure Sockets Layer (SSL)

(N) An Internet protocol (originally developed by Netscape Communications, Inc.) that uses connection-oriented end-to-end encryption to provide data confidentiality service and data integrity service for traffic between a client (often a web browser) and a server, and that can optionally provide peer entity authentication between the client and the server. (See: Transport Layer Security.)

Shirey Informational Page 263]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Tutorial: SSL has two layers; SSL's lower layer, the SSL Record Protocol, is layered on top of an IPS Transport-Layer protocol and encapsulates protocols that run in the upper layer. The upper- layer protocols are the three SSL management protocols – SSL Handshake Protocol, SSL Change Cipher Spec Protocol, or SSL Alert Protocol – and some Application-Layer protocol (e.g., HTTP).

The SSL management protocols provide asymmetric cryptography for server authentication (verifying the server's id[[entity to the client) and optional client authentication (verifying the client's id[[entity to the server), and also enable them, before the application protocol transmits or receives data, to negotiate a symmetric encryption algorithm and secret session key (to use for data confidentiality service) and a keyed hash (to use for data integrity service).

SSL is independent of the application it encapsulates, and any application can layer on top of SSL transparently. However, many Internet applications might be better served by IPsec.

([[Fair Use]] [[Source]]: [[RFC 4949])

secure state

1a. (I) A system condition in which the system is in conformance with the applicable security policy. (Compare: clean system, transaction.)

1b. (I) /formal model/ A system condition in which no subject can access any object in an unauthorized manner. (See: secondary definition under “Bell-LaPadula model”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security

1a. (I) A system condition that results from the establishment and maintenance of measures to protect the system.

1b. (I) A system condition in which system resources are free from unauthorized access and from unauthorized or accidental change, destruction, or loss. (Compare: safety.)

2. (I) Measures taken to protect a system.

Tutorial: Parker [Park] suggests that providing a condition of system security may involve the following six basic functions, which overlap to some extent: - “Deterrence”: Reducing an intelligent threat by discouraging action, such as by fear or doubt. (See: attack, threat action.) - “Avoidance”: Reducing a risk by either reducing the value of the potential loss or reducing the probability that the loss will occur. (See: risk analysis. Compare: “risk avoidance” under “risk”.)

Shirey Informational Page 264]

RFC 4949 Internet Security Glossary, Version 2 August 2007

- “Prevention”: Impeding or thwarting a potential security violation by deploying a counter measure. - “Detection”: Determining that a security violation is impending, is in progress, or has recently occurred, and thus make it possible to reduce the potential loss. (See: intrusion detection.) - “Recovery”: Restoring a normal state of system operation by compensating for a security violation, possibly by eliminating or repairing its effects. (See: contingency plan, main entry for “recovery”.) - “Correction”: Changing a security architecture to eliminate or reduce the risk of reoccurrence of a security violation or threat consequence, such as by eliminating a vulnerability.

([[Fair Use]] [[Source]]: [[RFC 4949])

security architecture

(I) A plan and set of principles that describe (a) the security services that a system is required to provide to meet the needs of its users, (b) the system components required to implement the services, and © the performance levels required in the components to deal with the threat environment (e.g., [R2179]). (See: defense in depth, IATF, OSIRM Security Architecture, security controls, Tutorial under “security policy”.)

Tutorial: A security architecture is the result of applying the system engineering process. A complete system security architecture includes administrative security, communication security, computer security, emanations security, personnel security, and physical security. A complete security architecture needs to deal with both intentional, intelligent threats and accidental threats.

([[Fair Use]] [[Source]]: [[RFC 4949])

Security Assertion Markup Language (SAML)

(N) A protocol consisting of XML-based request and response message formats for exchanging security information, expressed in the form of assertions about subjects, between on-line business partners. SAML

([[Fair Use]] [[Source]]: [[RFC 4949])

security association

1. (I) A relationship established between two or more entities to enable them to protect data they exchange. (See: association, ISAKMP, SAD. Compare: session.)

Tutorial: The relationship is represented by a set of data that is shared between the entities and is agreed upon and considered a contract between them. The data describes how the associated entities jointly use security services. The relationship is used to negotiate characteristics of security mechanisms, but the

Shirey Informational Page 265]

RFC 4949 Internet Security Glossary, Version 2 August 2007

relationship is usually understood to exclude the mechanisms themselves.

2. (I) /IPsec/ A simplex (uni-directional) logical connection created for security purposes and implemented with either AH or ESP (but not both). The security services offered by a security association depend on the protocol (AH or ESP), the IPsec mode (transport or tunnel), the endpoints, and the election of optional services within the protocol. A security association is identified by a triple consisting of (a) a destination IP address, (b) a protocol (AH or ESP) identifier, and © a Security Parameter Index.

3. (O) “A set of policy and cryptographic keys that provide security services to network traffic that matches that policy”. [R3740] (See: cryptographic association, group security association.)

4. (O) “The totality of communications and security mechanisms and functions (e.g., communications protocols, security protocols, security mechanisms and functions) that securely binds together two security contexts in different end systems or relay systems supporting the same information domain.” DoD6]

([[Fair Use]] [[Source]]: [[RFC 4949])

Security Association Database (SAD)

(I) /IPsec/ In an IPsec implementation that operates in a network node, a database that contains parameters to describe the status and operation of each of the active security associations that the node has established with other nodes. Separate inbound and outbound SADs are needed because of the directionality of IPsec security associations. [R4301] (Compare: SPD.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security association identifier (SAID)

(I) A data field in a security protocol (such as NLSP or SDE), used to identify the security association to which a PDU is bound. The SAID value is usually used to select a key for decryption or authentication at the destination. (See: Security Parameter Index.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security assurance

1. (I) An attribute of an information system that provides grounds for having confidence that the system operates such that the system's security policy is enforced. (Compare: trust.)

2. (I) A procedure that ensures a system is developed and operated as intended by the system's security policy.

Shirey Informational Page 266]

RFC 4949 Internet Security Glossary, Version 2 August 2007

3. (D) “The degree of confidence one has that the security controls operate correctly and protect the system as intended.” [SP12]

Deprecated Definition: IDOCs SHOULD NOT use definition 3; it is a definition for “assurance level” rather than for “assurance”.

4. (D) /U.S. Government, id[[entity authentication/ The (a) “degree of confidence in the vetting process used to establish the id[[entity of the individual to whom the id[[entity credential was issued” and the (b) “degree of confidence that the individual who uses the credential is the individual to whom the credential was issued”. [M0404]

Deprecated Definition: IDOCs SHOULD NOT use definition 4; it mixes concepts in a potentially misleading way. Part “a” is a definition for “assurance level” (rather than “security assurance”) of an id[[entity registration process; and part “b” is a definition for “assurance level” (rather than “security assurance”) of an id[[entity authentication process. Also, the processes of registration and authentication should be defined and designed separately to ensure clarity in certification.

([[Fair Use]] [[Source]]: [[RFC 4949])

security audit

(I) An independent review and examination of a system's records and activities to determine the adequacy of system controls, ensure compliance with established security policy and procedures, detect breaches in security services, and recommend any changes that are indicated for counter measures. [I7498-2, NCS01] (Compare: accounting, intrusion detection.)

Tutorial: The basic audit objective is to establish accountability for system entities that initiate or participate in security- relevant events and actions. Thus, means are needed to generate and record a security audit trail and to review and analyze the audit trail to discover and investigate security violations.

([[Fair Use]] [[Source]]: [[RFC 4949])

security audit trail

(I) A chronological record of system activities that is sufficient to enable the reconstruction and examination of the sequence of environments and activities surrounding or leading to an operation, procedure, or event in a security-relevant transaction from inception to final results. [NCS04] (See: security audit.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security by obscurity

(O) Attempting to maintain or increase security of a system by keeping secret the design or construction of a security mechanism.

Shirey Informational Page 267]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Tutorial: This approach has long been discredited in cryptography, where the phrase refers to trying to keep an algorithm secret, rather than just concealing the keys [Schn]. One must assume that mass-produced or widely fielded cryptographic devices eventually will be lost or stolen and, therefore, that the algorithms will be reverse engineered and become known to the adversary. Thus, one should rely on only those algorithms and protocols that are strong enough to have been published widely, and have been peer reviewed for long enough that their flaws have been found and removed. For example, NIST used a long, public process to select AES to replace DES.

In computer and network security, the principle of “no security by obscurity” also applies to security mechanisms other than cryptography. For example, if the design and implementation of a protocol for access control are strong, then reading the protocol's source code should not enable you to find a way to evade the protection and penetrate the system.

([[Fair Use]] [[Source]]: [[RFC 4949])

security class

(D) Synonym for “security level”.

Deprecated Term: IDOCs SHOULD NOT use this term. Instead, use “security level”, which is more widely established and understood.

([[Fair Use]] [[Source]]: [[RFC 4949])

security clearance

(I) A determination that a person is eligible, under the standards of a specific security policy, for authorization to access sensitive information or other system resources. (See: clearance level.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security compromise

(I) A security violation in which a system resource is exposed, or is potentially exposed, to unauthorized access. (Compare: data compromise, exposure, violation.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security controls

(N) The management, operational, and technical controls (safe guards or counter measures) prescribed for an information system which, taken together, satisfy the specified security requirements and adequately protect the confidentiality, integrity, and availability of the system and its information. [FP199] (See: security architecture.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security doctrine

(I) A specified set of procedures or practices that direct or provide guidance for how to comply with security policy. (Compare: security mechanism, security policy.)

Shirey Informational Page 268]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Tutorial: Security policy and security doctrine are closely related. However, policy deals mainly with strategy, and doctrine deals with tactics.

Security doctrine is often understood to refer mainly to administrative security, personnel security, and physical security. For example, security mechanisms and devices that implement them are normally designed to operate in a limited range of environmental and administrative conditions, and these conditions must be met to complement and ensure the technical protection afforded by the hardware, firm ware, and software in the devices. Security doctrine specifies how to achieve those conditions. (See: “first law” under “Courtney's laws”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security domain

(I) See: domain.

([[Fair Use]] [[Source]]: [[RFC 4949])

security environment

(I) The set of external entities, procedures, and conditions that affect secure development, operation, and maintenance of a system. (See: “first law” under “Courtney's laws”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security event

(I) An occurrence in a system that is relevant to the security of the system. (See: security incident.)

Tutorial: The term covers both events that are security incidents and those that are not. In a CA workstation, for example, a list of security events might include the following: - Logging an operator into or out of the system. - Performing a cryptographic operation, e.g., signing a digital certificate or CRL. - Performing a cryptographic card operation: creation, insertion, removal, or backup. - Performing a digital certificate life cycle operation: rekey, renewal, revocation, or update. - Posting a digital certificate to an X.500 Directory. - Receiving a key compromise notification. - Receiving an improper certification request. - Detecting an alarm condition reported by a cryptographic module. - Failing a built-in hardware self-test or a software system integrity check.

([[Fair Use]] [[Source]]: [[RFC 4949])

security fault analysis

(I) A security analysis, usually performed on hardware at the level of gate logic, gate-by-gate, to determine the security properties of a device when a hardware fault is encountered.

Shirey Informational Page 269]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

security function

(I) A function in a system that is relevant to the security of the system; i.e., a system function that must operate correctly to ensure adherence to the system's security policy.

([[Fair Use]] [[Source]]: [[RFC 4949])

security gateway

1. (I) An internet work gateway that separates trusted (or relatively more trusted) hosts on one side from untrusted (or less trusted) hosts on the other side. (See: firewall and guard.)

2. (O) /IPsec/ “An intermediate system that implements IPsec protocols.” [R4301]

Tutorial: IPsec's AH or ESP can be implemented on a gateway between a protected network and an unprotected network, to provide security services to the protected network's hosts when they communicate across the unprotected network to other hosts and gateways.

([[Fair Use]] [[Source]]: [[RFC 4949])

security incident

1. (I) A security event that involves a security violation. (See: CERT, security event, security intrusion, security violation.)

Tutorial: In other words, a security event in which the system's security policy is disobeyed or otherwise breached.

2. (D) “Any adverse event [that] compromises some aspect of computer or network security.” [R2350]

Deprecated Definition: IDOCs SHOULD NOT use definition 2 because (a) a security incident may occur without actually being harmful (i.e., adverse) and because (b) this Glossary defines “compromise” more narrowly in relation to unauthorized access.

3. (D) “A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard computer security practices.” [SP61]

Deprecated Definition: IDOCs SHOULD NOT use definition 3 because it mixes concepts in way that does not agree with common usage; a security incident is commonly thought of as involving a realization of a threat (see: threat action), not just a threat.

([[Fair Use]] [[Source]]: [[RFC 4949])

security intrusion

(I) A security event, or a combination of multiple security events, that constitutes a security incident in which an intruder gains, or attempts to gain, access to a system or system resource without having authorization to do so.

Shirey Informational Page 270]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

security kernel

(I) “The hardware, firm ware, and software elements of a trusted computing base that implement the reference monitor concept. It must mediate all accesses, be protected from modification, and be verifiable as correct.” [NCS04] (See: kernel, TCB.)

Tutorial: A security kernel is an implementation of a reference monitor for a given hardware base. [Huff]

([[Fair Use]] [[Source]]: [[RFC 4949])

security label

(I) An item of meta-data that designates the value of one or more security-relevant attributes (e.g., security level) of a system resource. (See: [R1457]. Compare: security marking.)

Deprecated usage: To avoid confusion, IDOCs SHOULD NOT use “security label” for “security marking”, or vice versa, even though that is commonly done (including in some national and international standards that should know better).

Tutorial: Humans and automated security mechanisms use a security label of a system resource to determine, according to applicable security policy, how to control access to the resource (and they affix appropriate, matching security markings to physical instances of the resource). Security labels are most often used to support data confidentiality policy, and sometimes used to support data integrity policy.

As explained in [R1457], the form that is taken by security labels of a protocol's packets varies depending on the OSIRM layer in which the protocol operates. Like meta-data generally, a security label of a data packet may be either explicit (e.g., IPSO) or implicit (e.g., Alice treats all messages received from Bob as being labeled “Not For Public Release”). In a connectionless protocol, every packet might have an explicit label; but in a connection-oriented protocol, all packets might have the same implicit label that is determined at the time the connection is established.

Both classified and unclassified system resources may require a security label. (See: FOUO.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security level

(I) The combination of a hierarchical classification level and a set of non-hierarchical category designations that represents how sensitive a specified type or item of information is. (See: dominate, lattice model. Compare: classification level.)

Shirey Informational Page 271]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Usage: IDOCs that use this term SHOULD state a definition for it. The term is usually understood to involve sensitivity to disclosure, but it also is used in many other ways and could easily be misunderstood.

([[Fair Use]] [[Source]]: [[RFC 4949])

Security Level field

(I) A 16-bit field that specifies a security level value in the security option (option type 130) of version 4 IP's datagram header format.

Deprecated Abbreviation: IDOCs SHOULD NOT use the abbreviation “S field”, which is potentially ambiguous.

([[Fair Use]] [[Source]]: [[RFC 4949])

security management infrastructure (SMI)

(I) System components and activities that support security policy by monitoring and controlling security services and mechanisms, distributing security information, and reporting security events.

Tutorial: The associated functions are as follows [I7498-4]: - Controlling (granting or restricting) access to system resources: This includes verifying authorizations and identities, controlling access to sensitive security data, and modifying access priorities and procedures in the event of attacks. - Retrieving (gathering) and archiving (storing) security information: This includes logging security events and analyzing the log, monitoring and profiling usage, and reporting security violations. - Managing and controlling the encryption process: This includes performing the functions of key management and reporting on key management problems. (See: PKI.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security marking

(I) A physical marking that is bound to an instance of a system resource and that represents a security label of the resource, i.e., that names or designates the value of one or more security- relevant attributes of the resource. (Compare: security label.)

Tutorial: A security label may be represented by various equivalent markings depending on the physical form taken by the labeled resource. For example, a document could have a marking composed of a bit pattern [FP188] when the document is stored electronically as a file in a computer, and also a marking of printed alphabetic characters when the document is in paper form.

Shirey Informational Page 272]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

security mechanism

(I) A method or process (or a device incorporating it) that can be used in a system to implement a security service that is provided by or within the system. (See: Tutorial under “security policy”. Compare: security doctrine.)

Usage: Usually understood to refer primarily to components of communication security, computer security, and emanation security.

Examples: Authentication exchange, checksum, digital signature, encryption, and traffic padding.

([[Fair Use]] [[Source]]: [[RFC 4949])

security model

(I) A schematic description of a set of entities and relationships by which a specified set of security services are provided by or within a system. Example: Bell-LaPadula model, OSIRM. (See: Tutorial under “security policy”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security parameters index (SPI)

1. (I) /IPsec/ A 32-bit identifier used to distinguish among security associations that terminate at the same destination (IP address) and use the same security protocol (AH or ESP). Carried in AH and ESP to enable the receiving system to determine under which security association to process a received packet.

2. (I) /mobile IP/ A 32-bit index identifying a security association from among the collection of associations that are available between a pair of nodes, for application to mobile IP protocol messages that the nodes exchange.

([[Fair Use]] [[Source]]: [[RFC 4949])

security perimeter

(I) A physical or logical boundary that is defined for a domain or enclave and within which a particular security policy or security architecture applies. (See: insider, outsider.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security policy

1. (I) A definite goal, course, or method of action to guide and determine present and future decisions concerning security in a system. [NCS03, R3198] (Compare: certificate policy.)

2a. (I) A set of policy rules (or principles) that direct how a system (or an organization) provides security services to protect sensitive and critical system resources. (See: id[[entity-based security policy, policy rule, rule-based security policy, rules of behavior. Compare: security architecture, security doctrine, security mechanism, security model, [R1281].)

Shirey Informational Page 273]

RFC 4949 Internet Security Glossary, Version 2 August 2007

2b. (O) A set of rules to administer, manage, and control access to network resources. [R3060, R3198]

2c. (O) /X.509/ A set of rules laid down by an authority to govern the use and provision of security services and facilities.

2d. (O) /Common Criteria/ A set of rules that regulate how assets are managed, protected, and distributed within a TOE.

Tutorial: Ravi Sandhu suggests that security policy is one of four layers of the security engineering process (as shown in the following diagram). Each layer provides a different view of security, ranging from what services are needed to how services are implemented.

What Security Services Should Be Provided? +- - - - - - - - - - - - -+

+- - - - - - - - - - - -	Mission Functions View
	Security Policy
+- - - - - - - - - - - -	Domain Practices View
	Security Model
+- - - - - - - - - - - -	Enclave Services View
	Security Architecture
+- - - - - - - - - - - -	Agent Mechanisms View
	Security Mechanism

v +- - - - - - - - - - - -| Platform Devices View| How Are Security +- - - - - - - - - - - - -+ Services Implemented?

We suggest that each of Sandhu's four layers is a mapping between two points of view that differ in their degree of abstraction, according to the perspectives of various participants in system design, development, and operation activities, as follows:. - Mission functions view: The perspective of a user of system resources. States time-phased protection needs for resources and identifies sensitive and critical resources – networks, hosts, applications, and databases. Independent of rules and practices used to achieve protection. - Domain practices view: The perspective of an enterprise manager who sets protection standards for resources. States rules and practices for protection. Identifies domain members; i.e., entities (users/providers) and resources (including data objects). Independent of system topology. Not required to be hierarchical. - Enclave services view: The perspective of a system designer who allocates security functions to major components. Assigns security services to system topology structures and their

Shirey Informational Page 274]

RFC 4949 Internet Security Glossary, Version 2 August 2007

contents. Independent of security mechanisms. Hierarchical across all domains. - Agent mechanisms view: The perspective of a system engineer who specifies security mechanisms to implement security services. Specifies mechanisms to be used by protocol, database, and application engines. Independent of type and manufacture of platforms and other physical devices. - Platform devices view: The perspective of an as-built description of the system in operation. Specifies exactly how to build or assemble the system, and also specifies procedures for operating the system.

([[Fair Use]] [[Source]]: [[RFC 4949])

Security Policy Database (SPD)

(I) /IPsec/ In an IPsec implementation operating in a network node, a database that contains parameters that specify policies set by a user or administrator to determine what IPsec services, if any, are to be provided to IP datagrams sent or received by the node, and in what fashion they are provided. For each datagram, the SPD specifies one of three choices: discard the datagram, apply IPsec services (e.g., AH or ESP), or bypass IPsec. Separate inbound and outbound SPDs are needed because of the directionality of IPsec security associations. [R4301] (Compare: SAD.)

([[Fair Use]] [[Source]]: [[RFC 4949])

Security Protocol 3 (SP3)

(O) A protocol [SDNS3] developed by SDNS to provide connectionless data security at the top of OSIRM Layer 3. (Compare: IPsec, NLSP.)

([[Fair Use]] [[Source]]: [[RFC 4949])

Security Protocol 4 (SP4)

(O) A protocol [SDNS4] developed by SDNS to provide either connectionless or end-to-end connection-oriented data security at the bottom of OSIRM Layer 4. (See: TLSP.)

([[Fair Use]] [[Source]]: [[RFC 4949])

security-relevant event

(D) Synonym for “security event”.

Deprecated Term: IDOCs SHOULD NOT use this term; it is wordy.

([[Fair Use]] [[Source]]: [[RFC 4949])

security-sensitive function

(D) Synonym for “security function”.

Deprecated Term: IDOCs SHOULD NOT use this term; it is wordy.

([[Fair Use]] [[Source]]: [[RFC 4949])

security service

1. (I) A processing or communication service that is provided by a system to give a specific kind of protection to system resources. (See: access control service, audit service, availability service, data confidentiality service, data integrity service, data origin

Shirey Informational Page 275]

RFC 4949 Internet Security Glossary, Version 2 August 2007

authentication service, non-repudiation service, peer entity authentication service, system integrity service.)

Tutorial: Security services implement security policies, and are implemented by security mechanisms.

2. (O) “A service, provided by a layer of communicating open systems, [that] ensures adequate security of the systems or the data transfers.” [I7498-2]

([[Fair Use]] [[Source]]: [[RFC 4949])

security situation

(I) /ISAKMP/ The set of all security-relevant information (e.g., network addresses, security classifications, manner of operation such as normal or emergency) that is needed to decide the security services that are required to protect the association that is being negotiated.

([[Fair Use]] [[Source]]: [[RFC 4949])

security target

(N) /Common Criteria/ A set of security requirements and specifications to be used as the basis for evaluation of an identified TOE.

Tutorial: A security target (ST) is a statement of security claims for a particular information technology security product or system, and is the basis for agreement among all parties as to what security the product or system offers. An ST parallels the structure of a protection profile, but has additional elements that include product-specific detailed information. An ST contains a summary specification, which defines the specific measures taken in the product or system to meet the security requirements.

([[Fair Use]] [[Source]]: [[RFC 4949])

security token

(I) See: token.

([[Fair Use]] [[Source]]: [[RFC 4949])

security violation

(I) An act or event that disobeys or otherwise breaches security policy. (See: compromise, penetration, security incident.)

([[Fair Use]] [[Source]]: [[RFC 4949])

seed

(I) A value that is an input to a pseudorandom number generator.

([[Fair Use]] [[Source]]: [[RFC 4949])

selective-field confidentiality

(I) A data confidentiality service that preserves confidentiality for one or more parts (i.e., fields) of each packet. (See: selective-field integrity.)

Tutorial: Data confidentiality service usually is applied to entire SDUs, but some situations might require protection of only

Shirey Informational Page 276]

RFC 4949 Internet Security Glossary, Version 2 August 2007

part of each packet. For example, when Alice uses a debit card at an automated teller machine (ATM), perhaps only her PIN is enciphered for confidentiality when her transaction request is transmitted from the ATM to her bank's computer.

In any given operational situation, there could be many different reasons for using selective field confidentiality. In the ATM example, there are at least four possibilities: The service may provide a fail-safe mode of operation, ensuring that the bank can still process transactions (although with some risk) even when the encryption system fails. It may make messages easier to work with when doing system fault isolation. It may avoid problems with laws that prevent shipping enciphered data across international borders. It may improve efficiency by reducing processing load at a central computer site.

([[Fair Use]] [[Source]]: [[RFC 4949])

selective-field integrity

(I) A data integrity service that preserves integrity for one or more parts (i.e., fields) of each packet. (See: selective-field confidentiality.)

Tutorial: Data integrity service may be implemented in a protocol to protect the SDU part of packets, the PCI part, or both. - SDU protection: When service is provided for SDUs, it usually is applied to entire SDUs, but it might be applied only to parts of SDUs in some situations. For example, an IPS Application-Layer protocol might need protection of only part of each packet, and this might enable faster processing. - PCI protection: To prevent active wire tapping, it might be desirable to apply data integrity service to the entire PCI, but some PCI fields in some protocols need to be mutable in transit. For example, the “Time to Live” field in IPv4 is changed each time a packet passes through a router in the Internet Layer. Thus, the value that the field will have when the packet arrives at its destination is not predictable by the sender and cannot be included in a checksum computed by the sender. (See: Authentication Header.)

([[Fair Use]] [[Source]]: [[RFC 4949])

self-signed certificate

(I) A public-key certificate for which the public key bound by the certificate and the private key used to sign the certificate are components of the same key pair, which belongs to the signer. (Compare: root certificate.)

Tutorial: In a self-signed X.509 public-key certificate, the issuer's DN is the same as the subject's DN.

Shirey Informational Page 277]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

semantic] [[security

(I) An attribute of an encryption algorithm that is a formalization of the notion that the algorithm not only hides the plain text but also reveals no partial information about the plain text; i.e., whatever is computable about the plain text when given the cipher text, is also computable without the cipher text. (Compare: indistinguishability.)

([[Fair Use]] [[Source]]: [[RFC 4949])

semiformal

(I) Expressed in a restricted syntax language with defined semantic]s. [CCIB] ([[Compare: formal, informal.)

([[Fair Use]] [[Source]]: [[RFC 4949])

sensitive

(I) A condition of a system resource such that the loss of some specified property of that resource, such as confidentiality or integrity, would adversely affect the interests or business of its owner or user. (See: sensitive information. Compare: critical.)

([[Fair Use]] [[Source]]: [[RFC 4949])

sensitive compartmented information (SCI)

(O) /U.S. Government/ Classified information concerning or derived from intelligence sources, methods, or analytical processes, which is required to be handled within formal control systems established by the Director of Central Intelligence. [C4009] (See: compartment, SAP, SCIF. Compare: collateral information.)

([[Fair Use]] [[Source]]: [[RFC 4949])

sensitive compartmented information facility (SCIF)

(O) /U.S. Government/ “An accredited area, room, group of rooms, building, or installation where SCI may be stored, used, discussed, and/or processed.” [C4009] (See: SCI. Compare: shielded enclosure.)

([[Fair Use]] [[Source]]: [[RFC 4949])

sensitive information

1. (I) Information for which (a) disclosure, (b) alteration, or © destruction or loss could adversely affect the interests or business of its owner or user. (See: data confidentiality, data integrity, sensitive. Compare: classified, critical.)

2. (O) /U.S. Government/ Information for which (a) loss, (b) misuse, © unauthorized access, or (d) unauthorized modification could adversely affect the national interest or the conduct of federal programs, or the privacy to which individuals are entitled under the Privacy Act of 1974, but that has not been specifically authorized under criteria established by an Executive Order or an Act of Congress to be kept classified in the interest of national defense or foreign policy.

Tutorial: Systems that are not U.S. national security systems, but contain sensitive U.S. Federal Government information, must be

Shirey Informational Page 278]

RFC 4949 Internet Security Glossary, Version 2 August 2007

protected according to the Computer Security Act of 1987 (Public Law 100-235). (See: national security.)

([[Fair Use]] [[Source]]: [[RFC 4949])

sensitivity label

(D) Synonym for “classification label”.

Deprecated term: IDOCs SHOULD NOT use this term because the definition of “sensitive” involves not only data confidentiality, but also data integrity.

([[Fair Use]] [[Source]]: [[RFC 4949])

sensitivity level

(D) Synonym for “classification level”.

Deprecated term: IDOCs SHOULD NOT use this term because the definition of “sensitive” involves not only data confidentiality, but also data integrity.

([[Fair Use]] [[Source]]: [[RFC 4949])

separation of duties

(I) The practice of dividing the steps in a system process among different individual entities (i.e., different users or different roles) so as to prevent a single entity acting alone from being able to subvert the process. Usage: a.k.a. “separation of privilege”. (See: administrative security, dual control.)

([[Fair Use]] [[Source]]: [[RFC 4949])

serial number

See: certificate serial number.

([[Fair Use]] [[Source]]: [[RFC 4949])

Serpent

(O) A symmetric, 128-bit block cipher designed by Ross Anderson, Eli Biham, and Lars Knudsen as a candidate for the AES.

([[Fair Use]] [[Source]]: [[RFC 4949])

server

(I) A system entity that provides a service in response to requests from other system entities called clients.

([[Fair Use]] [[Source]]: [[RFC 4949])

service data unit (SDU)

(N) See: secondary definition under “protocol data unit”.

([[Fair Use]] [[Source]]: [[RFC 4949])

session

1a. (I) /computer usage/ A continuous period of time, usually initiated by a login, during which a user accesses a computer system.

1b. (I) /computer activity/ The set of transactions or other computer activities that are performed by or for a user during a period of computer usage.

Shirey Informational Page 279]

RFC 4949 Internet Security Glossary, Version 2 August 2007

2. (I) /access control/ A temporary mapping of a principal to one or more roles. (See: role-based access control.)

Tutorial: A user establishes a session as a principal and activates some subset of roles to which the principal has been assigned. The authorizations available to the principal in the session are the union of the permissions of all the roles activated in the session. Each session is associated with a single principal and, therefore, with a single user. A principal may have multiple, concurrent sessions and may activate a different set of roles in each session.

3. (I) /computer network/ A persistent but (normally) temporary association between a user agent (typically a client) and a second process (typically a server). The association may persist across multiple exchanges of data, including multiple connections. (Compare: security association.)

([[Fair Use]] [[Source]]: [[RFC 4949])

session key

(I) In the context of symmetric encryption, a key that is temporary or is used for a relatively short period of time. (See: ephemeral, KDC, session. Compare: master key.)

Tutorial: A session key is used for a defined period of communication between two system entities or components, such as for the duration of a single connection or transaction set; or the key is used in an application that protects relatively large amounts of data and, therefore, needs to be rekeyed frequently.

([[Fair Use]] [[Source]]: [[RFC 4949])

SET(trade mark)

(O) See: SET Secure Electronic Transaction(trade mark).

([[Fair Use]] [[Source]]: [[RFC 4949])

SET private extension

(O) One of the private extensions defined by SET for X.509 certificates. Carries information about hashed root key, certificate type, merchant data, cardholder certificate requirements, encryption support for tunneling, or message support for payment instructions.

([[Fair Use]] [[Source]]: [[RFC 4949])

SET qualifier

(O) A certificate policy qualifier that provides information about the location and content of a SET certificate policy.

Tutorial: Besides the policies and qualifiers inherited from its own certificate, each CA in the SET certification hierarchy may add one qualifying statement to the root policy when the CA issues a certificate. The additional qualifier is a certificate policy for that CA. Each policy in a SET certificate may have these

Shirey Informational Page 280]

RFC 4949 Internet Security Glossary, Version 2 August 2007

qualifiers: (a) a URL where a copy of the policy statement may be found; (b) an electronic mail address where a copy of the policy statement may be found; © a hash result of the policy statement, computed using the indicated algorithm; and (d) a statement declaring any disclaimers associated with the issuing of the certificate.

([[Fair Use]] [[Source]]: [[RFC 4949])

SET Secure Electronic Transaction(trade mark) or SET(trade mark)

(N) A protocol developed jointly by MasterCard International and Visa International and published as an open standard to provide confidentiality of transaction information, payment integrity, and authentication of transaction participants for payment card transactions over unsecured networks, such as the Internet. [SET1] (See: acquirer, brand, cardholder, dual signature, electronic commerce, IOTP, issuer, merchant, payment gateway, third party.)

Tutorial: This term and acronym are trade marks of SETCo. MasterCard and Visa announced the SET standard on 1 February 1996.

([[Fair Use]] [[Source]]: [[RFC 4949])

SETCo

(O) Abbreviation of “SET Secure Electronic Transaction LLC”, formed on 19 December 1997 by MasterCard and Visa for implementing the SET Secure Electronic Transaction(trade mark) standard. A later memorandum of understanding added American Express and JCB Credit Card Company as co-owners of SETCo.

([[Fair Use]] [[Source]]: [[RFC 4949])

SHA, SHA-1, SHA-2

(N) See: Secure Hash Algorithm.

([[Fair Use]] [[Source]]: [[RFC 4949])

shared id[[entity

(I) See: secondary definition under “id[[entity”.

([[Fair Use]] [[Source]]: [[RFC 4949])

shared secret

(D) Synonym for “cryptographic key” or “password”.

Deprecated Usage: IDOCs that use this term SHOULD state a definition for it because the term is used in many ways and could easily be misunderstood.

([[Fair Use]] [[Source]]: [[RFC 4949])

shielded enclosure

(O) “Room or container designed to attenuate electromagnetic radiation, acoustic signals, or emanations.” [C4009] (See: emanation. Compare: SCIF.)

([[Fair Use]] [[Source]]: [[RFC 4949])

short title

(O) “Identifying combination of letters and numbers assigned to certain items of COMSEC material to facilitate handling, accounting, and controlling.” [C4009] (Compare: KMID, long title.)

Shirey Informational Page 281]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

shroud

(D) /verb/ To encrypt a private key, possibly in concert with a policy that prevents the key from ever being available in cleartext form beyond a certain, well-defined security perimeter. [PKC12] (See: encrypt. Compare: seal, wrap.)

Deprecated Term: IDOCs SHOULD NOT use this term as defined here; the definition duplicates the meaning of other, standard terms. Instead, use “encrypt” or other terminology that is specific with regard to the mechanism being used.

([[Fair Use]] [[Source]]: [[RFC 4949])

SHS

(N) See: Secure Hash Standard.

([[Fair Use]] [[Source]]: [[RFC 4949])

sign

(I) Create a digital signature for a data object. (See: signer.)

([[Fair Use]] [[Source]]: [[RFC 4949])

signal analysis

(I) Gaining indirect knowledge (inference) of communicated data by monitoring and analyzing a signal that is emitted by a system and that contains the data but is not intended to communicate the data. (See: emanation. Compare: traffic analysis.)

([[Fair Use]] [[Source]]: [[RFC 4949])

signal intelligence

(I) The science and practice of extracting information from signals. (See: signal security.)

([[Fair Use]] [[Source]]: [[RFC 4949])

signal security

(N) (I) The science and practice of protecting signals. (See: cryptology, security.)

Tutorial: The term “signal” denotes (a) communication in almost any form and also (b) emanations for other purposes, such as radar. Signal security is opposed by signal intelligence, and each discipline includes opposed sub-disciplines as follows [Kahn]:

Signal Security Signal Intelligence —————————— ——————————— 1. Communication Security 1. Communication Intelligence 1a. Cryptography 1a. Crypt analysis 1b. Traffic Security1b. Traffic Analysis 1c. Steganography1c. Detection and Interception 2. Electronic Security 2. Electronic Intelligence 2a. Emission Security 2a. Electronic Reconnaissance 2b. Counter-Counter measures 2b. Counter measures —————————— ———————————

Shirey Informational Page 282]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

signature

(O) A symbol or process adopted or executed by a system entity with present intention to declare that a data object is genuine. (See: digital signature, electronic signature.)

([[Fair Use]] [[Source]]: [[RFC 4949])

signature certificate

(I) A public-key certificate that contains a public key that is intended to be used for verifying digital signatures, rather than for encrypting data or performing other cryptographic functions.

Tutorial: A v3 X.509 public-key certificate may have a “key Usage” extension that indicates the purpose for which the certified public key is intended. (See: certificate profile.)

([[Fair Use]] [[Source]]: [[RFC 4949])

signed receipt

(I) An S/MIME service [R2634] that (a) provides, to the originator of a message, proof of delivery of the message and (b) enables the originator to demonstrate to a third party that the recipient was able to verify the signature of the original message.

Tutorial: The receipt is bound to the original message by a signature; consequently, the service may be requested only for a message that is signed. The receipt sender may optionally also encrypt the receipt to provide confidentiality between the receipt sender and the receipt recipient.

([[Fair Use]] [[Source]]: [[RFC 4949])

signer

(N) A human being or organization entity that uses a private key to sign (i.e., create a digital signature on) a data object. [DSG]

([[Fair Use]] [[Source]]: [[RFC 4949])

SILS

(N) See: Standards for Interoperable LAN/MAN Security.

([[Fair Use]] [[Source]]: [[RFC 4949])

simple authentication

1. (I) An authentication process that uses a password as the information needed to verify an id[[entity claimed for an entity. (Compare: strong authentication.)

2. (O) “Authentication by means of simple password arrangements.” [X509]

([[Fair Use]] [[Source]]: [[RFC 4949])

Simple Authentication and Security Layer (SASL)

(I) An Internet specification [R2222, R4422] for adding authentication service to connection-based protocols. (Compare: EAP, GSS-API.)

Shirey Informational Page 283]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Tutorial: To use SASL, a protocol includes a command for authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. The command names a registered security mechanism. SASL mechanisms include Kerberos, GSS-API, S/KEY, and others. Some protocols that use SASL are IMAP4 and POP3.

([[Fair Use]] [[Source]]: [[RFC 4949])

Simple Key Management for Internet Protocols (SKIP)

(I) A key-distribution protocol that uses hybrid encryption to convey session keys that are used to encrypt data in IP packets. (See: SKIP reference in [R2356].)

Tutorial: SKIP was designed by Ashar Aziz and Whitfield Diffie at Sun Micro systems and proposed as the standard key management protocol for IPsec, but IKE was chosen instead. Although IKE is mandatory for an IPsec implementation, the use of SKIP is not excluded.

SKIP uses the Diffie-Hellman-Merkle algorithm (or could use another key-agreement algorithm) to generate a key-encrypting key for use between two entities. A session key is used with a symmetric algorithm to encrypt data in one or more IP packets that are to be sent from one entity to the other. A symmetric KEK is established and used to encrypt the session key, and the encrypted session key is placed in a SKIP header that is added to each IP packet that is encrypted with that session key.

([[Fair Use]] [[Source]]: [[RFC 4949])

Simple Mail Transfer Protocol (SMTP)

(I) A TCP-based, Application-Layer, Internet Standard protocol (RFC 821) for moving electronic mail messages from one computer to another.

([[Fair Use]] [[Source]]: [[RFC 4949])

Simple Network Management Protocol (SNMP)

(I) A (usually) UDP-based, Application-Layer, Internet Standard protocol (RFCs 3410-3418) for conveying management information between system components that act as managers and agents.

([[Fair Use]] [[Source]]: [[RFC 4949])

Simple Public Key Infrastructure (SPKI)

(I) A set of experimental concepts (RFCs 2692, 2693) that were proposed as alternatives to the concepts standardized in PKIX.

([[Fair Use]] [[Source]]: [[RFC 4949])

simple security property

(N) /formal model/ Property of a system whereby a subject has read access to an object only if the clearance of the subject dominates the classification of the object. See: Bell-LaPadula model.

Shirey Informational Page 284]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

single sign-on

1. (I) An authentication sub system that enables a user to access multiple, connected system components (such as separate hosts on a network) after a single login at only one of the components. (See: Kerberos.)

2. (O) /Liberty Alliance/ A security sub system that enables a user id[[entity to be authenticated at an id[[entity provider – i.e., at a service that authenticates and asserts the user's id[[entity – and then have that authentication be honored by other service providers.

Tutorial: A single sign-on sub system typically requires a user to log in once at the beginning of a session, and then during the session transparently grants access by the user to multiple, separately protected hosts, applications, or other system resources, without further login action by the user (unless, of course, the user logs out). Such a sub system has the advantages of being user friendly and enabling authentication to be managed consistently across an entire enterprise. Such a sub system also has the disadvantage of requiring all the accessed components to depend on the security of the same authentication information.

([[Fair Use]] [[Source]]: [[RFC 4949])

singular id[[entity

(I) See: secondary definition under “id[[entity”.

([[Fair Use]] [[Source]]: [[RFC 4949])

site

(I) A facility – i.e., a physical space, room, or building together with its physical, personnel, administrative, and other safe guards – in which system functions are performed. (See: node.)

([[Fair Use]] [[Source]]: [[RFC 4949])

situation

(I) See: security situation.

([[Fair Use]] [[Source]]: [[RFC 4949])

SKEME

(I) A key-distribution protocol from which features were adapted for IKE. [SKEME]

([[Fair Use]] [[Source]]: [[RFC 4949])

SKIP

(I) See: Simple Key Management for Internet Protocols.

([[Fair Use]] [[Source]]: [[RFC 4949])

SKIPJACK

(N) A type 2, 64-bit block cipher [SKIP, R2773] with a key size of 80 bits. (See: CAPSTONE, CLIPPER, FORTEZZA, Key Exchange Algorithm.)

Shirey Informational Page 285]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Tutorial: SKIPJACK was developed by NSA and formerly classified at the U.S. DoD “Secret” level. On 23 June 1998, NSA announced that SKIPJACK had been declassified.

([[Fair Use]] [[Source]]: [[RFC 4949])

slot

(O) /MISSI/ One of the FORTEZZA PC card storage areas that are each able to hold an X.509 certificate plus other data, including the private key that is associated with a public-key certificate.

([[Fair Use]] [[Source]]: [[RFC 4949])

smart card

(I) A credit-card sized device containing one or more integrated circuit chips that perform the functions of a computer's central processor, memory, and input/output interface. (See: PC card, smart token.)

Usage: Sometimes this term is used rather strictly to mean a card that closely conforms to the dimensions and appearance of the kind of plastic credit card issued by banks and merchants. At other times, the term is used loosely to include cards that are larger than credit cards, especially cards that are thicker, such as PC cards.

([[Fair Use]] [[Source]]: [[RFC 4949])

smart token

(I) A device that conforms to the definition of “smart card” except that rather than having the standard dimensions of a credit card, the token is packaged in some other form, such as a military dog tag or a door key. (See: smart card, cryptographic token.)

([[Fair Use]] [[Source]]: [[RFC 4949])

SMI

(I) See: security management infrastructure.

([[Fair Use]] [[Source]]: [[RFC 4949])

SMTP

(I) See: Simple Mail Transfer Protocol.

([[Fair Use]] [[Source]]: [[RFC 4949])

smurf attack

(D) /slang/ A denial-of-service attack that uses IP broadcast addressing to send ICMP ping packets with the intent of flooding a system. (See: fraggle attack, ICMP flood.)

Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term.

Derivation: The Smurfs are a fictional race of small, blue creatures that were created by a cartoonist. Perhaps the inventor of this attack thought that a swarm of ping packets resembled a gang of smurfs. (See: Deprecated Usage under “Green Book”.)

Shirey Informational Page 286]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Tutorial: The attacker sends ICMP echo request (“ping”) packets that appear to originate not from the attacker's own IP address, but from the address of the host or router that is the target of the attack. Each packet is addressed to an IP broadcast address, e.g., to all IP addresses in a given network. Thus, each echo request that is sent by the attacker results in many echo responses being sent to the target address. This attack can disrupt service at a particular host, at the hosts that depend on a particular router, or in an entire network.

([[Fair Use]] [[Source]]: [[RFC 4949])

sneaker net

(D) /slang/ A process that transfers data between systems only manually, under human control; i.e., a data transfer process that involves an air gap.

Deprecated Term: It is likely that other cultures use different metaphors for this concept. Therefore, to avoid international misunderstanding, IDOCs SHOULD NOT use this term.

([[Fair Use]] [[Source]]: [[RFC 4949])

Snefru

(N) A public-domain, cryptographic hash function (a.k.a. “The Xerox Secure Hash Function”) designed by Ralph C. Merkle at Xerox Corporation. Snefru can produce either a 128-bit or 256-bit output (i.e., hash result). [Schn] (See: Khafre, Khufu.)

([[Fair Use]] [[Source]]: [[RFC 4949])

sniffing

(D) /slang/ Synonym for “passive wire tapping”; most often refers to capturing and examining the data packets carried on a LAN. (See: password sniffing.)

Deprecated Term: IDOCs SHOULD NOT use this term; it unnecessarily duplicates the meaning of a term that is better established. (See: Deprecated Usage under “Green Book”.

([[Fair Use]] [[Source]]: [[RFC 4949])

SNMP

(I) See: Simple Network Management Protocol.

([[Fair Use]] [[Source]]: [[RFC 4949])

social engineering

(D) Euphemism for non-technical or low-technology methods, often involving trickery or fraud, that are used to attack information systems. Example: phishing.

Deprecated Term: IDOCs SHOULD NOT use this term; it is too vague. Instead, use a term that is specific with regard to the means of attack, e.g., black mail, bribery, coercion, impersonation, intimidation, lying, or theft.

Shirey Informational Page 287]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

SOCKS

(I) An Internet protocol [R1928] that provides a generalized proxy server that enables client-server applications (e.g., TELNET, FTP, or HTTP; running over either TCP or UDP) to use the services of a firewall.

Tutorial: SOCKS is layered under the IPS Application Layer and above the Transport Layer. When a client inside a firewall wishes to establish a connection to an object that is reachable only through the firewall, it uses TCP to connect to the SOCKS server, negotiates with the server for the authentication method to be used, authenticates with the chosen method, and then sends a relay request. The SOCKS server evaluates the request, typically based on source and destination addresses, and either establishes the appropriate connection or denies it.

([[Fair Use]] [[Source]]: [[RFC 4949])

soft TEMPEST

(O) The use of software techniques to reduce the radio frequency information leakage from computer displays and keyboards. [Kuhn] (See: TEMPEST.)

([[Fair Use]] [[Source]]: [[RFC 4949])

soft token

(D) A data object that is used to control access or authenticate authorization. (See: token.)

Deprecated Term: IDOCs SHOULD NOT use this term as defined here; the definition duplicates the meaning of other, standard terms. Instead, use “attribute certificate” or another term that is specific with regard to the mechanism being used.

([[Fair Use]] [[Source]]: [[RFC 4949])

software

(I) Computer programs (which are stored in and executed by computer hardware) and associated data (which also is stored in the hardware) that may be dynamically written or modified during execution. (Compare: firm ware.)

([[Fair Use]] [[Source]]: [[RFC 4949])

software error

(I) /threat action/ See: secondary definitions under “corruption”, “exposure”, and “incapacitation”.

([[Fair Use]] [[Source]]: [[RFC 4949])

SORA

(O) See: SSO-PIN ORA.

([[Fair Use]] [[Source]]: [[RFC 4949])

source authentication

(D) Synonym for “data origin authentication” or “peer entity authentication”. (See: data origin authentication, peer entity authentication).

Shirey Informational Page 288]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Deprecated Term: IDOCs SHOULD NOT use this term because it is ambiguous and, in either meaning, duplicates the meaning of internationally standardized terms. If the intent is to authenticate the original creator or packager of data received, then use “data origin authentication”. If the intent is to authenticate the id[[entity of the sender of data in the current instance, then use “peer entity authentication”.

([[Fair Use]] [[Source]]: [[RFC 4949])

source integrity

(I) The property that data is trustworthy (i.e., worthy of reliance or trust), based on the trustworthiness of its sources and the trustworthiness of any procedures used for handling data in the system. Usage: a.k.a. Biba integrity. (See: integrity. Compare: correctness integrity, data integrity.)

Tutorial: For this kind of integrity, there are formal models of unauthorized modification (see: Biba model) that logically complement the more familiar models of unauthorized disclosure (see: Bell-LaPadula model). In these models, objects are labeled to indicate the credibility of the data they contain, and there are rules for access control that depend on the labels.

([[Fair Use]] [[Source]]: [[RFC 4949])

SP3

(O) See: Security Protocol 3.

([[Fair Use]] [[Source]]: [[RFC 4949])

SP4

(O) See: Security Protocol 4.

([[Fair Use]] [[Source]]: [[RFC 4949])

spam

1a. (I) /slang verb/ To indiscriminately send unsolicited, unwanted, irrelevant, or inappropriate messages, especially commercial advertising in mass quantities.

1b. (I) /slang noun/ Electronic “junk mail”. [R2635]

Deprecated Usage: IDOCs SHOULD NOT use this term in upper case letters, because SPAM(trade mark) is a trade mark of Hormel Foods Corporation. Hormel says, “We do not object to use of this slang term spam to describe [unsolicited advertising email, although we do object to the use of our product image in association with that term. Also, if the term is to be used, it SHOULD be used in all lower-case letters to distinguish it from our trade mark SPAM, which SHOULD be used with all upper case letters.” (See: metadata.)

Tutorial: In sufficient volume, spam can cause denial of service. (See: flooding.) According to Hormel, the term was adopted as a result of a Monty Python skit in which a group of Vikings sang a chorus of 'SPAM, SPAM, SPAM …' in an increasing crescendo,

Shirey Informational Page 289]

RFC 4949 Internet Security Glossary, Version 2 August 2007

drowning out other conversation. This lyric became a metaphor for the unsolicited advertising messages that threaten to overwhelm other discourse on the Internet.

([[Fair Use]] [[Source]]: [[RFC 4949])

SPD

(I) See: Security Policy Database.

([[Fair Use]] [[Source]]: [[RFC 4949])

special access program (SAP)

(O) /U.S. Government/ “Sensitive program, [that is] approved in writing by a head of agency with [i.e., who has] original top secret classification authority, [and] that imposes need-to-know and access controls beyond those normally provided for access to Confidential, Secret, or Top Secret information. The level of controls is based on the criticality of the program and the assessed hostile intelligence threat. The program may be an acquisition program, an intelligence program, or an operations and support program.” [C4009] (See: formal access approval, SCI. Compare: collateral information.)

([[Fair Use]] [[Source]]: [[RFC 4949])

SPI

(I) See: Security Parameters Index.

([[Fair Use]] [[Source]]: [[RFC 4949])

SPKI

(I) See: Simple Public Key Infrastructure.

([[Fair Use]] [[Source]]: [[RFC 4949])

split key

(I) A cryptographic key that is generated and distributed as two or more separate data items that individually convey no knowledge of the whole key that results from combining the items. (See: dual control, split knowledge.)

([[Fair Use]] [[Source]]: [[RFC 4949])

split knowledge

1. (I) A security technique in which two or more entities separately hold data items that individually do not convey knowledge of the information that results from combining the items. (See: dual control, split key.)

2. (O) “A condition under which two or more entities separately have key components [that] individually convey no knowledge of the plain text key [that] will be produced when the key components are combined in the cryptographic module.” [FP140]

([[Fair Use]] [[Source]]: [[RFC 4949])

spoof

(I) /threat action/ See: secondary definition under “masquerade”.

([[Fair Use]] [[Source]]: [[RFC 4949])

spoofing attack

(I) Synonym for “masquerade attack”.

Shirey Informational Page 290]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

spread spectrum

(N) A TRANSEC technique that transmits a signal in a band width much greater than the transmitted information needs. [F1037] Example: frequency hopping.

Tutorial: Usually uses a sequential, noise-like signal structure to spread the normally narrowband information signal over a relatively wide band of frequencies. The receiver correlates the signals to retrieve the original information signal. This technique decreases potential interference to other receivers, while achieving data confidentiality and increasing immunity of spread spectrum receivers to noise and interference.

([[Fair Use]] [[Source]]: [[RFC 4949])

spyware

(D) /slang/ Software that an intruder has installed surreptitiously on a networked computer to gather data from that computer and send it through the network to the intruder or some other interested party. (See: malicious logic, Trojan horse.)

Deprecated Usage: IDOCs that use this term SHOULD state a definition for it because the term is used in many ways and could easily be misunderstood.

Tutorial: Some examples of the types of data that might be gathered by spyware are application files, passwords, email addresses, usage histories, and keystrokes. Some examples of motivations for gathering the data are black mail, financial fraud, id[[entity theft, industrial espionage, market research, and voyeurism.

([[Fair Use]] [[Source]]: [[RFC 4949])

SSH(trade mark)

(N) See: Secure Shell(trade mark).

([[Fair Use]] [[Source]]: [[RFC 4949])

SSL

(I) See: Secure Sockets Layer.

([[Fair Use]] [[Source]]: [[RFC 4949])

SSO

(I) See: system security officer.

([[Fair Use]] [[Source]]: [[RFC 4949])

SSO PIN

(O) /MISSI/ One of two PINs that control access to the functions and stored data of a FORTEZZA PC card. Knowledge of the SSO PIN enables a card user to perform the FORTEZZA functions intended for use by an end user and also the functions intended for use by a MISSI CA. (See: user PIN.)

Shirey Informational Page 291]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

SSO-PIN ORA (SORA)

(O) /MISSI/ A MISSI organizational RA that operates in a mode in which the ORA performs all card management functions and, therefore, requires knowledge of the SSO PIN for FORTEZZA PC cards issued to end users.

([[Fair Use]] [[Source]]: [[RFC 4949])

Standards for Interoperable LAN/MAN Security (SILS)

1. (N) The IEEE 802.10 standards committee. (See: [FP191].)

2. (N) A set of IEEE standards, which has eight parts: (a) Model, including security management, (b) Secure Data Exchange protocol, © Key Management, (d) [has been incorporated in (a)], (e) SDE Over Ethernet 2.0, (f) SDE Sub layer Management, (g) SDE Security Labels, and (h) SDE PICS Conformance. Parts b, e, f, g, and h are incorporated in IEEE Standard 802.10-1998.

([[Fair Use]] [[Source]]: [[RFC 4949])

star property

(N) See: *-property.

([[Fair Use]] [[Source]]: [[RFC 4949])

Star Trek attack

(D) /slang/ An attack that penetrates your system where no attack has ever gone before.

Deprecated Usage: IDOCs SHOULD NOT use this term; it is a joke for Trekkies. (See: Deprecated Usage under “Green Book”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

static

(I) /adjective/ Refers to a cryptographic key or other parameter that is relatively long-lived. (Compare: ephemeral.)

([[Fair Use]] [[Source]]: [[RFC 4949])

steganography

(I) Methods of hiding the existence of a message or other data. This is different than cryptography, which hides the meaning of a message but does not hide the message itself. Examples: For classic, physical methods, see [Kahn]; for modern, digital methods, see [John]. (See: cryptology. Compare: concealment system, digital watermarking.)

([[Fair Use]] [[Source]]: [[RFC 4949])

storage channel

(I) See: covert storage channel.

([[Fair Use]] [[Source]]: [[RFC 4949])

storage key

(I) A cryptographic key used by a device for protecting information that is being maintained in the device, as opposed to protecting information that is being transmitted between devices. (See: cryptographic token, token copy. Compare: traffic key.)

Shirey Informational Page 292]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

stream cipher

(I) An encryption algorithm that breaks plain text into a stream of successive elements (usually, bits) and encrypts the n-th plain text element with the n-th element of a parallel key stream, thus converting the plain text stream into a cipher text stream. [Schn] (See: block cipher.)

([[Fair Use]] [[Source]]: [[RFC 4949])

stream integrity service

(I) A data integrity service that preserves integrity for a sequence of data packets, including both (a) bit-by-bit datagram integrity of each individual packet in the set and (b) packet-by- packet sequential integrity of the set as a whole. (See: data integrity. Compare: datagram integrity service.)

Tutorial: Some internet work applications need only datagram integrity, but others require that an entire stream of packets be protected against insertion, reordering, deletion, and delay: - “Insertion”: The destination receives an additional packet that was not sent by the source. - “Reordering”: The destination receives packets in a different order than that in which they were sent by the source. - “Deletion”: A packet sent by the source is not ever delivered to the intended destination. - “Delay”: A packet is detained for some period of time at a relay, thus hampering and postponing the packet's normal timely delivery from source to destination.

([[Fair Use]] [[Source]]: [[RFC 4949])

strength

1. (I) /cryptography/ A cryptographic mechanism's level of resistance to attacks [R3766]. (See: entropy, strong, work factor.)

2. (N) /Common Criteria/ “Strength of function” is a “qualification of a TOE security function expressing the minimum efforts assumed necessary to defeat its expected security behavior by directly attacking its underlying security mechanisms”: (See: strong.) - Basic: “A level of the TOE strength of function where analysis shows that the function provides adequate protection against casual breach of TOE security by attackers possessing a low attack potential.” - Medium: “… against straightforward or intentional breach … by attackers possessing a mode rate attack potential.” - High: “… against deliberately planned or organized breach … by attackers possessing a high attack potential.”

Shirey Informational Page 293]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

strong

1. (I) /cryptography/ Used to describe a cryptographic algorithm that would require a large amount of computational power to defeat it. (See: strength, work factor, weak key.)

2. (I) /COMPUSEC/ Used to describe a security mechanism that would be difficult to defeat. (See: strength, work factor.)

([[Fair Use]] [[Source]]: [[RFC 4949])

strong authentication

1. (I) An authentication process that uses a cryptographic security mechanism – particularly public-key certificates – to verify the id[[entity claimed for an entity. (Compare: simple authentication.)

2. (O) “Authentication by means of crypto graphically derived credentials.” [X509]

([[Fair Use]] [[Source]]: [[RFC 4949])

subject

1a. (I) A process in a computer system that represents a principal and that executes with the privileges that have been granted to that principal. (Compare: principal, user.)

1b. (I) /formal model/ A system entity that causes information to flow among objects or changes the system state; technically, a process-domain pair. A subject may itself be an object relative to some other subject; thus, the set of subjects in a system is a subset of the set of objects. (See: Bell-LaPadula model, object.)

2. (I) /digital certificate/ The name (of a system entity) that is bound to the data items in a digital certificate; e.g., a DN that is bound to a key in a public-key certificate. (See: X.509.)

([[Fair Use]] [[Source]]: [[RFC 4949])

subject CA

(D) The CA that is the subject of a cross-certificate issued by another CA. [X509] (See: cross-certification.)

Deprecated Term: IDOCs SHOULD NOT use this term because it is not widely known and could be misunderstood. Instead, say “the CA that is the subject of the cross-certificate”.

([[Fair Use]] [[Source]]: [[RFC 4949])

subnet work

(N) An OSI term for a system of packet relays and connecting links that implement OSIRM layer 2 or 3 to provide a communication service that interconnects attached end systems. Usually, the relays are all of the same type (e.g., X.25 packet switches, or interface units in an IEEE 802.3 LAN). (See: gateway, internet, router.)

Shirey Informational Page 294]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

subordinate CA (SCA)

1. (I) A CA whose public-key certificate is issued by another (superior) CA. (See: certification hierarchy. Compare: cross- certification.)

2. (O) /MISSI/ The fourth-highest (i.e., bottom) level of a MISSI certification hierarchy; a MISSI CA whose public-key certificate is signed by a MISSI CA rather than by a MISSI PCA. A MISSI SCA is the administrative authority for a sub unit of an organization, established when it is desirable to organizationally distribute or decentralize the CA service. The term refers both to that authoritative office or role, and to the person who fills that office. A MISSI SCA registers end users and issues their certificates and may also register ORAs, but may not register other CAs. An SCA periodically issues a CRL.

([[Fair Use]] [[Source]]: [[RFC 4949])

subordinate DN

(I) An X.500 DN is subordinate to another X.500 DN if it begins with a set of attributes that is the same as the entire second DN except for the terminal attribute of the second DN (which is usually the name of a CA). For example, the DN <C=FooLand, O=Gov, OU=Treasurer, CN=DukePinchpenny> is subordinate to the DN <C=FooLand, O=Gov, CN=KingFooCA>.

([[Fair Use]] [[Source]]: [[RFC 4949])

subscriber

(I) /PKI/ A user that is registered in a PKI and, therefore, can be named in the “subject” field of a certificate issued by a CA in that PKI. (See: registration, user.)

Usage: This term is needed to distinguish registered users from two other kinds of PKI users: - Users that access the PKI but are not identified to it: For example, a relying party may access a PKI repository to obtain the certificate of some other party. (See: access.) - Users that do not access the PKI: For example, a relying party (see: certificate user) may use a digital certificate that was obtained from a database that is not part of the PKI that issued the certificate.

([[Fair Use]] [[Source]]: [[RFC 4949])

substitution

1. (I) /cryptography/ A method of encryption in which elements of the plain text retain their sequential position but are replaced by elements of cipher text. (Compare: transposition.)

2. (I) /threat action/ See: secondary definition under “falsification”.

Shirey Informational Page 295]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

sub system

(I) A collection of related system components that together perform a system function or deliver a system service.

([[Fair Use]] [[Source]]: [[RFC 4949])

super encryption

(I) An encryption operation for which the plain text input to be transformed is the cipher text output of a previous encryption operation. (Compare: hybrid encryption.)

([[Fair Use]] [[Source]]: [[RFC 4949])

super user

(I) /UNIX/ Synonym for “root”.

([[Fair Use]] [[Source]]: [[RFC 4949])

survivability

(I) The ability of a system to remain in operation or existence despite adverse conditions, including natural occurrences, accidental actions, and attacks. (Compare: availability, reliability.)

([[Fair Use]] [[Source]]: [[RFC 4949])

swIPe

(I) An encryption protocol for IP that provides confidentiality, integrity, and authentication and can be used for both end-to-end and intermediate-hop security. [Ioan] (Compare: IPsec.)

Tutorial: The swIPe protocol is an IP predecessor that is concerned only with encryption mechanisms; policy and key management are handled outside the protocol.

([[Fair Use]] [[Source]]: [[RFC 4949])

syllabary

(N) /encryption/ A list of individual letters, combinations of letters, or syllables, with their equivalent code groups, used for spelling out proper names or other unusual words that are not present in the basic vocabulary (i.e., are not in the code book) of a code used for encryption.

([[Fair Use]] [[Source]]: [[RFC 4949])

symmetric cryptography

(I) A branch of cryptography in which the algorithms use the same key for both of two counterpart cryptographic operations (e.g., encryption and decryption). (See: asymmetric cryptography. Compare: secret-key cryptography.)

Tutorial: Symmetric cryptography has been used for thousands of years [Kahn]. A modern example is AES.

Symmetric cryptography has a disadvantage compared to asymmetric cryptography with regard to key distribution. For example, when Alice wants to ensure confidentiality for data she sends to Bob, she encrypts the data with a key, and Bob uses the same key to decrypt. However, keeping the shared key secret entails both cost

Shirey Informational Page 296]

RFC 4949 Internet Security Glossary, Version 2 August 2007

and risk when the key is distributed to both Alice and Bob. (See: key distribution, key management.)

([[Fair Use]] [[Source]]: [[RFC 4949])

symmetric key

(I) A cryptographic key that is used in a symmetric cryptographic algorithm. (See: symmetric cryptography.)

([[Fair Use]] [[Source]]: [[RFC 4949])

SYN flood

(I) A denial-of-service attack that sends a large number of TCP SYN (synchronize) packets to a host with the intent of disrupting the operation of that host. (See: blind attack, flooding.)

Tutorial: This attack seeks to exploit a vulnerability in the TCP specification or in a TCP implementation. Normally, two hosts use a three-way exchange of packets to establish a TCP connection: (a) host 1 requests a connection by sending a SYN packet to host 2; (b) host 2 replies by sending a SYN-ACK (acknowledgement) packet to host 1; and © host 1 completes the connection by sending an ACK packet to host 2. To attack host 2, host 1 can send a series of TCP SYNs, each with a different phony source address. ([R2827] discusses how to use packet filtering to prevent such attacks from being launched from behind an Internet service provider's aggregation point.) Host 2 treats each SYN as a request from a separate host, replies to each with a SYN-ACK, and waits to receive the matching ACKs. (The attacker can use random or unreachable sources addresses in the SYN packets, or can use source addresses that belong to third parties, that then become secondary victims.)

For each SYN-ACK that is sent, the TCP process in host 2 needs some memory space to store state information while waiting for the matching ACK to be returned. If the matching ACK never arrives at host 2, a timer associated with the pending SYN-ACK will eventually expire and release the space. But if host 1 (or a cooperating group of hosts) can rapidly send many SYNs to host 2, host 2 will need to store state information for many pending SYN- ACKs and may run out of space. This can prevent host 2 from responding to legitimate connection requests from other hosts or even, if there are flaws in host 2's TCP implementation, crash when the available space is exhausted.

([[Fair Use]] [[Source]]: [[RFC 4949])

synchronization

(I) Any technique by which a receiving (decrypting) cryptographic process attains an internal state that matches the transmitting (encrypting) process, i.e., has the appropriate keying material to process the cipher text and is correctly initialized to do so.

Shirey Informational Page 297]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

system

(I) Synonym for “information system”.

Usage: This is a generic definition, and is the one with which the term is used in this Glossary. However, IDOCs that use the term, especially IDOCs that are protocol specifications, SHOULD state a more specific definition. Also, IDOCs that specify security features, services, and assurances need to define which system components and system resources are inside the applicable security perimeter and which are outside. (See: security architecture.)

([[Fair Use]] [[Source]]: [[RFC 4949])

system architecture

(N) The structure of system components, their relationships, and the principles and guidelines governing their design and evolution over time. DoD10] (Compare: security architecture.)

([[Fair Use]] [[Source]]: [[RFC 4949])

system component

1. (I) A collection of system resources that (a) forms a physical or logical part of the system, (b) has specified functions and interfaces, and © is treated (e.g., by policies or specifications) as existing independently of other parts of the system. (See: sub system.)

2. (O) /ITSEC/ An identifiable and self-contained part of a TOE.

Usage: Component is a relative term because components may be nested; i.e., one component of a system may be a part of another component of that system.

Tutorial: Components can be characterized as follows: - A “physical component” has mass and takes up space. - A “logical component” is an abstraction used to manage and coordinate aspects of the physical environment, and typically represents a set of states or capabilities of the system.

([[Fair Use]] [[Source]]: [[RFC 4949])

system entity

(I) An active part of a system – a person, a set of persons (e.g., some kind of organization), an automated process, or a set of processes (see: sub system) – that has a specific set of capabilities. (Compare: subject, user.)

([[Fair Use]] [[Source]]: [[RFC 4949])

system high

(I) The highest security level at which a system operates, or is capable of operating, at a particular time or in a particular environment. (See: system-high security mode.)

Shirey Informational Page 298]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

system-high security mode

(I) A mode of system operation wherein all users having access to the system possess all necessary authorizations (both security clearance and formal access approval) for all data handled by the system, but some users might not have need-to-know for all the data. (See: /system operation/ under “mode”, formal access approval, protection level, security clearance.)

Usage: Usually abbreviated as “system-high mode”. This mode was defined in U.S. DoD policy that applied to system accreditation, but the term is widely used outside the Government.

([[Fair Use]] [[Source]]: [[RFC 4949])

system integrity

1. (I) An attribute or quality “that a system has when it can perform its intended function in a unimpaired manner, free from deliberate or inadvertent unauthorized manipulation.” [C4009, NCS04] (See: recovery, system integrity service.)

2. (D) “Quality of an information system reflecting the logical correctness and reliability of the operating system; the logical completeness of the hardware and software implementing the protection mechanisms; and the consistency of the data structures and occurrence of the stored data.” [from an earlier version of C4009]

Deprecated Definition: IDOCs SHOULD NOT use definition 2 because it mixes several concepts in a potentially misleading way. Instead, IDOCs should use the term with definition 1 and, depending on what is meant, couple the term with additional, more specifically descriptive and informative terms, such as “correctness”, “reliability”, and “data integrity”.

([[Fair Use]] [[Source]]: [[RFC 4949])

system integrity service

(I) A security service that protects system resources in a verifiable manner against unauthorized or accidental change, loss, or destruction. (See: system integrity.)

([[Fair Use]] [[Source]]: [[RFC 4949])

system low

(I) The lowest security level supported by a system at a particular time or in a particular environment. (Compare: system high.)

([[Fair Use]] [[Source]]: [[RFC 4949])

system resource

(I) Data contained in an information system; or a service provided by a system; or a system capacity, such as processing power or communication band width; or an item of system equipment (i.e.,

Shirey Informational Page 299]

RFC 4949 Internet Security Glossary, Version 2 August 2007

hardware, firm ware, software, or documentation); or a facility that houses system operations and equipment. (See: system component.)

([[Fair Use]] [[Source]]: [[RFC 4949])

system security officer (SSO)

(I) A person responsible for enforcement or administration of the security policy that applies to a system. (Compare: manager, operator.)

([[Fair Use]] [[Source]]: [[RFC 4949])

system user

(I) A system entity that consumes a product or service provided by the system, or that accesses and employs system resources to produce a product or service of the system. (See: access, [R2504]. Compare: authorized user, manager, operator, principal, privileged user, subject, subscriber, system entity, unauthorized user.)

Usage: IDOCs that use this term SHOULD state a definition for it because the term is used in many ways and could easily be misunderstood: - This term usually refers to an entity that has been authorized to access the system, but the term sometimes is used without regard for whether access is authorized. - This term usually refers to a living human being acting either personally or in an organizational role. However, the term also may refer to an automated process in the form of hardware, software, or firm ware; to a set of persons; or to a set of processes. - IDOCs SHOULD NOT use the term to refer to a mixed set containing both persons and processes. This exclusion is intended to prevent situations that might cause a security policy to be interpreted in two different and conflicting ways.