GIST v0.7 ― T
“TACACS[+]” to “type unification”

T

- TACACS, - TACACS+ n. 

See: Terminal Access Controller (TAC) Access Control System.

- tailgate vb. 

ISO/IEC 2382-8:1998

To gain unauthorized physical access by following an authorized person through a controlled door.

- tamper vb. 

RFC 2828 (2000)

(I) Make an unauthorized modification in a system that alters the system’s functioning in a way that degrades the security services that the system was intended to provide.

- target n. 

OASIS XACML 2.0 (2005)

The set of decision requests, identified by definitions for resource, subject and action, that a rule, policy or policy set is intended to evaluate.

- Target of Evaluation (TOE) n.

SC 27 SD 6 (2002)

ISO/IEC 15408-1: 1999

An IT product or system and its associated administrator and user guidance documentation that is the subject of an evaluation.

- TCB n. 

See: trusted computing base.

- TCP n. 

See: Transmission Control Protocol.

- TCP/IP n. 

RFC 2828 (2000)

(I) A synonym for Internet Protocol Suite (see: (secondary definition under) Internet), in which the Transmission Control Protocol (TCP) and the Internet Protocol (IP) are important parts.

- TCSEC n. 

See: Trusted Computer System Evaluation Criteria.

- technical control n. 

NIST IR 7298 (2006)

SP 800-53; FIPS 200

technical controls

The security controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system.

- technical non-repudiation n. 

NIST IR 7298 (2006)

SP 800-32

The contribution of public key mechanisms to the provision of technical evidence supporting a non-repudiation security service.

- technology testing n. 

BEM 2002

Testing one or more biometric systems to measure statistical properties (e.g. FAR and FRR) to compare various algorithms and technologies usually achieved by off-line processing. (Compare operational testing; scenario testing.)

- TELNET n. 

RFC 2828 (2000)

(I) A TCP-based, application-layer, Internet Standard protocol [R0854] for remote login from one host to another.

- TEMPEST n. 

RFC 2828 (2000)

(O) A nickname for specifications and standards for limiting the strength of electromagnetic emanations from electrical and electronic equipment and thus reducing vulnerability to eavesdropping. This term originated in the U.S. Department of Defense. [Army, Kuhn, Russ] (See: emanation s security, soft TEMPEST.)

(D) ISDs SHOULD NOT use this term as a synonym for [electromagnetic] emanations security.

NIST IR 7298 (2006)

FIPS 140-2

A name referring to the investigation, study, and control of unintentional compromising emanations from telecommunications and automated information systems equipment.

- template n. 

See: biometric template.

- template aging n. 

iAfB-ICSA 1999

The degree to which biometric data evolves and changes over time, and the process by which templates account for this change.

BEM 2002

The gradual change of a user’s biometric feature(s) which requires periodic updating of the user’s reference template.

- template size n. 

iAfB-ICSA 1999

The amount of computer memory taken up by the biometric data.

- Terminal Access Controller (TAC) Access Control System (TACACS) n. 

RFC 2828 (2000)

(I) A UDP-based authentication and access control protocol [R1492] in which a network access server receives an identifier and password from a remote terminal and passes them to a separate authentication server for verification.

(C) TACACS was developed for ARPANET and has evolved for use in commercial equipment. TACs were a type of network access server computer used to connect terminals to the early Internet, usually using dial-up modem connections. TACACS used centralized authentication servers and served not only network access servers like TACs but also routers and other networked computing devices. TACs are no longer in use, but TACACS+ is. [R1983]

• XTACACS: The name of Cisco Corporation’s implementation, which enhances and extends the original TACACS.
• TACACS+: A TCP-based protocol that improves on TACACS and XTACACS by separating the functions of authentication, authorization, and accounting and by encrypting all traffic between the network access server and authentication server. It is extensible to allow any authentication mechanism to be used with TACACS+ clients.

- TESS n. 

See: The Exponential Encryption System.

- text-dependent system n. 

iAfB-ICSA 1999

A speaker verification system that requires a speaker to say a specific set of numbers or words. (See also: biometric characteristic.)

- text-independent system n. 

iAfB-ICSA 1999

A speaker verification system that creates voiceprints from unconstrained speech and does not require a speaker to say a specific set of numbers or words. (See also: biometric characteristic.)

- text-prompted system n. 

iAfB-ICSA 1999

A speaker verification system that prompts the speaker to say randomly ordered numbers or words. The term challenge-response is also used in a similar way to define text prompting. (See also: biometric characteristic.)

- The Exponential Encryption System (TESS) n. 

RFC 2828 (2000)

(I) A system of separate but cooperating cryptographic mechanisms and functions for the secure authenticated exchange of cryptographic keys, the generation of digital signatures, and the distribution of public keys. TESS employs asymmetric cryptography, based on discrete exponentiation, and a structure of self-certified public keys. [R1824]

- thermal adj. 

iAfB-ICSA 1999

A finger image capture technique that uses a sensor to sense heat from the finger and thus capture a finger image pattern. (See: biometric characteristic.)

- third-party test n. 

iAfB-ICSA 1999

An objective test, independent of a biometric vendor, usually carried out entirely within a test laboratory in controlled environmental conditions.

- threat n. 

ISO/IEC 2382-8:1998

A potential violation of computer security.

• active threat: A threat [of] a deliberate unauthorized change to the state of a data processing system. Example: A threat that would result in modification of messages, insertion of spurious messages, masquerade [attack], or denial of service.
• passive threat: A threat of disclosure of information without changing the state of a data processing system. Example: A threat that would result in the recovery of sensitive information through the interception of data transmitted.

RFC 2828 (2000)

(I) A potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm. (See: attack, threat action, threat consequence.)

(C) That is, a threat is a possible danger that might exploit a vulnerability. A threat can be either intentional (i.e., intelligent; e.g., an individual cracker or a criminal organization) or accidental (e.g., the possibility of a computer malfunctioning, or the possibility of an act of God such as an earthquake, a fire, or a tornado).

(C) In some contexts, such as the following, the term is used narrowly to refer only to intelligent threats:

