$ risk transference
      (I) See: secondary definition under "risk".

   $ Rivest Cipher #2 (RC2)
      (N) A proprietary, variable-key-length block cipher invented by
      Ron Rivest for RSA Data Security, Inc.

   $ Rivest Cipher #4 (RC4)
      (N) A proprietary, variable-key-length stream cipher invented by
      Ron Rivest for RSA Data Security, Inc.

   $ Rivest Cipher #6 (RC6)
      (N) A symmetric, block cipher with 128-bit or longer key length,
      developed by Ron Rivest for RSA Data Security, Inc. as a candidate
      for the AES.

   $ Rivest-Shamir-Adleman (RSA)
      (N) An algorithm for asymmetric cryptography, invented in 1977 by
      Ron Rivest, Adi Shamir, and Leonard Adleman [RSA78].

      Tutorial: RSA uses exponentiation modulo the product of two large
      prime numbers. The difficulty of breaking RSA is believed to be
      equivalent to the difficulty of factoring integers that are the
      product of two large prime numbers of approximately equal size.

      To create an RSA key pair, randomly choose two large prime
      numbers, p and q, and compute the modulus, n = pq. Randomly choose
      a number e, the public exponent, that is less than n and
      relatively prime to (p-1)(q-1). Choose another number d, the
      private exponent, such that ed-1 evenly divides (p-1)(q-1). The
      public key is the set of numbers (n,e), and the private key is the
      set (n,d).

      It is assumed to be difficult to compute the private key (n,d)
      from the public key (n,e). However, if n can be factored into p
      and q, then the private key d can be computed easily. Thus, RSA
      security depends on the assumption that it is computationally
      difficult to factor a number that is the product of two large
      prime numbers. (Of course, p and q are treated as part of the
      private key, or else are destroyed after computing n.)

      For encryption of a message, m, to be sent to Bob, Alice uses
      Bob's public key (n,e) to compute m**e (mod n) = c. She sends c to
      Bob. Bob computes c**d (mod n) = m. Only Bob knows d, so only Bob
      can compute c**d (mod n) to recover m.

      To provide data origin authentication of a message, m, to be sent
      to Bob, Alice computes m**d (mod n) = s, where (d,n) is Alice's

      private key. She sends m and s to Bob. To recover the message that
      only Alice could have sent, Bob computes s**e (mod n) = m, where
      (e,n) is Alice's public key.

      To ensure data integrity in addition to data origin authentication
      requires extra computation steps in which Alice and Bob use a
      cryptographic hash function h (see: digital signature). Alice
      computes the hash value h(m) = v, and then encrypts v with her
      private key to get s. She sends m and s. Bob receives m' and s',
      either of which might have been changed from the m and s that
      Alice sent. To test this, he decrypts s' with Alice's public key
      to get v'. He then computes h(m') = v". If v' equals v", Bob is
      assured that m' is the same m that Alice sent.

   $ robustness
      (N) See: level of robustness.

   $ role
      1. (I) A job function or employment position to which people or
      other system entities may be assigned in a system. (See: role-
      based access control. Compare: duty, billet, principal, user.)

      2. (O) /Common Criteria/ A pre-defined set of rules establishing
      the allowed interactions between a user and the TOE.

   $ role-based access control
      (I) A form of identity-based access control wherein the system
      entities that are identified and controlled are functional
      positions in an organization or process. [Sand] (See:
      authorization, constraint, identity, principal, role.)

      Tutorial: Administrators assign permissions to roles as needed to
      perform functions in the system. Administrators separately assign
      user identities to roles. When a user accesses the system in an
      identity (for which the user has been registered) and initiates a
      session using a role (to which the user has been assigned), then
      the permissions that have been assigned to the role are available
      to be exercised by the user.

      The following diagram shows that role-based access control
      involves five different relationships: (a) administrators assign
      identities to roles, (b) administrators assign permissions to
      roles, (c) administrators assign roles to roles, (d) users select
      identities in sessions, and (e) users select roles in sessions.
      Security policies may define constraints on these assignments and
      selections.

         (c) Permission Inheritance Assignments (i.e., Role Hierarchy)
                               [Constraints]
                                  +=====+
                                  |     |
                   (a) Identity   v     v  (b) Permission
      +----------+  Assignments  +-------+  Assignments  +----------+
      |Identities|<=============>| Roles |<=============>|Permissions|
      +----------+ [Constraints] +-------+ [Constraints] +----------+
           |   |                   ^   ^
           |   |   +-----------+   |   |       +---------------------+
           |   |   | +-------+ |   |   |       |       Legend        |
           |   +====>|Session|=====+   |       |                     |
           |       | +-------+ |       |       |     One-to-One      |
           |       |    ...   |       |       | =================== |
           |       | +-------+ |       |       |                     |
           +========>|Session|=========+       |     One-to-Many     |
      (d) Identity | +-------+ |  (e) Role     | ==================> |
       Selections  |           | Selections    |                     |
      [Constraints]|  Access   |[Constraints]  |    Many-to-Many     |
                   | Sessions  |               | <=================> |
                   +-----------+               +---------------------+

   $ role certificate
      (I) An organizational certificate that is issued to a system
      entity that is a member of the set of users that have identities
      that are assigned to the same role. (See: role-based access
      control.)

   $ root, root CA
      1. (I) /PKI/ A CA that is directly trusted by an end entity. (See:
      trust anchor, trusted CA.)

      2. (I) /hierarchical PKI/ The CA that is the highest level (most
      trusted) CA in a certification hierarchy; i.e., the authority upon
      whose public key all certificate users base their validation of
      certificates, CRLs, certification paths, and other constructs.
      (See: top CA.)

      Tutorial: The root CA in a certification hierarchy issues public-
      key certificates to one or more additional CAs that form the
      second-highest level. Each of these CAs may issue certificates to
      more CAs at the third-highest level, and so on. To initialize
      operation of a hierarchical PKI, the root's initial public key is
      securely distributed to all certificate users in a way that does
      not depend on the PKI's certification relationships, i.e., by an
      out-of-band procedure. The root's public key may be distributed
      simply as a numerical value, but typically is distributed in a
      self-signed certificate in which the root is the subject. The

      root's certificate is signed by the root itself because there is
      no higher authority in a certification hierarchy. The root's
      certificate is then the first certificate in every certification
      path.

      3. (I) /DNS/ The base of the tree structure that defines the name
      space for the Internet DNS. (See: domain name.)

      4. (O) /MISSI/ A name previously used for a MISSI policy creation
      authority, which is not a root as defined above for general usage,
      but is a CA at the second level of the MISSI hierarchy,
      immediately subordinate to a MISSI policy approving authority.

      5. (O) /UNIX/ A user account (a.k.a. "superuser") that has all
      privileges (including all security-related privileges) and thus
      can manage the system and its other user accounts.

   $ root certificate
      1. (I) /PKI/ A certificate for which the subject is a root. (See:
      trust anchor certificate, trusted certificate.)

      2. (I) /hierarchical PKI/ The self-signed public-key certificate
      at the top of a certification hierarchy.

   $ root key
      (I) /PKI/ A public key for which the matching private key is held
      by a root. (See: trust anchor key, trusted key.)

   $ root registry
      (O) /MISSI/ A name previously used for a MISSI PAA.

   $ ROT13
      (I) See: secondary definition under "Caesar cipher".

   $ router
      1a. (I) /IP/ A networked computer that forwards IP packets that
      are not addressed to the computer itself. (Compare: host.)

      1b. (I) /IPS/ A gateway that operates in the IPS Internet Layer to
      connect two or more subnetworks.

      1c. (N) /OSIRM/ A computer that is a gateway between two networks
      at OSIRM Layer 3 and that relays and directs data packets through
      that internetwork. (Compare: bridge, proxy.)

   $ RSA
      (N) See: Rivest-Shamir-Adleman.

   $ rule
      See: policy rule.

   $ rule-based security policy
      (I) "A security policy based on global rules [i.e., policy rules]
      imposed for all users. These rules usually rely on comparison of
      the sensitivity of the resource being accessed and the possession
      of corresponding attributes of users, a group of users, or
      entities acting on behalf of users." [I7498-2] (Compare: identity-
      based security policy, policy rule, RBAC.)

   $ rules of behavior
      (I) A body of security policy that has been established and
      implemented concerning the responsibilities and expected behavior
      of entities that have access to a system. (Compare: [R1281].)

      Tutorial: For persons employed by a corporation or government, the
      rules might cover such matters as working at home, remote access,
      use of the Internet, use of copyrighted works, use of system
      resources for unofficial purpose, assignment and limitation of
      system privileges, and individual accountability.

   $ S field
      (D) See: Security Level field.

   $ S-BGP
      (I) See: Secure BGP.

   $ S-HTTP
      (I) See: Secure Hypertext Transfer Protocol.

   $ S/Key
      (I) A security mechanism that uses a cryptographic hash function
      to generate a sequence of 64-bit, one-time passwords for remote
      user login. [R1760]

      Tutorial: The client generates a one-time password by applying the
      MD4 cryptographic hash function multiple times to the user's
      secret key. For each successive authentication of the user, the
      number of hash applications is reduced by one. (Thus, an intruder
      using wiretapping cannot compute a valid password from knowledge
      of one previously used.) The server verifies a password by hashing
      the currently presented password (or initialization value) one
      time and comparing the hash result with the previously presented
      password.

   $ S/MIME
      (I) See: Secure/MIME.

   $ SAD
      (I) See: Security Association Database.

   $ safety
      (I) The property of a system being free from risk of causing harm
      (especially physical harm) to its system entities. (Compare:
      security.)

   $ SAID
      (I) See: security association identifier.

   $ salami swindle
      (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".)

   $ 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.

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

   $ 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.

   $ 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.

   $ SAP
      (O) See: special access program.

   $ SASL
      (I) See: Simple Authentication and Security Layer.

   $ SCA
      (I) See: subordinate certification authority.

   $ scavenging
      (I) /threat action/ See: secondary definition under "exposure".

   $ SCI
      (O) See: sensitive compartmented information.

   $ SCIF
      (O) See: sensitive compartmented information facility.

   $ 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.)

   $ 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.

   $ screening router
      (I) Synonym for "filtering router".

   $ 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.

      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".)

   $ SDE
      (N) See: Secure Data Exchange.

   $ SDNS
      (O) See: Secure Data Network System.

   $ SDU
      (N) See: "service data unit" under "protocol data unit".

   $ 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 ciphertext to learn what was
      the plaintext"; sealing is stronger than that. If Alice simply
      encrypts a plaintext P with a public key K to produce ciphertext 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.

   $ 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.

   $ 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.

   $ 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.

   $ 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 identity, and a
         BGP router's identity 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

         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.

   $ Secure Data Exchange (SDE)
      (N) A LAN security protocol defined by the IEEE 802.10 standard.

   $ 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).

   $ secure distribution
      (I) See: trusted distribution.

   $ 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.

   $ Secure Hash Standard (SHS)
      (N) The U.S. Government standard [FP180] that specifies SHA.

   $ 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.

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

   $ 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.

   $ Secure Shell(trademark) (SSH(trademark))
      (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 trademarks or registered trademarks of
      SSH." This Glossary seeks to make readers aware of this trademark
      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.

   $ 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.)

      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 identity to the
      client) and optional client authentication (verifying the client's
      identity 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.

   $ 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".)

   $ 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".)

      -  "Prevention": Impeding or thwarting a potential security
         violation by deploying a countermeasure.
      -  "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.

   $ 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 (c) 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.

   $ 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]

   $ 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

      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 (c) 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]

   $ 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.)

   $ 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.)

   $ 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.

      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, identity authentication/ The (a) "degree
      of confidence in the vetting process used to establish the
      identity of the individual to whom the [identity] 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
      identity registration process; and part "b" is a definition for
      "assurance level" (rather than "security assurance") of an
      identity authentication process. Also, the processes of
      registration and authentication should be defined and designed
      separately to ensure clarity in certification.

   $ 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 countermeasures. [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.

   $ 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.)

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

      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.

   $ 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.

   $ 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.)

   $ 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.)

   $ security controls
      (N) The management, operational, and technical controls
      (safeguards or countermeasures) 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.)

   $ 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.)

      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, firmware, and software in the
      devices. Security doctrine specifies how to achieve those
      conditions. (See: "first law" under "Courtney's laws".)

   $ security domain
      (I) See: domain.

   $ 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".)

   $ 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 lifecycle 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.

   $ 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.

   $ 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.

   $ security gateway
      1. (I) An internetwork 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.

   $ 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.

   $ 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.

   $ security kernel
      (I) "The hardware, firmware, 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]

   $ 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.)

   $ 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.)

      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.

   $ 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.

   $ 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.)

   $ 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.

   $ 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.

   $ 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".)

   $ 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.

   $ 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.)

   $ 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: identity-based
      security policy, policy rule, rule-based security policy, rules of
      behavior. Compare: security architecture, security doctrine,
      security mechanism, security model, [R1281].)

      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

         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.

   $ 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.)

   $ 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.)

   $ 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.)

   $ security-relevant event
      (D) Synonym for "security event".

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

   $ security-sensitive function
      (D) Synonym for "security function".

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

   $ 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

      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]

   $ 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.

   $ 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.

   $ security token
      (I) See: token.

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

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

   $ 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

      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.

   $ 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 wiretapping, 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.)

   $ 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.

   $ 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.)

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

   $ 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.)

   $ 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.)

   $ 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.)

   $ sensitive information
      1. (I) Information for which (a) disclosure, (b) alteration, or
      (c) 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, (c) 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

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

   $ 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.

   $ 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.

   $ 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.)

   $ serial number
      See: certificate serial number.

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

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

   $ service data unit (SDU)
      (N) See: secondary definition under "protocol data unit".

   $ 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.

      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.)

   $ 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.

   $ SET(trademark)
      (O) See: SET Secure Electronic Transaction(trademark).

   $ 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.

   $ 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

      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; (c) 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.

   $ SET Secure Electronic Transaction(trademark) or SET(trademark)
      (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 trademarks of SETCo.
      MasterCard and Visa announced the SET standard on 1 February 1996.

   $ 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(trademark) standard. A later
      memorandum of understanding added American Express and JCB Credit
      Card Company as co-owners of SETCo.

   $ SHA, SHA-1, SHA-2
      (N) See: Secure Hash Algorithm.

   $ shared identity
      (I) See: secondary definition under "identity".

   $ 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.

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

   $ 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.)

   $ 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.

   $ SHS
      (N) See: Secure Hash Standard.

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

   $ 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.)

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

   $ 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. Cryptanalysis
         1b. Traffic Security            1b. Traffic Analysis
         1c. Steganography               1c. Detection and Interception
      2. Electronic Security          2. Electronic Intelligence
         2a. Emission Security           2a. Electronic Reconnaissance
         2b. Counter-Countermeasures     2b. Countermeasures
      ------------------------------  ---------------------------------