(N) U.S. Government usage: The technical and operational capability of a hostile entity to detect, exploit, or subvert friendly information systems and the demonstrated, presumed, or inferred intent of that entity to conduct such activity.

BEM 2002

An intentional or unintentional potential event that could compromise the security integrity of the system.

SC 27 SD 6 (2002)

ISO/IEC PDTR 13335-1 (11/2001)

A potential cause of an unwanted incident that may result in harm to a system or organization.

ISO/IEC DTR 15947 (10/2001)

A potential cause of an unwanted incident that may result in harm to an IT system.

ISO/IEC 17799: 2000

A potential cause of an unwanted incident which may result in harm to a system or organization.

NIST IR 7298 (2006)

SP 800-53; CNSSI-4009 Adapted

Any circumstance or event with the potential to adversely impact agency operations (including mission, functions, image, or reputation), agency assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.

FIPS 200; CNSSI-4009 Adapted

Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Also, the potential for a threat-source to successfully exploit a particular information system vulnerability.

IAEG LIAF (2008)

An adversary that is motivated and capable to violate the security of a target and has the capability to mount attacks that will exploit the target’s vulnerabilities.

- threat action n. 

RFC 2828 (2000)

(I) An assault on system security. (See: attack, threat, threat consequence.)

(C) A complete security architecture deals with both intentional acts (i.e. attacks) and accidental events [FIPS31]. Various kinds of threat actions are defined as subentries under threat consequence.

- threat agent n. 

NIST IR 7298 (2006)

SP 800-53

threat agent/source

Either:

1. intent and method targeted at the intentional exploitation of a vulnerability; or
2. a situation and method that may accidentally trigger a vulnerability.

FIPS 200

threat source

The intent and method targeted at the intentional exploitation of a vulnerability or a situation and method that may accidentally trigger a vulnerability.

SP 800-37

threat source

Either:

1. intent and method targeted at the intentional exploitation of a vulnerability; or
2. a situation and method that may accidentally trigger a vulnerability.

Synonymous with threat agent.

- threat analysis, - threat assessment n. 

ISO/IEC 2382-8:1998

threat analysis

An examination of actions and events that might adversely affect a data processing system.

RFC 2828 (2000)

threat analysis

(I) An analysis of the probability of occurrences and consequences of damaging actions to a system.

NIST IR 7298 (2006)

SP 800-27A

threat analysis

The examination of threat sources against system vulnerabilities to determine the threats for a particular system in a particular operational environment.

SP 800-53; CNSSI-4009

threat assessment

Formal description and evaluation of threat to an information system.

- threat consequence n. 

RFC 2828 (2000)

(I) A security violation that results from a threat action. Includes disclosure, deception, disruption, and usurpation. (See: attack, threat, threat action.)

(C) The following subentries describe four kinds of threat consequences, and also list and describe the kinds of threat actions that cause each consequence. Threat actions that are accidental events are marked by “*”.

1. (unauthorized) disclosure (a threat consequence): A circumstance or event whereby an entity gains access to data for which the entity is not authorized. (See: data confidentiality.) The following threat actions can cause unauthorized disclosure:
   1. exposure: A threat action whereby sensitive data is directly released to an unauthorized entity. This includes:
      1. deliberate exposure: Intentional release of sensitive data to an unauthorized entity.
      2. scavenging: Searching through data residue in a system to gain unauthorized knowledge of sensitive data.
      3. * human error: Human action or inaction that unintentionally results in an entity gaining unauthorized knowledge of sensitive data.
      4. * hardware/software error. System failure that results in an entity gaining unauthorized knowledge of sensitive data.
   2. interception: A threat action whereby an unauthorized entity directly accesses sensitive data traveling between authorized sources and destinations. This includes:
      1. theft: Gaining access to sensitive data by stealing a shipment of a physical medium, such as a magnetic tape or disk, that holds the data.
      2. wiretapping (passive): Monitoring and recording data that is flowing between two points in a communication system. (See: wiretapping.)
      3. emanations analysis: Gaining direct knowledge of communicated data by monitoring and resolving a signal that is emitted by a system and that contains the data but is not intended to communicate the data. (See: emanation.)
   3. inference: A threat action whereby an unauthorized entity indirectly accesses sensitive data (but not necessarily the data contained in the communication) by reasoning from characteristics or byproducts of communications. This includes:
      1. traffic analysis: Gaining knowledge of data by observing the characteristics of communications that carry the data. (See: (main Glossary entry for) traffic analysis.)
      2. signals analysis: Gaining indirect knowledge 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.)
   4. intrusion: A threat action whereby an unauthorized entity gains access to sensitive data by circumventing a system’s security protections. This includes:
      1. trespass: Gaining unauthorized physical access to sensitive data by circumventing a system’s protections.
      2. penetration: Gaining unauthorized logical access to sensitive data by circumventing a system’s protections.
      3. reverse engineering: Acquiring sensitive data by disassembling and analyzing the design of a system component.
      4. cryptanalysis: Transforming encrypted data into plaintext without having prior knowledge of encryption parameters or processes. (See: (main Glossary entry for) cryptanalysis.)
2. deception (a threat consequence): A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. The following threat actions can cause deception:
   1. masquerade: A threat action whereby an unauthorized entity gains access to a system or performs a malicious act by posing as an authorized entity. (See: (main Glossary entry for) masquerade attack.)
      1. spoof: Attempt by an unauthorized entity to gain access to a system by posing as an authorized user.
      2. malicious logic: In context of masquerade, any hardware, firmware, or software (e.g., Trojan horse) that appears to perform a useful or desirable function, but actually gains unauthorized access to system resources or tricks a user into executing other malicious logic. (See: (main Glossary entry for) malicious logic.)
   2. falsification: A threat action whereby false data deceives an authorized entity. (See: active wiretapping.)
      1. substitution: Altering or replacing valid data with false data that serves to deceive an authorized entity.
      2. insertion: Introducing false data that serves to deceive an authorized entity.
   3. repudiation: A threat action whereby an entity deceives another by falsely denying responsibility for an act. (See: non-repudiation service, (main Glossary entry for) repudiation.)
      1. false denial of origin: Action whereby the originator of data denies responsibility for its generation.
      2. false denial of receipt: Action whereby the recipient of data denies receiving and possessing the data.
3. disruption (a threat consequence): A circumstance or event that interrupts or prevents the correct operation of system services and functions. (See: denial of service, (main GIST entry for) disruption.) The following threat actions can cause disruption:
   1. incapacitation: A threat action that prevents or interrupts system operation by disabling a system component.
      1. malicious logic: In context of incapacitation, any hardware, firmware, or software (e.g., logic bomb) intentionally introduced into a system to destroy system functions or resources. (See: (main Glossary entry for) malicious logic.)
      2. physical destruction: Deliberate destruction of a system component to interrupt or prevent system operation.
      3. * human error: Action or inaction that unintentionally disables a system component.
      4. * hardware or software error: Error that causes failure of a system component and leads to disruption of system operation.
      5. * natural disaster: Any act of God (e.g., fire, flood, earthquake, lightning, or wind) that disables a system component. [FP031 section 2]
   2. corruption: A threat action that undesirably alters system operation by adversely modifying system functions or data.
      1. tamper: In context of corruption, deliberate alteration of a system’s logic, data, or control information to interrupt or prevent correct operation of system functions.
      2. malicious logic: In context of corruption, any hardware, firmware, or software (e.g., a computer virus) intentionally introduced into a system to modify system functions or data. (See: (main Glossary entry for) malicious logic.)
      3. * human error: Human action or inaction that unintentionally results in the alteration of system functions or data.
      4. * hardware or software error: Error that results in the alteration of system functions or data.
      5. * natural disaster: Any act of God (e.g., power surge caused by lightning) that alters system functions or data. [FP031 section 2]
   3. obstruction: A threat action that interrupts delivery of system services by hindering system operations.
      1. interference: Disruption of system operations by blocking communications or user data or control information.
      2. overload: Hindrance of system operation by placing excess burden on the performance capabilities of a system component. (See: flooding.)
4. usurpation (a threat consequence): A circumstance or event that results in control of system services or functions by an unauthorized entity. The following threat actions can cause usurpation:
   1. misappropriation: A threat action whereby an entity assumes unauthorized logical or physical control of a system resource.
      1. theft of service: Unauthorized use of service by an entity.
      2. theft of functionality: Unauthorized acquisition of actual hardware, software, or firmware of a system component.
      3. theft of data: Unauthorized acquisition and use of data.
   2. misuse: A threat action that causes a system component to perform a function or service that is detrimental to system security.
      1. tamper: In context of misuse, deliberate alteration of a system’s logic, data, or control information to cause the system to perform unauthorized functions or services.
      2. malicious logic: In context of misuse, any hardware, software, or firmware intentionally introduced into a system to perform or control execution of an unauthorized function or service.
      3. violation of permissions: Action by an entity that exceeds the entity’s system privileges by executing an unauthorized function.

- threat source n. 

See: threat agent.

- threshold n., vb.

1. n.

iAfB-ICSA 1999

threshold, decision threshold

The acceptance or rejection of biometric data is dependent on the match score falling above or below the threshold. The threshold is adjustable so that the biometric systemec can be more or less strict, depending on the requirements of any given biometric application.

BEM 2002

A parametric value used to convert a matching score to a decision. A threshold change will usually change both FAR and FRR – as FAR decreases, FRR increases.

JTC 1/SC 37 (2008)

threshold [n.]

Numerical value (or set of values) at which a decision boundary exists.

2. vb.

JTC 1/SC 37 (2006⇒2008)

thresholding threshold (vb.)
cull (vb.)
exclude

Elimination of Eliminate biometric reference identifier(s) associated with biometric reference(s) and/or identifiers for reference probe biometric sample(s) that have failed to attain a level of any type of score.

Note: Score can be quality score, comparison score, etc.

- thresholding n. 

See: threshold (vb.)

- throughput rate n. 

iAfB-ICSA 1999

The number of end users that a biometric system can process within a stated time interval.

- thumbprint n. 

RFC 2828 (2000)

(I) A pattern of curves formed by the ridges on the tip of a thumb. (See: biometric authentication, fingerprint.)

(D) ISDs SHOULD NOT use this term as a synonym for hash result because that meaning mixes concepts in a potentially misleading way.

- ticket n. 

ISO/IEC 2382-8:1998

A representation of one or more access rights that possessor has to an object. Note: The ticket represents an access permission.

RFC 2828 (2000)

(I) A synonym for capability. (See: Kerberos.)

(C) A ticket is usually granted by a centralized access control server (ticket-granting agent) to authorize access to a system resource for a limited time. Tickets have been implemented with symmetric cryptography, but can also be implemented as attribute certificates using asymmetric cryptography.

- time bomb n. 

ISO/IEC 2382-8:1998

A logic bomb to be activated at a predetermined time.

- time-out n. 

OASIS SAML 2.0 (2005)

A period of time after which some condition becomes true if some event has not occurred. For example, a session that is terminated because its state has been inactive for a specified period of time is said to “time out”.

Note: time-out is the noun; time out the verb. (Compare: backup; back up.)

- time stamp n.

SC 27 SD 6 (2002)

ISO/IEC 11770-1: 1996

A time variant parameter which denotes a point in time with respect to a common time reference.

ISO/IEC 9798-1: 1997

A time variant parameter which denotes a point in time with respect to a common reference.

ISO/IEC 11770-3: 1999

A data item which denotes a point in time with respect to a common time reference.

ISO/IEC FDIS 15946-3 (02/2001)

A data item which denotes a point in time with respect to a common reference.

- time-stamp requester n.

SC 27 SD 6 (2002)

ISO/IEC FDIS 18014-1 (02/2002)

An entity which possesses data it wants to be time-stamped. Note: A requester may also be a Trusted Third Party including a time-stamping authority.

- time-stamp token n.

SC 27 SD 6 (2002)

ISO/IEC FDIS 18014-1 (02/2002)

A data structure containing a verifiable cryptographic binding between a data items' representation and a time-value. A time-stamp token may also include additional data items in the binding.

- time-stamp verifier n.

SC 27 SD 6 (2002)

ISO/IEC FDIS 18014-1 (02/2002)

An entity which possesses data and wants to verify that it has a valid time-stamp bound to it. The verification process may be performed by the verified itself or by a Trusted Third Party.

- time-stamping authority (TSA) n.

SC 27 SD 6 (2002)

ISO/IEC 11770-3: 1999

A trusted third party trusted to provide evidence which includes the time when the secure time stamp is generated.

ISO/IEC FDIS 18014-1 (02/2002)

A trusted third party trusted to provide a time stamping service.

- time-stamping service n.

SC 27 SD 6 (2002)

ISO/IEC FDIS 18014-1 (02/2002)

A service providing evidence that a data item existed before a certain point in time. Note: An example is given by adding a time stamp to a data items representation and signing the result.

ISO/IEC 15945: 2002

A service which attests the existence of electronic data at a precise instant of time. Note: Time stamping services are useful and probably indispensable to support long term validation of signatures. They will be defined in a separate document.

- time-variant parameter n.

SC 27 SD 6 (2002)

ISO/IEC 9798-1: 1997, ISO/IEC 11770-2: 1996, ISO/IEC 11770-3: 1999

A data item used to verify that a message is not a replay, such as a random number, a sequence number, or a time stamp.

ISO/IEC 11770-1: 1996

A data item used by an entity to verify that a message is not a replay, such as a random number, a sequence number, or a time stamp.

- timing channel n. 

See: (secondary definition under) covert channel.

- TLS n. 

See: Transport Layer Security. (See: TLSP.)

- TLSP n. 

See: Transport Layer Security Protocol. (See: TLS.)

- TOE n.

See: Target of Evaluation.

- TOE resource n.

SC 27 SD 6 (2002)

ISO/IEC 15408-1: 1999

Anything useable or consumable in the TOE.

- TOE Security Functions (TSF) n.

SC 27 SD 6 (2002)

ISO/IEC 15408-1: 1999

A set consisting of all hardware, software, and firmware of the TOE that must be relied upon for the correct enforcement of the TSP.

- TOE Security Functions Interface (TSFI) n.

SC 27 SD 6 (2002)

ISO/IEC 15408-1: 1999

A set of interfaces, whether interactive (man-machine interface) or programmatic (application programming interface), through which TOE resources are accessed, mediated by the TSF, or information is obtained from the TSF.

- TOE Security Policy (TSP) n.

SC 27 SD 6 (2002)

ISO/IEC 15408-1: 1999

A set of rules that regulate how assets are managed, protected and distributed within a TOE.

- TOE security policy model n.

SC 27 SD 6 (2002)

ISO/IEC 15408-1: 1999

A structured representation of the security policy to be enforced by the TOE.

- token n. 

ISO/IEC 2382-8:1998

identity token

A device used for identity authentication. Examples: Smart card, metal key.

RFC 2828 (2000)

(I) general usage: An object that is used to control access and is passed between cooperating entities in a protocol that synchronizes use of a shared resource. Usually, the entity that currently holds the token has exclusive access to the resource.

(I) authentication usage: A data object or a portable, user-controlled, physical device used to verify an identity in an authentication process. (See: authentication information, dongle.)

(I) cryptographic usage: See: cryptographic token.

(O) SET usage: “A portable device [e.g., smart card or PCMCIA card] specifically designed to store cryptographic information and possibly perform cryptographic functions in a secure manner.” [SET2]

SC 27 SD 6 (2002)

ISO/IEC 9798-1: 1997

A message consisting of data fields relevant to a particular communication and which contains information that has been transformed using a cryptographic technique. [Compare: ticket.]

modonis^IDM (2005)

Definition: A token is any hardware or software that contains credentials related to attributes.

Tokens may take any form, ranging from a digital data set to smart cards or mobile phones.

Tokens can be used for both data/entity authentication (authentication tokens) and authorisation purposes (authorisation tokens).

SCA ISCTAG (2007)

A physical device that carries an individual’s credentials. The device is typically small (for easy transport) and usually employs a variety of physical and/or logical mechanisms to protect against modifying legitimate credentials or producing fraudulent credentials. Examples of tokens include picture ID cards (e.g., state driver’s licenses), smart cards, and USB devices.

IAEG LIAF (2008)

Something that a claimant possesses and controls (typically a key or password) that is used to authenticate the claimant’s identity.

NIST SP 800-63-1 DRAFT (2008)

Something that the claimant possesses and controls (typically a key or password) used to authenticate the claimant’s identity.

Note that IAEG LIAF and NIST SP 800-63 generalize “token” to mean anything possessed by the user and used for authentication not necessarily just a physical “something” that only the user holds. A password would generally be regarded as something that only the user knows. See: (discussion under) authentication.

- token authenticator n.

NIST SP 800-63-1 DRAFT (2008)

The value that is provided to the protocol stack to prove that the claimant possesses and controls the token. Protocol messages sent to the verifier are dependant upon the token authenticator, but they may or may not explicitly contain it.

- token backup n. 

RFC 2828 (2000)

(I) A token management operation that stores sufficient information in a database (e.g., in a CAW) to recreate or restore a security token (e.g., a smart card) if it is lost or damaged.

- token copy n. 

RFC 2828 (2000)

(I) A token management operation that copies all the personality information from one security token to another. However, unlike in a token restore operation, the second token is initialized with its own, different local security values such as PINs and storage keys.

- token management n. 

RFC 2828 (2000)

(I) The process of initializing security tokens (e.g., see: smart card), loading data into the tokens, and controlling the tokens during their life cycle. May include performing key management and certificate management functions; generating and installing PINs; loading user personality data; performing card backup, card copy, and card restore operations; and updating firmware.

- token restore n. 

RFC 2828 (2000)

(I) A token management operation that loads a security token with data for the purpose of recreating (duplicating) the contents previously held by that or another token.

- token storage key n. 

RFC 2828 (2000)

(I) A cryptography key used to protect data that is stored on a security token.

- top CA n. 

RFC 2828 (2000)

(I) A CA that is the highest level (i.e., is the most trusted CA) in a certification hierarchy. (See: root.)

- top-level specification n. 

RFC 2828 (2000)

(I) “A non-procedural description of system behavior at the most abstract level; typically a functional specification that omits all implementation details.” [NCS04] (See: (discussion under) security policy.)

(C) A top-level specification may be descriptive or formal:

• descriptive top-level specification: One that is written in a natural language like English or an informal design notation.
• formal top-level specification: One that is written in a formal mathematical language to enable theorems to be proven that show that the specification correctly implements a set of formal requirements or a formal security model. (See: correctness proof.)

- topology n. 

NIST IR 7298 (2006)

FIPS 201

The physical, non-logical features of a PIV card. A card may have either standard [or mandatory] or enhanced [or optional] topography.

- total risk n. 

NIST IR 7298 (2006)

SP 800-16

The potential for the occurrence of an adverse event if no mitigating action is taken (i.e., the potential for any applicable threat to exploit a system vulnerability).

- tracking cookie n. 

NIST IR 7298 (2006)

SP 800-83

A cookie placed on a user’s computer to track the user’s activity on different Web sites, creating a detailed profile of the user’s behavior.

- traffic analysis n. 

ISO/IEC 2382-8:1998

The inference of information from observation of traffic flow. Example: Analysis of presence, absence, amount, direction, and frequency of traffic.

RFC 2828 (2000)

(I) Inference of information from observable characteristics of data flow(s), even when the data is encrypted or otherwise not directly available. Such characteristics include the identities and locations of the source(s) and destination(s), and the presence, amount, frequency, and duration of occurrence. (See: wiretapping.)

(O) “The inference of information from observation of traffic flows (presence, absence, amount, direction, and frequency).” [I7498 Part 2]

NIST IR 7298 (2006)

SP 800-24

A form of passive attack in which an intruder observes information about calls (although not necessarily the contents of the messages) and makes inferences, e.g. from the source and destination numbers, or frequency and length of the messages.

- traffic flow confidentiality n. 

RFC 2828 (2000)

(I) A data confidentiality service to protect against traffic analysis.

(O) “A confidentiality service to protect against traffic analysis.” [I7498 Part 2]

- traffic padding n. 

ISO/IEC 2382-8:1998

A countermeasure that generates spurious data in transmission media to make traffic analysis or decryption more difficult.

RFC 2828 (2000)

(I) “The generation of spurious instances of communication, spurious data units, and/or spurious data within data units.” [I7498 Part 2]

- trailer n.

SC 27 SD 6 (2002)

ISO/IEC FDIS 9796-2 (12/2001)

String of bits of length one or two octets, concatenated to the end of the recoverable part of the message during message representative production.

- training n. 

See also: awareness, awareness and training program, education, and needs assessment.

NIST IR 7298 (2006)

SP 800-50

IT security training

IT Security Training strives to produce relevant and needed security skills and competencies by practitioners of functional specialties other than IT security (e.g., management, systems design and development, acquisition, auditing). The most significant difference between training and awareness is that training seeks to teach skills, which allow a person to perform a specific function, while awareness seeks to focus an individual’s attention on an issue or set of issues. The skills acquired during training are built upon the awareness foundation, in particular, upon the security basics and literacy material.

SP 800-50

training (information security)

Training strives to produce relevant and needed (information) security skills and competencies.

- training assessment n. 

NIST IR 7298 (2006)

SP 800-16

An evaluation of the training efforts.

- training effectiveness n. 

NIST IR 7298 (2006)

SP 800-16

A measurement of what a given student has learned from a specific course or training event.

- training effectiveness evaluation n. 

NIST IR 7298 (2006)

SP 800-16

Information collected to assist employees and their supervisors in assessing individual students’ subsequent on-the-job performance, to provide trend data to assist trainers in improving both learning and teaching, and to be used in return-on-investment statistics to enable responsible officials to allocate limited resources in a thoughtful, strategic manner among the spectrum of IT security awareness, security literacy, training, and education options for optimal results among the workforce as a whole.

- tranquillity property n. 

See: (secondary definition under) Bell-LaPadula Model.

- transaction n. 

JTC 1/SC 37 (2008)

Instance of buying or selling; exchange or interaction between people; an input message to a computer system dealt with as a single unit of work.

Note: Definition source: Oxford dictionary.

- transient pseudonym n. 

OASIS SAML 2.0 (2005)

A privacy-preserving identifier assigned by an identity provider to identify a principal to a given relying party for a relatively short period of time that need not span multiple sessions.

- transitional product n.

SCA ISCTAG (2007)

As defined in NIST SP 800-73, a product that meets the “Transitional” interface specification. Transitional products can be used as part of a migration strategy by Federal agencies that have already initiated a large-scale deployment of smart cards as identity badges.

- transfers outside TSF control n.

SC 27 SD 6 (2002)

ISO/IEC 15408-1: 1999

Communicating data to entities not under control of the TSF.

- Transmission Control Protocol (TCP) n. 

RFC 2828 (2000)

(I) An Internet Standard protocol [R0793] that reliably delivers a sequence of datagrams (discrete sets of bits) from one computer to another in a computer network. (See: TCP/IP.)

(C) TCP is designed to fit into a layered hierarchy of protocols that support internetwork applications. TCP assumes it can obtain a simple, potentially unreliable datagram service (such as the Internet Protocol) from the lower-layer protocols.

- transponder n.

SCA ISCTAG (2007)

A wireless communications device that detects and responds to an RF signal.

- Transport Layer Security (TLS) n. 

RFC 2828 (2000)

(I) TLS Version 1.0 is an Internet protocol [R2246] based-on and very similar to SSL Version 3.0. (See: TLSP.)

(C) The TLS protocol is misnamed, because it operates well above the transport layer (OSI layer 4).

NIST SP 800-63-1 DRAFT (2008)

An authentication and security protocol widely implemented in browsers and web servers. TLS is defined by [RFC 2246] and [RFC 3546]. TLS is similar to the older Secure Sockets Layer (SSL) protocol, and TLS 1.0 is effectively SSL version 3.1. NIST SP 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations specifies how TLS is to be used in government applications.

- Transport Layer Security Protocol (TLSP) n. 

RFC 2828 (2000)

(I) An end-to-end encryption protocol(ISO Standard 10736) that provides security services at the bottom of OSI layer 4, i.e., directly above layer 3. (See: TLS.)

(C) TLSP evolved directly from the SP4 protocol of SDNS.

- transport mode n. 

RFC 2828 (2000)

(I) IPsec usage: One of two ways to apply IPsec protocols (AH and ESP) to protect communications in which the protection applies to (i.e., the IPsec protocol encapsulates) the packets of upper-layer protocols, the ones that are carried above IP. Compare with tunnel mode.

(C) A transport mode security association is always between two hosts.

- transposition n. 

ISO/IEC 2382-8:1998

Encryption that rearranges bits or characters according to some scheme. Note: The resulting ciphertext is called [a] transposition cipher.

- trap door n. 

ISO/IEC 2382-8:1998

trapdoor

A hidden software or hardware mechanism, usually created for testing and troubleshooting, that may be used to circumvent computer security.

RFC 2828 (2000)

(I) A hidden computer flaw known to an intruder, or a hidden computer mechanism (usually software) installed by an intruder, who can activate the trap door to gain access to the computer without being blocked by security services or mechanisms. (See: back door, Trojan horse.)

- trial n. 

JTC 1/SC 37 (2008)

One element of a test of performance.

- triple DES n. 

RFC 2828 (2000)

(I) A block cipher, based on DES, that transforms each 64-bit plaintext block by applying the Data Encryption Algorithm three successive times, using either two or three different keys, for an effective key length of 112 or 168 bits. [A9052] (See: DES.)

(C) IPsec usage: The algorithm variation proposed for ESP uses a 168-bit key, consisting of three independent 56-bit quantities used by the Data Encryption Algorithm, and a 64-bit initialization value. Each datagram contains an IV to ensure that each received datagram can be decrypted even when other datagrams are dropped or a sequence of datagrams is reordered in transit. [R1851]

NIST IR 7298 (2006)

SP 800-46

An implementation of the Data Encryption Standard (DES) algorithm that uses three passes of the DES algorithm instead of one as used in ordinary DES applications. Triple DES provides much stronger encryption than ordinary DES but it is less secure than AES.

SCA ISCTAG (2007)

A block cipher formed from the Data Encryption Standard (DES) cipher by using it three times.

- triple-wrapped adj. 

RFC 2828 (2000)

(I) S/MIME usage: Data that has been signed with a digital signature, and then encrypted, and then signed again. [R2634]

- Trojan horse n. 

ISO/IEC 2382-8:1998

An apparently harmless program containing malicious logic that allows the unauthorized collection, falsification, or destruction of data.

RFC 2828 (2000)

(I) A computer program that appears to have a useful function, but also has a hidden and potentially malicious function that evades security mechanisms, sometimes by exploiting legitimate authorizations of a system entity that invokes the program.

NIST IR 7298 (2006)

SP 800-61

A non-self-replicating program that seems to have a useful purpose, but in reality has a different, malicious purpose.

- trust n. 

1. (general usage)

modonis^IDM (2005)

Definition: Trust is a quality of a relationship between two or more entities, in which an entity assumes that another entity in the relationship will behave in a fashion agreed beforehand, and in which the first entity is willing to act on this assumption.

Whether or not to trust depends on a natural person’s decision. It is possible, but not necessary that several entities trust each other mutually in a certain context. Trust decisions of legal persons depend on the decisions made by the legal person’s responsible natural persons.

Trust may be limited to one or more specific functions, and may depend on the fulfilment of one or more requirements.

2. (information system usage)

RFC 2828 (2000)

(I) The extent to which someone who relies on a system can have confidence that the system meets its specifications, i.e., that the system does what it claims to do and does not perform unwanted functions. (See: trust level.)

(C) trusted vs. trustworthy: In discussing a system or system process or object, this Glossary (and industry usage) prefers the term trusted to describe a system that operates as expected, according to design and policy. When the trust can also be guaranteed in some convincing way, such as through formal analysis or code review, the system is termed trustworthy; this differs from the ABA Guidelines definition (see: trustworthy system).

3. (PKI usage)

RFC 2828 (2000)

(I) A relationship between a certificate user and a CA in which the user acts according to the assumption that the CA creates only valid digital certificates.

(O) “Generally, an entity can be said to ‘trust’ a second entity when it (the first entity) makes the assumption that the second entity will behave exactly as the first entity expects. This trust may apply only for some specific function. The key role of trust in [X.509] is to describe the relationship between an entity and a [certification] authority; an entity shall be certain that it can trust the certification authority to create only valid and reliable certificates.” [X509]

- trust anchor n. 

NIST IR 7298 (2006)

SP 800-57

A public key and the name of a certification authority that is used to validate the first certificate in a sequence of certificates. The trust anchor public key is used to verify the signature on a certificate issued by a trust anchor certification authority. The security of the validation process depends upon the authenticity and integrity of the trust anchor. Trust anchors are often distributed as self-signed certificates.

- trust chain n. 

RFC 2828 (2000)

(D) ISDs SHOULD NOT use this term as a synonym for certification path because it mixes concepts in a potentially misleading way. (See: trust.)

- trust-file PKI n. 

RFC 2828 (2000)

(I) A non-hierarchical PKI in which each certificate user has a local file (which is used by application software) of public-key certificates that the user trusts as starting points (i.e., roots) for certification paths. (See: hierarchical PKI, mesh PKI, root, web of trust.)

(C) For example, popular browsers are distributed with an initial file of trusted certificates, which often are self-signed certificates. Users can add certificates to the file or delete from it. The file may be directly managed by the user, or the user’s organization may manage it from a centralized server.

- trust hierarchy n. 

RFC 2828 (2000)

(D) ISDs SHOULD NOT use this term as a synonym for certification hierarchy because this term mixes concepts (see: trust) in a potentially misleading way and duplicates the meaning of another, standardized term. (See: trust, web of trust.)

- trust level n. 

RFC 2828 (2000)

(I) A characterization of a standard of security protection to be met by a computer system.

(C) The TCSEC defines eight trust levels. From the lowest to the highest, they are D, C1, C2, B1, B2, B3, and A1. A trust level is based not only on the presence of security mechanisms but also on the use of systems engineering discipline to properly structure the system and implementation analysis to ensure that the system provides an appropriate degree of trust.

- trust list n. 

NIST IR 7298 (2006)

SP 800-32

The collection of trusted certificates used by relying parties to authenticate other certificates.

- trusted n. 

See: (discussion under) trust.

- trusted agent n. 

NIST IR 7298 (2006)

SP 800-32

Entity authorized to act as a representative of an agency in confirming subscriber identification during the registration process. Trusted agents do not have automated interfaces with certification authorities.

- trusted certificate n. 

RFC 2828 (2000)

(I) A certificate upon which a certificate user relies as being valid without the need for validation testing; especially a public-key certificate that is used to provide the first public key in a certification path. (See: certification path, root certificate, validation.)

(C) A trusted public-key certificate might be (a) the root certificate in a hierarchical PKI, (b) the certificate of the CA that issued the user’s own certificate in a mesh PKI, or (c) any certificate accepted by the user in a trust-file PKI.

- trusted channel n.

SC 27 SD 6 (2002)

ISO/IEC 15408-1: 1999

A means by which a TSF and a remote trusted IT product can communicate with necessary confidence to support the TSP.

- trusted computer system n. 

ISO/IEC 2382-8:1998

A data processing system that provides sufficient computer security to allow for concurrent access to data by users with different access rights and to data with different security classification and security categories.

RFC 2828 (2000)

(I) multilevel security usage: “A system that employs sufficient hardware and software assurance measures to allow its use for simultaneous processing of a range of sensitive or classified information.” [NCS04] (See: (discussion under) trust.)

- Trusted Computer System Evaluation Criteria (TCSEC) n. 

RFC 2828 (2000)

(N) A standard for evaluating the security provided by operating systems [CSC001, DOD1]. Informally called the Orange Book because of the color of its cover; first document in the Rainbow Series. (See: Common Criteria, (usage note under) Green Book, Orange Book, trust level.)

- trusted computing base (TCB) n. 

RFC 2828 (2000)

(I) “The totality of protection mechanisms within a computer system, including hardware, firmware, and software, the combination of which is responsible for enforcing a security policy.” [NCS04] (See: (discussion of trusted under) trust.)

- trusted distribution n. 

RFC 2828 (2000)

(I) “A trusted method for distributing the TCB hardware, software, and firmware components, both originals and updates, that provides methods for protecting the TCB from modification during distribution and for detection of any changes to the TCB that may occur.” [NCS04]

- trusted key n. 

RFC 2828 (2000)

(I) A public key upon which a user relies; especially a public key that can be used as the first public key in a certification path. (See: certification path, root key, validation.)

(C) A trusted public key might be (a) the root key in a hierarchical PKI, (b) the key of the CA that issued the user’s own certificate in a mesh PKI, or (c) any key accepted by the user in a trust-file PKI.

- trusted path n. 

RFC 2828 (2000)

(I) COMPUSEC usage: A mechanism by which a computer system user can communicate directly and reliably with the trusted computing base (TCB) and that can only be activated by the user or the TCB and cannot be imitated by untrusted software within the computer. [NCS04]

(I) COMSEC usage: A mechanism by which a person or process can communicate directly with a cryptographic module and that can only be activated by the person, process, or module, and cannot be imitated by untrusted software within the module. [FP140]

SC 27 SD 6 (2002)

ISO/IEC 15408-1: 1999

A means by which a user and a TSF can communicate with necessary confidence to support the TSP.

NIST IR 7298 (2006)

SP 800-53

A mechanism by which a user (through an input device) can communicate directly with the security functions of the information system with the necessary confidence to support the system security policy. This mechanism can only be activated by the user or the security functions of the information system and cannot be imitated by untrusted software.

FIPS 140-2; CNSSI-4009 Adapted

A means by which an operator and a target of evaluation security function can communicate with the necessary confidence to support the target of evaluation security policy.

- trusted process n. 

RFC 2828 (2000)

(I) A system process that has privileges that enable it to affect the state of system security and that can, therefore, through incorrect or malicious execution, violate the system’s security policy. (See: privileged process, (discussion of trusted under) trust.)

- trusted subnetwork n. 

RFC 2828 (2000)

(I) A subnetwork containing hosts and routers that trust each other not to engage in active or passive attacks. (There also is an assumption that the underlying communication channels – e.g., telephone lines, or a LAN – are protected from attack by some means.)

- trusted system n. 

See: (discussion under) trust, trusted computer system, trustworthy system.

- Trusted Systems Interoperability Group (TSIG) n. 

RFC 2828 (2000)

(N) A forum of computer vendors, system integrators, and users devoted to promoting interoperability of trusted computer systems. TSIG meetings are open to all persons who are working in the INFOSEC area.

- trusted third party n.

SC 27 SD 6 (2002)

ISO/IEC 11770-3: 1999, ISO/IEC WD 13888-1 (11/2001), ISO/IEC 14888-2: 1999

A security authority, or its agent, trusted by other entities with respect to security related activities.

ISO/IEC 9798-1: 1997

A security authority or its agent, trusted by other entities with respect to security-related activities. In the context of ISO/IEC 9798, a trusted third party is trusted by a claimant and/or a verifier for the purposes of authentication.

modonis^IDM (2005)

Definition: A trusted third party is an entity trusted by multiple other entities within a specific context and which is alien to their internal relationship.

- trusted timestamp n. 

SC 27 SD 6 (2002)

ISO/IEC WD 13888-1 (11/2001)

A data item with time and date information assured by a trusted time stamping authority.

NIST IR 7298 (2006)

SP 800-32

A digitally signed assertion by a trusted authority that a specific digital object existed at a particular time.

- trusted time stamping authority n.

SC 27 SD 6 (2002)

ISO/IEC WD 13888-1 (11/2001)

A trusted third party trusted to provide evidence which includes the time when the trusted time stamp is generated.

- trustworthiness n. 

NIST IR 7298 (2006)

SP 800-79

The attribute of a person or organization that provides confidence to others of the qualifications, capabilities, and reliability of that entity to perform specific tasks and fulfill assigned responsibilities.

- trustworthy system n. 

RFC 2828 (2000)

(O) ABA usage: “Computer hardware, software, and procedures that: (a) are reasonably secure from intrusion and misuse; (b) provide a reasonably reliable level of availability, reliability, and correct operation; (c) are reasonably suited to performing their intended functions; and (d) adhere to generally accepted security principles.” [ABA] This differs somewhat from other industry usage. (See: (discussion of trusted vs. trustworthy under) trust.)

NIST IR 7298 (2006)

SP 800-32

Computer hardware, software and procedures that –

1. are reasonably secure from intrusion and misuse;
2. provide a reasonable level of availability, reliability, and correct operation;
3. are reasonably suited to performing their intended functions; and
4. adhere to generally accepted security procedures.

- TSF n.

See: TOE Security Functions.

- TSF data n.

SC 27 SD 6 (2002)

ISO/IEC 15408-1: 1999

Data created by and for the TOE, that might affect the operation of the TOE.

- TSF Scope of Control (TSC) n.

SC 27 SD 6 (2002)

ISO/IEC 15408-1: 1999

The set of interactions that can occur with or within a TOE and are subject to the rules of the TSP.

- TSIG n. 

See: Trusted Systems Interoperability Group.

- TSP n.

See: TOE Security Policy.

- tunnel n. 

RFC 2828 (2000)

(I) A communication channel created in a computer network by encapsulating (carrying, layering) a communication protocol’s data packets in (on top of) a second protocol that normally would be carried above, or at the same layer as, the first one. (See: L2TP, VPN.)

(C) Tunneling can involve almost any OSI or TCP/IP protocol layers; for example, a TCP connection between two hosts could conceivably be tunneled through email messages across the Internet. Most often, a tunnel is a logical point-to-point link – i.e., an OSI layer 2 connection – created by encapsulating the layer 2 protocol in a transport protocol (such as TCP), in a network or internetwork layer protocol (such as IP), or in another link layer protocol. Often, encapsulation is accomplished with an extra, intermediate protocol, i.e., a tunneling protocol (such as L2TP) that is layered between the tunneled layer 2 protocol and the encapsulating protocol.

(C) Tunneling can move data between computers that use a protocol not supported by the network connecting them. Tunneling also can enable a computer network to use the services of a second network as though the second network were a set of point-to-point links between the first network’s nodes. (See: virtual private network.)

(O) SET usage: The name of a SET private extension that indicates whether the CA or the payment gateway supports passing encrypted messages to the cardholder through the merchant. If so, the extension lists OIDs of symmetric encryption algorithms that are supported.

- tunnel mode n. 

RFC 2828 (2000)

(I) IPsec usage: One of two ways to apply IPsec protocols (AH and ESP) to protect communications in which the protection applies to (i.e., the IPsec protocol encapsulates) IP packets. Compare with transport mode.

(C) In a tunnel mode security association, each end may be either a host or a gateway. Whenever either end of an IPsec security association is a security gateway, the association is required to be in tunnel mode.

- tunneled password protocol n. 

NIST SP 800-63-1 DRAFT (2008)

A protocol where a password is sent through a protected channel to a cryptographically authenticated verifier. For example, the TLS protocol is often used with a verifier’s public key certificate to (1) authenticate the verifier to the claimant, (2) establish an encrypted session between the verifier and claimant, and (3) transmit the claimant’s password to the verifier. The encrypted TLS session protects the claimant’s password from eavesdroppers.

- two-factor authentication n. 

See: (secondary definition under) authentication, strong authentication

- Twofish n. 

An AES finalist.

- two-person control n. 

RFC 2828 (2000)

(I) The close surveillance and control of a system, process, or materials (especially with regard to cryptography) at all times by a minimum of two appropriately authorized persons, each capable of detecting incorrect and unauthorized procedures with respect to the tasks to be performed and each familiar with established security requirements. (See: dual control, no-lone zone.)

- Type 1 authentication n., - Type 12 authentication n., - Type 13 authentication n., - Type 123 authentication n., - Type 2 authentication n., - Type 23 authentication n., - Type 3 authentication n. 

See: (secondary definitions under) authentication.

- Type I cryptography n. 

RFC 2828 (2000)

(O) A cryptographic algorithm or device approved by NSA for protecting classified information.

- type I error n. 

iAfB-ICSA 1999

In statistics, the rejection of the null hypothesis (default assumption) when it is true. In a biometric system the usual default assumption is that the claimant is genuine, in which case this error corresponds to a false rejection.

- Type II cryptography n. 

RFC 2828 (2000)

(O) A cryptographic algorithm or device approved by NSA for protecting sensitive unclassified information (as specified in section 2315 of Title 10 United States Code, or section 3502(2) of Title 44, United States Code.)

- type II error n. 

iAfB-ICSA 1999

In statistics, the acceptance of the null hypothesis (default assumption) when it is false. In a biometric system the usual default assumption is that the claimant is genuine, in which case this error corresponds to a false acceptance.

- Type III cryptography n. 

RFC 2828 (2000)

(O) A cryptographic algorithm or device approved as a Federal Information Processing Standard.

- type unification n. 

OASIS XACML 2.0 (2005)

The method by which two type expressions are “unified”. The type expressions are matched along their structure. Where a type variable appears in one expression it is then “unified” to represent the corresponding structure element of the other expression, be it another variable or subexpression. All variable assignments must remain consistent in both structures. Unification fails if the two expressions cannot be aligned, either by having dissimilar structure, or by having instance conflicts, such as a variable needs to represent both xs:string and xs:integer. For a full explanation of type unification, please see P. Hancock, “Polymorphic Type Checking”, in Simon L. Peyton Jones, Implementation of Functional Programming Languages, Prentice-Hall 1987, ISBN 0-13-453333-X.