| < draft-shirey-secgloss-v2-00.txt | draft-shirey-secgloss-v2-01.txt > | |||
|---|---|---|---|---|
| INTERNET-DRAFT R. W. Shirey | INTERNET-DRAFT R. W. Shirey | |||
| Obsoletes: RFC 2828 (if approved) BBN Technologies | Obsoletes: RFC 2828, FYI 36 BBN Technologies | |||
| Expiration Date: 20 February 2004 20 August 2004 | Expiration Date: 9 September 2005 9 March 2005 | |||
| Internet Security Glossary, Version 2 | Internet Security Glossary, Version 2 | |||
| <draft-shirey-secgloss-v2-00.txt> | <draft-shirey-secgloss-v2-01.txt> | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, I certify that any applicable | By submitting this Internet-Draft, I certify that any applicable | |||
| patent or other IPR claims of which I am aware have been disclosed, | patent or other IPR claims of which I am aware have been disclosed, | |||
| or will be disclosed, and any of which I become aware will be | or will be disclosed, and any of which I become aware will be | |||
| disclosed, in accordance with RFC 3668. | disclosed, in accordance with RFC 3668. | |||
| This document may not be modified, and derivative works of it may | This document may not be modified, and derivative works of it may | |||
| not be created, except to publish it as an RFC and to translate it | not be created, except to publish it as an RFC and to translate it | |||
| into languages other than English. | into languages other than English. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that other | |||
| other groups may also distribute working documents as Internet- | groups may also distribute working documents as Internet-Drafts. | |||
| Drafts. | ||||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than a "work in progress." | material or to cite them other than a "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/1id-abstracts.html | http://www.ietf.org/1id-abstracts.html | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html" | http://www.ietf.org/shadow.html" | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2005). All Rights Reserved. | |||
| Abstract | Abstract | |||
| This Glossary has 1,500 entries that give definitions, abbreviations, | This Glossary provides definitions, abbreviations, and explanations | |||
| and explanations for terminology concerning information system | of terminology for information system security. The 288 pages of | |||
| security. It makes recommendations to improve the clarity of Internet | listings offer recommendations to improve the clarity of Internet | |||
| Standards documents (ISDs) and the ease with which international | Standards documents (ISDs) and to make them more easily understood by | |||
| readers can understand ISDs. Its follow the principles that ISDs | international readers. The recommendations follow the principles that | |||
| should (a) use the same term or definition whenever the same concept | ISDs should (a) use the same term or definition whenever the same | |||
| is mentioned; (b) use terms in their plainest, dictionary sense; (c) | concept is mentioned; (b) use terms in their plainest, dictionary | |||
| use terms that are already well-established in open publications; and | sense; (c) use terms that are already well-established in open | |||
| (d) avoid terms that are proprietary, favor a particular vendor, or | publications; and (d) avoid terms that are proprietary, favor a | |||
| create a bias toward a particular technology or mechanism versus | particular vendor, or create a bias toward a particular technology or | |||
| other, competing techniques that already exist or might be developed. | mechanism versus other, competing techniques that already exist or | |||
| might be developed. | ||||
| Table of Contents | Table of Contents | |||
| Section Page | Section Page | |||
| ------- ---- | ------- ---- | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Format of Entries . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Format of Entries . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.1 Presentation Order . . . . . . . . . . . . . . . . . . . . 4 | 2.1 Presentation Order . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.2 Capitalization and Abbreviation . . . . . . . . . . . . . 4 | 2.2 Capitalization and Abbreviation . . . . . . . . . . . . . 4 | |||
| 2.3 Support for Automated Searching . . . . . . . . . . . . . 5 | 2.3 Support for Automated Searching . . . . . . . . . . . . . 5 | |||
| 2.4 Definition Type and Context . . . . . . . . . . . . . . . 5 | 2.4 Definition Type and Context . . . . . . . . . . . . . . . 5 | |||
| 2.5 Explanatory Notes . . . . . . . . . . . . . . . . . . . . 5 | 2.5 Explanatory Notes . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.6 Cross-References . . . . . . . . . . . . . . . . . . . . . 5 | 2.6 Cross-References . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.7 Trademarks . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.7 Trademarks . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.8 The New Punctuation . . . . . . . . . . . . . . . . . . . 6 | 2.8 The New Punctuation . . . . . . . . . . . . . . . . . . . 6 | |||
| 3. Types of Definitions . . . . . . . . . . . . . . . . . . . . . 6 | 3. Types of Entries . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3.1 Type "I": Recommended Definition with Internet Basis . . . 6 | 3.1 Type "I": Recommended Definitions of Internet Origin . . . 6 | |||
| 3.2 Type "N": Recommended Definition with Non-Internet Basis . 7 | 3.2 Type "N": Recommended Definitions of Non-Internet Origin . 7 | |||
| 3.3 Type "O": Other Definitions. . . . . . . . . . . . . . . . 7 | 3.3 Type "O": Other Terms and Definitions to be Noted . . . . 7 | |||
| 2.4 Type "D": Deprecated Definitions . . . . . . . . . . . . . 7 | 3.4 Type "D": Deprecated Terms and Definitions . . . . . . . . 7 | |||
| 2.5 Definition Substitutions . . . . . . . . . . . . . . . . . 7 | 3.5 Definition Substitutions . . . . . . . . . . . . . . . . . 7 | |||
| 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 5. Informative References . . . . . . . . . . . . . . . . . . . 276 | 5. Informative References . . . . . . . . . . . . . . . . . . . . 297 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 293 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 315 | |||
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 293 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 315 | |||
| 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 293 | 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 315 | |||
| 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 293 | 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 315 | |||
| 1. Introduction | 1. Introduction | |||
| This Glossary provides an internally consistent and self-contained | This Glossary provides an internally consistent and self-contained | |||
| set of terms, abbreviations, and definitions -- supported by | set of terms, abbreviations, and definitions -- supported by | |||
| explanations, recommendations, and references -- for terminology that | explanations, recommendations, and references -- for terminology that | |||
| concerns information system security. The intent of this Glossary is | concerns information system security. The intent of this Glossary is | |||
| to improve the comprehensibility of Internet Standards documents | to improve the comprehensibility of Internet Standards documents | |||
| (ISDs) -- i.e., RFCs, Internet-Drafts, and other material produced as | (ISDs) -- i.e., RFCs, Internet-Drafts, and other material produced as | |||
| part of the Internet Standards Process [R2026] -- and of all other | part of the Internet Standards Process (RFC 2026) -- and other | |||
| Internet-related material, too. A few non-security, networking terms | Internet-related discourse. A few non-security, networking terms are | |||
| are included to make the Glossary self-contained, but more complete | included to make the Glossary self-contained, but more complete | |||
| glossaries of networking terms are available elsewhere [A1523, F1037, | glossaries of networking terms are available elsewhere [A1523, F1037, | |||
| R1208, R1983]. | R1208, R1983]. | |||
| This Glossary supports the goals of the Internet Standards Process: | This Glossary supports the goals of the Internet Standards Process: | |||
| o Clear, Concise, Easily Understood Documentation | o Clear, Concise, Easily Understood Documentation | |||
| This Glossary seeks to improve comprehensibility of security- | This Glossary seeks to improve comprehensibility of security- | |||
| related content of ISDs. That requires wording to be clear and | related content of ISDs. That requires wording to be clear and | |||
| understandable, and requires the set of security-related terms and | understandable, and requires the set of security-related terms and | |||
| skipping to change at page 3, line 46 ¶ | skipping to change at page 3, line 46 ¶ | |||
| Just as Internet Standard (STD) protocols should operate | Just as Internet Standard (STD) protocols should operate | |||
| effectively, ISDs should use terminology accurately, precisely, | effectively, ISDs should use terminology accurately, precisely, | |||
| and unambiguously to enable standards to be implemented correctly. | and unambiguously to enable standards to be implemented correctly. | |||
| o Prior Implementation and Testing | o Prior Implementation and Testing | |||
| Just as STD protocols require demonstrated experience and | Just as STD protocols require demonstrated experience and | |||
| stability before adoption, ISDs need to use well-established | stability before adoption, ISDs need to use well-established | |||
| language. Using terms in their plainest, dictionary sense (when | language. Using terms in their plainest, dictionary sense (when | |||
| appropriate) helps to ensure international understanding. ISDs | appropriate) helps to ensure international understanding. ISDs | |||
| need to avoid using private, made-up terms in place of generally- | need to avoid using private, made-up terms in place of generally | |||
| accepted terms from open publications. ISDs need to avoid | accepted terms from open publications. ISDs need to avoid | |||
| substituting new definitions that conflict with established ones. | substituting new definitions that conflict with established ones. | |||
| ISDs need to avoid using "cute" synonyms (e.g., see: Green Book), | ISDs need to avoid using "cute" synonyms (e.g., see: Green Book), | |||
| because no matter how popular a nickname may be in one community, | because no matter how popular a nickname may be in one community, | |||
| it is likely to cause confusion in another. | it is likely to cause confusion in another. | |||
| o Openness, Fairness, and Timeliness | o Openness, Fairness, and Timeliness | |||
| ISDs need to avoid terms that are proprietary or otherwise favor a | ISDs need to avoid terms that are proprietary or otherwise favor a | |||
| particular vendor, or that create a bias toward a particular | particular vendor, or that create a bias toward a particular | |||
| skipping to change at page 5, line 17 ¶ | skipping to change at page 5, line 17 ¶ | |||
| Each entry is preceded by a dollar sign ($) and a space. This | Each entry is preceded by a dollar sign ($) and a space. This | |||
| makes it possible to find the defining entry for an item "X" by | makes it possible to find the defining entry for an item "X" by | |||
| searching for the character string "$ X", without stopping at | searching for the character string "$ X", without stopping at | |||
| entries in which "X" is used in explanations. | entries in which "X" is used in explanations. | |||
| 2.4 Definition Type and Context | 2.4 Definition Type and Context | |||
| Each entry is preceded by a character -- I, N, O, or D -- enclosed | Each entry is preceded by a character -- I, N, O, or D -- enclosed | |||
| in parentheses, to indicate the type of definition (as is | in parentheses, to indicate the type of definition (as is | |||
| explained further in Section 3): | explained further in Section 3): | |||
| - "I" for a RECOMMENDED term or definition of Internet origin. | - "I" for a RECOMMENDED term or definition of Internet origin. | |||
| - "N" if RECOMMENDED but not of Internet origin. | - "N" if RECOMMENDED but not of Internet origin. | |||
| - "O" for a term or definition that is NOT recommended for use in | - "O" for a term or definition that is NOT recommended for use in | |||
| ISDs but is something that authors of Internet documents need | ISDs but is something that authors of Internet documents should | |||
| to know about. | know about. | |||
| - "D" for a term or definition that is deprecated and SHOULD NOT | - "D" for a term or definition that is deprecated and SHOULD NOT | |||
| be used in Internet documents. | be used in Internet documents. | |||
| If a definition is valid only in a specific context (e.g., | If a definition is valid only in a specific context (e.g., | |||
| "baggage"), that context is shown immediately following the | "baggage"), that context is shown immediately following the | |||
| definition type and is enclosed by a pair of slash symbols (/). If | definition type and is enclosed by a pair of slash symbols (/). If | |||
| the definition is valid only for specific parts of speech, that is | the definition is valid only for specific parts of speech, that is | |||
| shown in the same way (e.g., "archive). | shown in the same way (e.g., "archive). | |||
| 2.5 Explanatory Notes | 2.5 Explanatory Notes | |||
| Some entries have explanatory text that is introduced by one or | Some entries have explanatory text that is introduced by one or | |||
| more of the following keywords: | more of the following keywords: | |||
| - Deprecated Abbreviation (e.g., "EE", "H field", "W3") | - Deprecated Abbreviation (e.g., "EE", "H field", "W3") | |||
| - Deprecated Definition (e.g., "digital certification") | - Deprecated Definition (e.g., "digital certification") | |||
| - Deprecated Usage (e.g., "authenticate") | - Deprecated Usage (e.g., "authenticate") | |||
| - Deprecated Term (e.g., "certificate authority") | - Deprecated Term (e.g., "certificate authority") | |||
| - Pronunciation (e.g., "*-property") | - Pronunciation (e.g., "*-property") | |||
| - Derivation (e.g., "discretionary access control") | - Derivation (e.g., "discretionary access control") | |||
| - Tutorial (e.g., "accreditation") | - Tutorial (e.g., "accreditation") | |||
| - Example (e.g., "back door") | - Example (e.g., "back door") | |||
| - Usage (e.g., "access") | - Usage (e.g., "access") | |||
| Explanatory text in this Glossary MAY be reused in other ISDs. | Explanatory text in this Glossary MAY be reused in other ISDs. | |||
| However, such text is not intended to authoritatively supersede | However, such text is not intended to authoritatively supersede | |||
| text of an ISD in which the Glossary entry is already used. | text of an ISD in which the Glossary entry is already used. | |||
| 2.6 Cross-References | 2.6 Cross-References | |||
| Some entries contain a parenthetical remark of the form "(See: | Some entries contain a parenthetical remark of the form "(See: | |||
| X)", where X is a list one of more related Glossary entries. Some | X.)", where X is a list one of more related Glossary entries. Some | |||
| entries contain a remark of the form "(Compare: X)", where X is a | entries contain a remark of the form "(Compare: X)", where X is a | |||
| list of other entries that either are antonyms or differ in some | list of other entries that either are antonyms or differ in some | |||
| other manner worth observing. | other manner worth noting. | |||
| 2.7 Trademarks | 2.7 Trademarks | |||
| All servicemarks and trademarks that appear in this Glossary are | All servicemarks and trademarks that appear in this Glossary are | |||
| used in an editorial fashion and to the benefit of the mark owner, | used in an editorial fashion and to the benefit of the mark owner, | |||
| without any intention of infringement. | without any intention of infringement. | |||
| 2.8 The New Punctuation | 2.8 The New Punctuation | |||
| This Glossary uses the "new" or "logical" punctuation style that | This Glossary uses the "new" or "logical" punctuation style | |||
| is favored by computer programmers, as described in [Raym]: | favored by computer programmers, as described by Raymond [Raym]: | |||
| Programmers use pairs of quotation marks the same way they use | Programmers use pairs of quotation marks the same way they use | |||
| pairs of parentheses, i.e., as balanced delimiters. For example, | pairs of parentheses, i.e., as balanced delimiters. For example, | |||
| if " Alice sends" is a phrase, and so are "Bill receives" and "Eve | if "Alice sends" is a phrase, and so are "Bill receives" and "Eve | |||
| listens", then a programmer would write the following sentence: | listens", then a programmer would write the following sentence: | |||
| "Alice sends", "Bill receives", and "Eve listens". | "Alice sends", "Bill receives", and "Eve listens". | |||
| According to standard American usage, the punctuation in that | According to standard American usage, the punctuation in that | |||
| sentence is incorrect; the continuation commas and the final | sentence is incorrect; the continuation commas and the final | |||
| period should go inside the string quotes, like this: | period should go inside the string quotes, like this: | |||
| "Alice sends," "Bill receives," and "Eve listens." | "Alice sends," "Bill receives," and "Eve listens." | |||
| skipping to change at page 6, line 48 ¶ | skipping to change at page 6, line 48 ¶ | |||
| Then delete one line from the file by typing "dd." | Then delete one line from the file by typing "dd." | |||
| However, in the vi language, the dot character repeats the last | However, in the vi language, the dot character repeats the last | |||
| command accepted. So, if a reader entered "dd.", two lines would | command accepted. So, if a reader entered "dd.", two lines would | |||
| be deleted instead of one. | be deleted instead of one. | |||
| Similarly, use of standard American punctuation might cause | Similarly, use of standard American punctuation might cause | |||
| misunderstanding in entries in this Glossary. Thus, the new | misunderstanding in entries in this Glossary. Thus, the new | |||
| punctuation is used here, and we recommend it for ISDs. | punctuation is used here, and we recommend it for ISDs. | |||
| 3. Types of Definition | 3. Types of Entries | |||
| Each entry in this Glossary is marked as type I, N, O, or D: | Each entry in this Glossary is marked as type I, N, O, or D: | |||
| 3.1 Type "I": Recommended Term or Definition with Internet Basis | 3.1 Type "I": Recommended Definitions of Internet Origin | |||
| The marking "I" indicates two things: | The marking "I" indicates two things: | |||
| - Origin: "I" (as opposed to "N") means either that the Internet | - Origin: "I" (as opposed to "N") means either that the Internet | |||
| Standards Process or Internet community is authoritative for | Standards Process or Internet community is authoritative for | |||
| the definition *or* that the term is sufficiently generic that | the definition *or* that the term is sufficiently generic that | |||
| this Glossary can freely state a definition without | this Glossary can freely state a definition without | |||
| contradicting a non-Internet authority (e.g., "attack"). | contradicting a non-Internet authority (e.g., "attack"). | |||
| - Recommendation: "I" (as opposed to "O") means that the term and | - Recommendation: "I" (as opposed to "O") means that the term and | |||
| definition are RECOMMENDED for use in ISDs. However, some "I" | definition are RECOMMENDED for use in ISDs. However, some "I" | |||
| entries may be accompanied by a "Usage" note that states a | entries may be accompanied by a "Usage" note that states a | |||
| limitation (e.g., "certification"), and ISDs SHOULD NOT use the | limitation (e.g., "certification"), and ISDs SHOULD NOT use the | |||
| defined term outside that limited context. | defined term outside that limited context. | |||
| Many "I" entries are proper nouns (e.g., "Internet Protocol") for | Many "I" entries are proper nouns (e.g., "Internet Protocol") for | |||
| which the definition is intended only to provide basic | which the definition is intended only to provide basic | |||
| information; i.e., the authoritative definition of such terms is | information; i.e., the authoritative definition of such terms is | |||
| found elsewhere. For a proper noun described as an "Internet | found elsewhere. For a proper noun described as an "Internet | |||
| protocol", please refer to the current edition of "Internet | protocol", please refer to the current edition of "Internet | |||
| Official Protocol Standards" (STD 1) for the standardization | Official Protocol Standards" (Standard 1) for the standardization | |||
| status of the protocol. | status of the protocol. | |||
| 3.2 Type "N": Recommended Term or Definition with Non-Internet Basis | 3.2 Type "N": Recommended Definitions of Non-Internet Origin | |||
| The marking "N" indicates two things: | The marking "N" indicates two things: | |||
| - Origin: "N" (as opposed to "I") means that the entry has a non- | - Origin: "N" (as opposed to "I") means that the entry has a non- | |||
| Internet basis or origin. | Internet basis or origin. | |||
| - Recommendation: "N" (as opposed to "O") means that the term and | - Recommendation: "N" (as opposed to "O") means that the term and | |||
| definition are RECOMMENDED for use in ISDs, if they are needed | definition are RECOMMENDED for use in ISDs, if they are needed | |||
| at all in ISDs. Many of these entries are accompanied by a | at all in ISDs. Many of these entries are accompanied by a | |||
| label that states a context (e.g., "package") or a note that | label that states a context (e.g., "package") or a note that | |||
| states a limitation (e.g., "data integrity"), and ISDs SHOULD | states a limitation (e.g., "data integrity"), and ISDs SHOULD | |||
| NOT use the defined term outside that context or limit. Some of | NOT use the defined term outside that context or limit. Some of | |||
| the contexts are rarely if ever expected to occur in an ISD | the contexts are rarely if ever expected to occur in an ISD | |||
| (e.g., see: baggage). In those cases, the listing exists to | (e.g., see: baggage). In those cases, the listing exists to | |||
| make Internet authors aware of the non-Internet usage so that | make Internet authors aware of the non-Internet usage so that | |||
| they can avoid conflicts with non-Internet documents. | they can avoid conflicts with non-Internet documents. | |||
| 3.3 Type "O": Other Terms and Definitions To Be Noted | 3.3 Type "O": Other Terms and Definitions To Be Noted | |||
| The marking "O" means that the definition has a non-Internet basis | The marking "O" means that the definition is of non-Internet | |||
| and SHOULD NOT be used in ISDs *except* in cases where the term is | origin and SHOULD NOT be used in ISDs *except* in cases where the | |||
| specifically identified as non-Internet. | term is specifically identified as non-Internet. | |||
| For example, an ISD might mention "BCA" (see: brand certification | For example, an ISD might mention "BCA" (see: brand certification | |||
| authority) or "baggage" as an example of some concept; in that | authority) or "baggage" as an example of some concept; in that | |||
| case, the document should specifically say "SET(trademark) BCA" or | case, the document should specifically say "SET(trademark) BCA" or | |||
| "SET(trademark) baggage" and include the definition of the term. | "SET(trademark) baggage" and include the definition of the term. | |||
| 3.4 Type "D": Deprecated Terms and Definitions | 3.4 Type "D": Deprecated Terms and Definitions | |||
| If this Glossary recommends that an term or definition SHOULD NOT | If this Glossary recommends that a term or definition SHOULD NOT | |||
| be used in ISDs, then the entry is marked as type "D", and a | be used in ISDs, then the entry is marked as type "D", and a | |||
| "Deprecated Term", "Deprecated Definition", or "Deprecated Usage" | "Deprecated Term", "Deprecated Definition", or "Deprecated Usage" | |||
| explanatory note is provided. | explanatory note is provided. | |||
| 3.5 Definition Substitutions | 3.5 Definition Substitutions | |||
| Some terms have a definition published by a non-Internet authority | Some terms have a definition published by a non-Internet authority | |||
| -- government (e.g., "object reuse"), industry (e.g., "Secure Data | -- government (e.g., "object reuse"), industry (e.g., "Secure Data | |||
| Exchange"), national authority (e.g., "Data Encryption Standard"), | Exchange"), national authority (e.g., "Data Encryption Standard"), | |||
| or international body (e.g., "data confidentiality") -- that is | or international body (e.g., "data confidentiality") -- that is | |||
| skipping to change at page 8, line 28 ¶ | skipping to change at page 8, line 28 ¶ | |||
| exchange") or explanations, using other terms that are defined in | exchange") or explanations, using other terms that are defined in | |||
| this Glossary. In those cases, this Glossary marks the entry "O", | this Glossary. In those cases, this Glossary marks the entry "O", | |||
| and provides an "I" or "N" entry that precedes, and is intended to | and provides an "I" or "N" entry that precedes, and is intended to | |||
| supersede, the "O" entry. | supersede, the "O" entry. | |||
| In some cases where this Glossary provides a definition to | In some cases where this Glossary provides a definition to | |||
| supersede an "O" definition, the substitute is intended to subsume | supersede an "O" definition, the substitute is intended to subsume | |||
| the meaning of the "O" entry and not conflict with it. For the | the meaning of the "O" entry and not conflict with it. For the | |||
| term "security service", for example, the "O" definition deals | term "security service", for example, the "O" definition deals | |||
| narrowly with only communication services provided by layers in | narrowly with only communication services provided by layers in | |||
| the OSI model and is inadequate for the full range of ISD usage, | the OSIRM and is inadequate for the full range of ISD usage, while | |||
| while the new "I" definition provided by this Glossary can be used | the new "I" definition provided by this Glossary can be used in | |||
| in more situations and for more kinds of service. However, the "O" | more situations and for more kinds of service. However, the "O" | |||
| definition is also listed so that ISD authors will be aware of the | definition is also listed so that ISD authors will be aware of the | |||
| context in which the term is used more narrowly. | context in which the term is used more narrowly. | |||
| When making substitutions, this Glossary attempts to avoid | When making substitutions, this Glossary attempts to avoid | |||
| contradicting any non-Internet authority. Still, terminology | contradicting any non-Internet authority. Still, terminology | |||
| differs between the standards of the American Bar Association, | differs between authorities such as the American Bar Association, | |||
| OSI, SET, the U.S. DoD, and other authorities; and this Glossary | OSI, SET, the U.S. DoD, and other authorities; and this Glossary | |||
| probably is not exactly aligned with any of them. | probably is not exactly aligned with any of them. | |||
| 4. Definitions | 4. Definitions | |||
| $ *-property | $ *-property | |||
| (N) Synonym for "confinement property" in the context of the Bell- | (N) Synonym for "confinement property" in the context of the Bell- | |||
| LaPadula model. Pronunciation: star property. | LaPadula model. Pronunciation: star property. | |||
| $ 3DES | $ 3DES | |||
| See: Triple Data Encryption Algorithm. | (N) See: Triple Data Encryption Algorithm. | |||
| $ A1 computer system | $ A1 computer system | |||
| (O) See: TCSEC. | (O) /TCSEC/ See: Tutorial under "Trusted Computer System | |||
| Evaluation Criteria". | ||||
| $ AA | $ AA | |||
| See: attribute authority. | See: attribute authority. | |||
| $ ABA Guidelines | $ ABA Guidelines | |||
| (N) "American Bar Association (ABA) Digital Signature Guidelines" | (N) "American Bar Association (ABA) Digital Signature Guidelines" | |||
| [ABA], a framework of legal principles for using digital | [ABA], a framework of legal principles for using digital | |||
| signatures and digital certificates in electronic commerce. | signatures and digital certificates in electronic commerce. | |||
| $ Abstract Syntax Notation One (ASN.1) | $ Abstract Syntax Notation One (ASN.1) | |||
| (N) A standard for describing data objects. [Larm, X680] (See: | (N) A standard for describing data objects. [Larm, X680] (See: | |||
| CMS.) | CMS.) | |||
| Usage: This term is often incorrectly used to refer to BER. | Deprecated Usage: The term "ASN.1" can be used narrowly to | |||
| describe the notation or language called "Abstract | ||||
| Syntax Notation One", or can be used more broadly to | ||||
| encompass the notation, its associated encoding rules | ||||
| (see: BER), and software tools that assist in its use. | ||||
| Tutorial: OSIRM defines computer network functionality in layers. | Tutorial: OSIRM defines computer network functionality in layers. | |||
| Protocols and data objects at higher layers are abstractly defined | Protocols and data objects at higher layers are abstractly defined | |||
| to be implemented using protocols and data objects from lower | to be implemented using protocols and data objects from lower | |||
| layers. A higher layer may define transfers of abstract objects | layers. A higher layer may define transfers of abstract objects | |||
| between computers, and a lower layer may define those transfers | between computers, and a lower layer may define those transfers | |||
| concretely as strings of bits. Syntax is needed to specify data | concretely as strings of bits. Syntax is needed to specify data | |||
| formats of abstract objects, and encoding rules are needed to | formats of abstract objects, and encoding rules are needed to | |||
| transform abstract objects into bit strings at lower layers. OSI | transform abstract objects into bit strings at lower layers. OSI | |||
| standards use ASN.1 for those specifications and use various | standards use ASN.1 for those specifications and use various | |||
| skipping to change at page 9, line 51 ¶ | skipping to change at page 9, line 56 ¶ | |||
| In ASN.1, formal names are written without spaces, and separate | In ASN.1, formal names are written without spaces, and separate | |||
| words in a name are indicated by capitalizing the first letter of | words in a name are indicated by capitalizing the first letter of | |||
| each word except the first word. For example, the name of a CRL is | each word except the first word. For example, the name of a CRL is | |||
| "certificateRevocationList". | "certificateRevocationList". | |||
| $ ACC | $ ACC | |||
| (I) See: access control center. | (I) See: access control center. | |||
| $ acceptable risk | $ acceptable risk | |||
| (I) A risk that is understood and tolerated by a system's | (I) A risk that is understood and tolerated by a system's user, | |||
| accreditor, usually because the cost or difficulty of implementing | operator, owner, or accreditor, usually because the cost or | |||
| an effective countermeasure for the associated vulnerability | difficulty of implementing an effective countermeasure for the | |||
| exceeds the expectation of loss. (See: adequate security, (second | associated vulnerability exceeds the expectation of loss. (See: | |||
| law under) Courtney's laws.) | adequate security, "second law" under "Courtney's laws".) | |||
| $ access | $ access | |||
| 1. (I) The ability and means to communicate with or otherwise | 1. (I) The ability and means to communicate with or otherwise | |||
| interact with a system to use system resources either to handle | interact with a system to use system resources either to handle | |||
| information or to gain knowledge of the information the system | information or to gain knowledge of the information the system | |||
| contains. (Compare: handle.) | contains. (Compare: handle.) | |||
| Usage: The definition is intended to include all types of | Usage: The definition is intended to include all types of | |||
| communication with a system, including one-way communication in | communication with a system, including one-way communication in | |||
| either direction. In actual practice, however, entities that are | either direction. In actual practice, however, passive users might | |||
| outside a security perimeter and can receive output from the | be treated as not having "access" and, therefore, be exempt from | |||
| system but cannot provide input or otherwise directly interact | most requirements of the system's security policy. (See: "passive | |||
| with the system, might be treated as not having "access" (and, | user" under "user".) | |||
| therefore, be exempt from security policy requirements, such as | ||||
| the need for a security clearance). | ||||
| 2. (O) /formal model/ "A specific type of interaction between a | 2. (O) /formal model/ "A specific type of interaction between a | |||
| subject and an object that results in the flow of information from | subject and an object that results in the flow of information from | |||
| one to the other." [NCS04] | one to the other." [NCS04] | |||
| $ Access Certificate for Electronic Services (ACES) | $ Access Certificate for Electronic Services (ACES) | |||
| (O) A PKI operated by the U.S. Government's General Services | (O) A PKI operated by the U.S. Government's General Services | |||
| Administration in cooperation with industry partners. (See: CAM.) | Administration in cooperation with industry partners. (See: CAM.) | |||
| $ access control | $ access control | |||
| skipping to change at page 10, line 56 ¶ | skipping to change at page 11, line 6 ¶ | |||
| human controls to identify or admit personnel with properly | human controls to identify or admit personnel with properly | |||
| authorized access to a SCIF. | authorized access to a SCIF. | |||
| $ access control center (ACC) | $ access control center (ACC) | |||
| (I) A computer that maintains a database (possibly in the form of | (I) A computer that maintains a database (possibly in the form of | |||
| an access control matrix) defining the security policy for an | an access control matrix) defining the security policy for an | |||
| access control service, and that acts as a server for clients | access control service, and that acts as a server for clients | |||
| requesting access control decisions. | requesting access control decisions. | |||
| Tutorial: An ACC is sometimes used in conjunction with a key | Tutorial: An ACC is sometimes used in conjunction with a key | |||
| center to implement access control in a key distribution system | center to implement access control in a key-distribution system | |||
| for symmetric cryptography. (See: BLACKER, Kerberos.) | for symmetric cryptography. (See: BLACKER, Kerberos.) | |||
| $ access control list (ACL) | $ access control list (ACL) | |||
| (I) /information system/ A mechanism that implements access | (I) /information system/ A mechanism that implements access | |||
| control for a system resource by enumerating the system entities | control for a system resource by enumerating the system entities | |||
| that are permitted to access the resource and, either implicitly | that are permitted to access the resource and stating, either | |||
| or explicitly, the types of access granted to each. (Compare: | implicitly or explicitly, the access modes granted to each entity. | |||
| access control matrix, access list, access profile, capability.) | (Compare: access control matrix, access list, access profile, | |||
| capability list.) | ||||
| $ access control matrix | $ access control matrix | |||
| (I) A rectangular array of cells, with one row per subject and one | (I) A rectangular array of cells, with one row per subject and one | |||
| column per object. The entry in a cell -- that is, the entry for a | column per object. The entry in a cell -- that is, the entry for a | |||
| particular subject-object pair -- indicates the access mode that | particular subject-object pair -- indicates the access mode that | |||
| the subject is permitted to exercise on the object. Each column is | the subject is permitted to exercise on the object. Each column is | |||
| equivalent to an "access control list" for the object; and each | equivalent to an "access control list" for the object; and each | |||
| row is equivalent to an "access profile" for the subject. | row is equivalent to an "access profile" for the subject. | |||
| $ access control service | $ access control service | |||
| skipping to change at page 11, line 48 ¶ | skipping to change at page 11, line 52 ¶ | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | |||
| in a potentially misleading way. Access control may be based on | in a potentially misleading way. Access control may be based on | |||
| attributes other than classification level. | attributes other than classification level. | |||
| $ access list | $ access list | |||
| (I) /physical security/ Roster of persons who are authorized to | (I) /physical security/ Roster of persons who are authorized to | |||
| enter a controlled area. (Compare: access control list.) | enter a controlled area. (Compare: access control list.) | |||
| $ access mode | $ access mode | |||
| (I) A distinct type of data processing operation -- e.g., read, | (I) A distinct type of data processing operation -- e.g., read, | |||
| write, append, or execute -- that a subject can potentially | write, append, or execute, or a combination of operations -- that | |||
| perform on an object in an information system. [Huff] | a subject can potentially perform on an object in an information | |||
| system. [Huff] | ||||
| $ access policy | $ access policy | |||
| (I) A kind of "security policy". (See: access, access control.) | (I) A kind of "security policy". (See: access, access control.) | |||
| $ access profile | $ access profile | |||
| (O) /information system/ A mechanism that implements access | (O) A synonym for "capability list". | |||
| control for a system entity by enumerating the system resources | ||||
| that the entity is authorized to access and, either implicitly or | ||||
| explicitly, the types of access granted to each. (Compare: access | ||||
| control matrix, access control list, access list, capability.) | ||||
| Usage: The definition is not widely known; therefore, ISDs that | Usage: ISDs that use this term SHOULD state a definition for it | |||
| use this term SHOULD state a definition for it. | because the definition is not widely known. | |||
| $ access right | $ access right | |||
| (I) Synonym for "authorization"; emphasizes the possession of the | (I) Synonym for "authorization"; emphasizes the possession of the | |||
| authorization by a system entity. | authorization by a system entity. | |||
| $ accountability | $ accountability | |||
| (I) The property of a system or system resource that ensures that | (I) The property of a system or system resource that ensures that | |||
| the actions of a system entity may be traced uniquely to that | the actions of a system entity may be traced uniquely to that | |||
| entity, which can then be held responsible for its actions. [Huff] | entity, which can then be held responsible for its actions. [Huff] | |||
| (See: audit service.) | (See: audit service.) | |||
| Tutorial: Accountability (also known as "individual | Tutorial: Accountability (a.k.a. "individual accountability") | |||
| accountability") typically involves a system capability to | typically requires a system ability to positively associate the | |||
| positively associate the identity of a user with the time, method, | identity of a user with the time, method, and mode of the user's | |||
| and mode of the user's access to the system. This capability | access to the system. This ability supports detection and | |||
| supports detection and subsequent investigation of security | subsequent investigation of security breaches. Individual persons | |||
| breaches. Individual persons who are system users are held | who are system users are held accountable for their actions after | |||
| accountable for their actions after being notified of the rules of | being notified of the rules of behavior for using the system and | |||
| behavior for using the system and the penalties associated with | the penalties associated with violating those rules. | |||
| violating those rules. | ||||
| $ accounting | $ accounting | |||
| See: COMSEC accounting. | See: COMSEC accounting. | |||
| $ accounting legend code (ALC) | $ accounting legend code (ALC) | |||
| (O) /U.S. Government/ Numeric system used to indicate the minimum | (O) /U.S. Government/ Numeric system used to indicate the minimum | |||
| accounting controls required for items of COMSEC material within | accounting controls required for items of COMSEC material within | |||
| the CMCS. [C4009] (See: COMSEC accounting.) | the CMCS. [C4009] (See: COMSEC accounting.) | |||
| $ accreditation | $ accreditation | |||
| skipping to change at page 13, line 35 ¶ | skipping to change at page 13, line 35 ¶ | |||
| 2. (O) /SET/ "The institution (or its agent) that acquires from | 2. (O) /SET/ "The institution (or its agent) that acquires from | |||
| the card acceptor the financial data relating to the transaction | the card acceptor the financial data relating to the transaction | |||
| and initiates that data into an interchange system." [SET2] | and initiates that data into an interchange system." [SET2] | |||
| $ activation data | $ activation data | |||
| (N) Secret data, other than keys, that is required to access a | (N) Secret data, other than keys, that is required to access a | |||
| cryptographic module. | cryptographic module. | |||
| $ active attack | $ active attack | |||
| (I) See: (secondary definition under) attack. | (I) See: secondary definition under "attack". | |||
| $ active content | $ active content | |||
| (O) "Electronic documents that can carry out or trigger actions | (O) "Electronic documents that can carry out or trigger actions | |||
| automatically on a computer platform without the intervention of a | automatically on a computer platform without the intervention of a | |||
| user. [This technology enables] mobile code associated with a | user. [This technology enables] mobile code associated with a | |||
| document to execute as the document is rendered." [SP28] | document to execute as the document is rendered." [SP28] (See: | |||
| mobile code.) | ||||
| $ active user | ||||
| (I) See: secondary definition under "attack". | ||||
| $ active wiretapping | $ active wiretapping | |||
| (I) A wiretapping attack that attempts to alter data being | (I) A wiretapping attack that attempts to alter data being | |||
| communicated or otherwise affect data flow. (See: wiretapping. | communicated or otherwise affect data flow. (See: wiretapping. | |||
| Compare: active attack, passive wiretapping.) | Compare: active attack, passive wiretapping.) | |||
| $ add-on security | $ add-on security | |||
| (N) The retrofitting of protection mechanisms, implemented by | (N) The retrofitting of protection mechanisms, implemented by | |||
| hardware or software, in an information system after the system | hardware or software, in an information system after the system | |||
| has become operational. [FP039] (Compare: baked-in security.) | has become operational. [FP039] (Compare: baked-in security.) | |||
| $ adequate security | $ adequate security | |||
| (O) /U.S. DoD/ "Security commensurate with the risk and magnitude | (O) /U.S. DoD/ "Security commensurate with the risk and magnitude | |||
| of harm resulting from the loss, misuse, or unauthorized access to | of harm resulting from the loss, misuse, or unauthorized access to | |||
| or modification of information." (See: acceptable risk, residual | or modification of information." (See: acceptable risk, residual | |||
| risk.) | risk.) | |||
| $ administrative security | $ administrative security | |||
| 1. (I) Management procedures and constraints to prevent | 1. (I) Management procedures and constraints to prevent | |||
| unauthorized access to a system. (See: (third law under) | unauthorized access to a system. (See: "third law" under | |||
| Courtney's laws, operational security, procedural security, | "Courtney's laws", operational security, procedural security, | |||
| security architecture. Compare: technical security.) | security architecture. Compare: technical security.) | |||
| Examples: Clear delineation and separation of duties; | Examples: Clear delineation and separation of duties; | |||
| configuration control. | configuration control. | |||
| Usage: Administrative security is usually understood to consist of | Usage: Administrative security is usually understood to consist of | |||
| methods and mechanisms that are implemented and executed primarily | methods and mechanisms that are implemented and executed primarily | |||
| by people, rather than by automated systems. | by people, rather than by automated systems. | |||
| 2. (O) "The management constraints, operational procedures, | 2. (O) "The management constraints, operational procedures, | |||
| skipping to change at page 14, line 34 ¶ | skipping to change at page 14, line 39 ¶ | |||
| $ administrator | $ administrator | |||
| 1. (O) /Common Criteria/ A person that is responsible for | 1. (O) /Common Criteria/ A person that is responsible for | |||
| configuring, maintaining, and administering the TOE in a correct | configuring, maintaining, and administering the TOE in a correct | |||
| manner for maximum security. (See: administrative security.) | manner for maximum security. (See: administrative security.) | |||
| 2. (O) /ITSEC/ A person in contact with the TOE, who is | 2. (O) /ITSEC/ A person in contact with the TOE, who is | |||
| responsible for maintaining its operational capability. | responsible for maintaining its operational capability. | |||
| $ Advanced Encryption Standard (AES) | $ Advanced Encryption Standard (AES) | |||
| (N) A U.S. Government standard [FP197] (the successor to DES) that | (N) A U.S. Government standard [FP197] (the successor to DES) that | |||
| (a) specifies the "the AES algorithm", which is a symmetric block | (a) specifies "the AES algorithm", which is a symmetric block | |||
| cipher that is based on Rijndael and uses key sizes of 128, 192, | cipher that is based on Rijndael and uses key sizes of 128, 192, | |||
| or 256 bits to operate on a 128-bit block, and (b) states policy | or 256 bits to operate on a 128-bit block, and (b) states policy | |||
| for using that algorithm to protect unclassified, sensitive data. | for using that algorithm to protect unclassified, sensitive data. | |||
| Tutorial: Rijndael was designed to handle additional block sizes | Tutorial: Rijndael was designed to handle additional block sizes | |||
| and key lengths that were not adopted in the AES. Rijndael was | and key lengths that were not adopted in the AES. Rijndael was | |||
| selected by NIST through a public competition that was held to | selected by NIST through a public competition that was held to | |||
| find a successor to the DEA; the other finalists were MARS, RC6, | find a successor to the DEA; the other finalists were MARS, RC6, | |||
| Serpent, and Twofish. | Serpent, and Twofish. | |||
| skipping to change at page 15, line 11 ¶ | skipping to change at page 15, line 15 ¶ | |||
| $ Affirm | $ Affirm | |||
| (O) A formal methodology, language, and integrated set of software | (O) A formal methodology, language, and integrated set of software | |||
| tools developed at the University of Southern California's | tools developed at the University of Southern California's | |||
| Information Sciences Institute for specifying, coding, and | Information Sciences Institute for specifying, coding, and | |||
| verifying software to produce correct and reliable programs. | verifying software to produce correct and reliable programs. | |||
| [Cheh] | [Cheh] | |||
| $ aggregation | $ aggregation | |||
| (I) A circumstance in which a collection of information items is | (I) A circumstance in which a collection of information items is | |||
| required to be classified at a higher security level than any of | required to be classified at a higher security level than any of | |||
| the items is classified individually. | the items is classified individually. (See: classification.) | |||
| $ AH | $ AH | |||
| (I) See: Authentication Header | (I) See: Authentication Header | |||
| $ air gap | $ air gap | |||
| (I) An interface between two systems at which (a) they are not | (I) An interface between two systems at which (a) they are not | |||
| connected physically and (b) any logical connection is not | connected physically and (b) any logical connection is not | |||
| automated (i.e., data is transferred through the interface only | automated (i.e., data is transferred through the interface only | |||
| manually, under human control). (See: sneaker net.) | manually, under human control). (See: sneaker net. Compare: | |||
| gateway.) | ||||
| Example: Computer A and computer B are on opposite sides of a | Example: Computer A and computer B are on opposite sides of a | |||
| room. To move data from A to B, a person carries a floppy disk | room. To move data from A to B, a person carries a floppy disk | |||
| across the room. If A and B operate in different security domains, | across the room. If A and B operate in different security domains, | |||
| than moving data across the air gap may involve an upgrade or | than moving data across the air gap may involve an upgrade or | |||
| downgrade operation. | downgrade operation. | |||
| $ ALC | $ ALC | |||
| (O) See: accounting legend code. | (O) See: accounting legend code. | |||
| skipping to change at page 15, line 54 ¶ | skipping to change at page 16, line 7 ¶ | |||
| $ American National Standards Institute (ANSI) | $ American National Standards Institute (ANSI) | |||
| (N) A private, not-for-profit association that administers U.S. | (N) A private, not-for-profit association that administers U.S. | |||
| private sector voluntary standards. | private sector voluntary standards. | |||
| Tutorial: ANSI has approximately 1,000 member organizations, | Tutorial: ANSI has approximately 1,000 member organizations, | |||
| including equipment users, manufacturers, and others. These | including equipment users, manufacturers, and others. These | |||
| include commercial firms, government agencies, and other | include commercial firms, government agencies, and other | |||
| institutions and international entities. | institutions and international entities. | |||
| ANSI is the sole U.S. representative to the two major non-treaty | ANSI is the sole U.S. representative to (1) ISO and (2) (via the | |||
| international standards organizations, ISO and, via the U.S. | U.S. National Committee) the International Electrotechnical | |||
| Commission (IEC), which are the two major, non-treaty, | ||||
| National Committee (USNC), the International Electrotechnical | international standards organizations. | |||
| Commission (IEC). | ||||
| ANSI provides a forum for ANSI-accredited standards development | ANSI provides a forum for ANSI-accredited standards development | |||
| groups. Among those groups, the following are especially relevant | groups. Among those groups, the following are especially relevant | |||
| to Internet security: | to Internet security: | |||
| - International Committee for Information Technology | - International Committee for Information Technology | |||
| Standardization (INCITS) (formerly X3): Primary U.S. focus of | Standardization (INCITS) (formerly X3): Primary U.S. focus of | |||
| standardization in information and communications technologies, | standardization in information and communications technologies, | |||
| encompassing storage, processing, transfer, display, | encompassing storage, processing, transfer, display, | |||
| management, organization, and retrieval of information. | management, organization, and retrieval of information. | |||
| Example: [A3092]. | Example: [A3092]. | |||
| - Accredited Standards Committee X9: Develops, establishes, | - Accredited Standards Committee X9: Develops, establishes, | |||
| maintains, and promotes standards for the financial services | maintains, and promotes standards for the financial services | |||
| industry. Example: [A9009]. | industry. Example: [A9009]. | |||
| - Alliance for Telecommunications Industry Solutions (ATIS): | - Alliance for Telecommunications Industry Solutions (ATIS): | |||
| Develops standards, specifications, guidelines, requirements, | Develops standards, specifications, guidelines, requirements, | |||
| technical reports, industry processes, and verification tests | technical reports, industry processes, and verification tests | |||
| for interoperability and reliability of telecommunications | for interoperability and reliability of telecommunications | |||
| networks, equipment, and software. Example: [A1523]. | networks, equipment, and software. Example: [A1523]. | |||
| $ American Standard Code for Information Interchange (ASCII) | ||||
| (N) A scheme that encodes 128 specified characters -- the numbers | ||||
| 0-9, the letters a-z and A-Z, some basic punctuation symbols, some | ||||
| control codes that originated with Teletype machines, and a blank | ||||
| space -- into the 7-bit binary numbers. Forms the basis of the | ||||
| character set representations used in most computers and many | ||||
| Internet standards. [FP001] (See: code.) | ||||
| $ Anderson report | $ Anderson report | |||
| (O) A 1972 study of computer security that was written by James P. | (O) A 1972 study of computer security that was written by James P. | |||
| Anderson for the U.S. Air Force [Ande]. | Anderson for the U.S. Air Force [Ande]. | |||
| Tutorial: Anderson collaborated with a panel of experts to study | Tutorial: Anderson collaborated with a panel of experts to study | |||
| Air Force requirements for multilevel security. The study | Air Force requirements for multilevel security. The study | |||
| recommended research and development that was urgently needed to | recommended research and development that was urgently needed to | |||
| provide secure information processing for command and control | provide secure information processing for command and control | |||
| systems and support systems. The report introduced the reference | systems and support systems. The report introduced the reference | |||
| monitor concept and provided development impetus for computer and | monitor concept and provided development impetus for computer and | |||
| network security technology. However, many of the security | network security technology. However, many of the security | |||
| problems that the 1972 report called "current" still plague | problems that the 1972 report called "current" still plague | |||
| information systems today. | information systems today. | |||
| $ anomaly detection | $ anomaly detection | |||
| (I) A intrusion detection method that searches for activity that | (I) A intrusion detection method that searches for activity that | |||
| is different from the normal behavior of system entities and | is different from the normal behavior of system entities and | |||
| system resources. (Compare: misuse detection. See: IDS.) | system resources. (See: IDS. Compare: misuse detection.) | |||
| $ anonymity | $ anonymity | |||
| (I) The condition of having a name that is unknown or concealed. | (I) The condition of having a name that is unknown or concealed. | |||
| (Compare: privacy. See: alias, anonymizer, anonymous credential, | (See: alias, anonymizer, anonymous credential, anonymous login, | |||
| anonymous login, persona certificate.) | onion routing, persona certificate. Compare: privacy.) | |||
| Tutorial: An application may require security services that | Tutorial: An application may require security services that | |||
| maintain anonymity of users or other system entities, perhaps to | maintain anonymity of users or other system entities, perhaps to | |||
| preserve their privacy or hide them from attack. To hide an | preserve their privacy or hide them from attack. To hide an | |||
| entity's real name, an alias may be used. For example, a financial | entity's real name, an alias may be used. For example, a financial | |||
| institution may assign an account number. Parties to a transaction | institution may assign an account number. Parties to a transaction | |||
| can thus remain relatively anonymous, but can also accept the | can thus remain relatively anonymous, but can also accept the | |||
| transaction as legitimate. Real names of the parties cannot be | transaction as legitimate. Real names of the parties cannot be | |||
| easily determined by observers of the transaction, but an | easily determined by observers of the transaction, but an | |||
| authorized third party may be able to map an alias to a real name, | authorized third party may be able to map an alias to a real name, | |||
| skipping to change at page 17, line 18 ¶ | skipping to change at page 17, line 31 ¶ | |||
| $ anonymizer | $ anonymizer | |||
| (I) A internetwork service, usually provided via a proxy server, | (I) A internetwork service, usually provided via a proxy server, | |||
| that provides anonymity and privacy for clients. That is, the | that provides anonymity and privacy for clients. That is, the | |||
| service enables a client to access servers without allowing the | service enables a client to access servers without allowing the | |||
| anyone to gather information about which servers the client | anyone to gather information about which servers the client | |||
| accesses and without allowing the accessed servers to gather | accesses and without allowing the accessed servers to gather | |||
| information about the client, such as its IP address. | information about the client, such as its IP address. | |||
| $ anonymous credential | $ anonymous credential | |||
| (D) /U.S. Government/ An credential that (a) can be used to | (D) /U.S. Government/ A credential that (a) can be used to | |||
| authenticate a person as having a specific attribute or being a | authenticate a person as having a specific attribute or being a | |||
| member of a specific group (e.g., military veterans or U.S. | member of a specific group (e.g., military veterans or U.S. | |||
| citizens) but (b) does not reveal the individual identity of the | citizens) but (b) does not reveal the individual identity of the | |||
| person that presents the credential. [M0404] | person that presents the credential. [M0404] (See: anonymity.) | |||
| Deprecated term: ISDs SHOULD NOT use this term; it mixes concepts | Deprecated term: ISDs SHOULD NOT use this term; it mixes concepts | |||
| in a potentially misleading way. For example, when the credential | in a potentially misleading way. For example, when the credential | |||
| is an X.509 certificate, the term could be misunderstood to mean | is an X.509 certificate, the term could be misunderstood to mean | |||
| that the certificate was signed by a CA that has a persona | that the certificate was signed by a CA that has a persona | |||
| certificate. Instead, use "attribute certificate", "organizational | certificate. Instead, use "attribute certificate", "organizational | |||
| certificate", or "persona" certificate" depending on what is | certificate", or "persona certificate" depending on what is meant, | |||
| meant, with additional explanations as needed. | and provide additional explanations as needed. | |||
| $ anonymous login | $ anonymous login | |||
| (I) An access control feature (actually, an access control | (I) An access control feature (actually, an access control | |||
| vulnerability) in many Internet hosts that enables users to gain | vulnerability) in many Internet hosts that enables users to gain | |||
| access to general-purpose or public services and resources of a | access to general-purpose or public services and resources of a | |||
| host (such as allowing any user to transfer data using File | host (such as allowing any user to transfer data using File | |||
| Transfer Protocol) without having a pre-established, identity- | Transfer Protocol) without having a pre-established, identity- | |||
| specific account (i.e., user name and password). | specific account (i.e., user name and password). (See: anonymity.) | |||
| Tutorial: This feature exposes a system to more threats than when | Tutorial: This feature exposes a system to more threats than when | |||
| all the users are known, pre-registered entities that are | all the users are known, pre-registered entities that are | |||
| individually accountable for their actions. A user logs in using a | individually accountable for their actions. A user logs in using a | |||
| special, publicly known user name (e.g., "anonymous", "guest", or | special, publicly known user name (e.g., "anonymous", "guest", or | |||
| "ftp"). To use the public login name, the user is not required to | "ftp"). To use the public login name, the user is not required to | |||
| know a secret password and may not be required to input anything | know a secret password and may not be required to input anything | |||
| at all except the name. In other cases, to complete the normal | at all except the name. In other cases, to complete the normal | |||
| sequence of steps in a login protocol, the system may require the | sequence of steps in a login protocol, the system may require the | |||
| user to input a matching, publicly known password (such as | user to input a matching, publicly known password (such as | |||
| "anonymous") or may ask the user for an e-mail address or some | "anonymous") or may ask the user for an e-mail address or some | |||
| other arbitrary character string. | other arbitrary character string. | |||
| $ ANSI | $ ANSI | |||
| (I) See: American National Standards Institute. | (N) See: American National Standards Institute. | |||
| $ anti-jam | $ anti-jam | |||
| (N) "Measures ensuring that transmitted information can be | (N) "Measures ensuring that transmitted information can be | |||
| received despite deliberate jamming attempts." [C4009] (See: | received despite deliberate jamming attempts." [C4009] (See: | |||
| electronic security, frequency hopping, jam, spread spectrum.) | electronic security, frequency hopping, jam, spread spectrum.) | |||
| $ apex trust anchor | ||||
| (N) The trust anchor that is superior to all other trust anchors | ||||
| in a particular system or context. (See: trust anchor, top CA.) | ||||
| $ API | $ API | |||
| (I) See: application programming interface. | (I) See: application programming interface. | |||
| $ APOP | $ APOP | |||
| (I) See: POP3 APOP. | (I) See: POP3 APOP. | |||
| $ application layer | $ Application Layer | |||
| (I) See: Open Systems Interconnection Reference Model (OSIRM). | See: Internet Protocol Suite, OSIRM. | |||
| $ application program | $ application program | |||
| (I) A computer program that performs a specific function directly | (I) A computer program that performs a specific function directly | |||
| for a user (as opposed to a program that is part of a computer | for a user (as opposed to a program that is part of a computer | |||
| operating system and exists to perform functions in support of | operating system and exists to perform functions in support of | |||
| application programs). | application programs). | |||
| $ archive | $ archive | |||
| 1a. (I) /noun/ A collection of data that is stored for a | 1a. (I) /noun/ A collection of data that is stored for a | |||
| relatively long period of time for historical and other purposes, | relatively long period of time for historical and other purposes, | |||
| skipping to change at page 18, line 42 ¶ | skipping to change at page 19, line 6 ¶ | |||
| archive. (Compare: back up.) | archive. (Compare: back up.) | |||
| Tutorial: A digital signature may need to be verified many years | Tutorial: A digital signature may need to be verified many years | |||
| after the signing occurs. The CA -- the one that issued the | after the signing occurs. The CA -- the one that issued the | |||
| certificate containing the public key needed to verify that | certificate containing the public key needed to verify that | |||
| signature -- may not stay in operation that long. So every CA | signature -- may not stay in operation that long. So every CA | |||
| needs to provide for long-term storage of the information needed | needs to provide for long-term storage of the information needed | |||
| to verify the signatures of those to whom it issues certificates. | to verify the signatures of those to whom it issues certificates. | |||
| $ ARPANET | $ ARPANET | |||
| (N) Advanced Research Projects Agency (ARPA) Network, a pioneer | (I) Advanced Research Projects Agency (ARPA) Network, a pioneer | |||
| packet-switched network that was designed, implemented, operated, | packet-switched network that (a) was designed, implemented, | |||
| and maintained by BBN from January 1969 until July 1975 under | operated, and maintained by BBN from January 1969 until July 1975 | |||
| contract to the U.S. Government; led to the development of today's | under contract to the U.S. Government; (b) led to the development | |||
| Internet; and was decommissioned in June 1990. [B4799, Hafn] | of today's Internet; and (c) was decommissioned in June 1990. | |||
| [B4799, Hafn] | ||||
| $ ASCII | $ ASCII | |||
| (I) American Standard Code for Information Interchange, a scheme | (N) See: American Standard Code for Information Interchange. | |||
| that encodes 128 specified characters -- the numbers 0-9, the | ||||
| letters a-z and A-Z, some basic punctuation symbols, some control | ||||
| codes that originated with Teletype machines, and a blank space -- | ||||
| into the 7-bit binary numbers. Forms the basis of the character | ||||
| set representations used in most computers and many Internet | ||||
| standards. (See: code.) | ||||
| $ ASN.1 | $ ASN.1 | |||
| (I) See: Abstract Syntax Notation One. | (N) See: Abstract Syntax Notation One. | |||
| $ asset | $ asset | |||
| (I) A system resource that is (a) required to be protected by an | (I) A system resource that is (a) required to be protected by an | |||
| information system's security policy, (b) intended to be protected | information system's security policy, (b) intended to be protected | |||
| by a countermeasure, or (c) required for a system's mission. | by a countermeasure, or (c) required for a system's mission. | |||
| $ association | $ association | |||
| (I) A cooperative relationship between system entities, usually | (I) A cooperative relationship between system entities, usually | |||
| for the purpose of transferring information between them. (See: | for the purpose of transferring information between them. (See: | |||
| security association.) | security association.) | |||
| $ assurance | $ assurance | |||
| See: security assurance. | See: security assurance. | |||
| $ assurance level | $ assurance level | |||
| (I) A rank on a hierarchical scale of confidence that a TOE | (N) A rank on a hierarchical scale that judges the confidence | |||
| adequately fulfills stated security requirements. (See: assurance, | someone can have that a TOE adequately fulfills stated security | |||
| certificate policy, EAL, TCSEC.) | requirements. (See: assurance, certificate policy, EAL, TCSEC.) | |||
| Example: U.S. Government guidance [M0404] describes four assurance | Example: U.S. Government guidance [M0404] describes four assurance | |||
| levels for identity authentication, where each level "describes | levels for identity authentication, where each level "describes | |||
| the [Government] agency~Os degree of certainty that the user has | the [Government] agency's degree of certainty that the user has | |||
| presented [a credential] that refers to [the user's] identity." In | presented [a credential] that refers to [the user's] identity." In | |||
| that guidance, "assurance is defined as (a) "the degree of | that guidance, "assurance is defined as (a) "the degree of | |||
| confidence in the vetting process used to establish the identity | confidence in the vetting process used to establish the identity | |||
| of the individual to whom the credential was issued" and (b) "the | of the individual to whom the credential was issued" and (b) "the | |||
| degree of confidence that the individual who uses the credential | degree of confidence that the individual who uses the credential | |||
| is the individual to whom the credential was issued." The four | is the individual to whom the credential was issued." | |||
| levels are described as follows: | ||||
| - Level 1: Little or no confidence in the asserted identity. | The four levels are described as follows: | |||
| - Level 2: Some confidence in the asserted identity. | - Level 1: Little or no confidence in the asserted identity. | |||
| - Level 3: High confidence in the asserted identity. | - Level 2: Some confidence in the asserted identity. | |||
| - Level 4: Very high confidence in the asserted identity. | - Level 3: High confidence in the asserted identity. | |||
| - Level 4: Very high confidence in the asserted identity. | ||||
| Standards for determining these levels are provided in a NIST | Standards for determining these levels are provided in a NIST | |||
| publication [SP12]. However, as noted there, an assurance level is | publication [SP12]. However, as noted there, an assurance level is | |||
| "a degree of confidence, not a true measure of how secure the | "a degree of confidence, not a true measure of how secure the | |||
| system actually is. This distinction is necessary because it is | system actually is. This distinction is necessary because it is | |||
| extremely difficult -- and in many cases virtually impossible -- | extremely difficult -- and in many cases virtually impossible -- | |||
| to know exactly how secure a system is." | to know exactly how secure a system is." | |||
| $ asymmetric cryptography | $ asymmetric cryptography | |||
| (I) A modern branch of cryptography (popularly known as "public- | (I) A modern branch of cryptography (popularly known as "public- | |||
| skipping to change at page 20, line 8 ¶ | skipping to change at page 20, line 20 ¶ | |||
| public key and a private key) and use a different component of the | public key and a private key) and use a different component of the | |||
| pair for each of two counterpart cryptographic operations (e.g., | pair for each of two counterpart cryptographic operations (e.g., | |||
| encryption and decryption, or signature creation and signature | encryption and decryption, or signature creation and signature | |||
| verification). (See: key pair, symmetric cryptography.) | verification). (See: key pair, symmetric cryptography.) | |||
| Tutorial: Asymmetric algorithms have key management advantages | Tutorial: Asymmetric algorithms have key management advantages | |||
| over equivalently strong symmetric ones. First, one key of the | over equivalently strong symmetric ones. First, one key of the | |||
| pair need not be known by anyone but its owner; so it can more | pair need not be known by anyone but its owner; so it can more | |||
| easily be kept secret. Second, although the other key is shared by | easily be kept secret. Second, although the other key is shared by | |||
| all entities that use the algorithm, that key need not be kept | all entities that use the algorithm, that key need not be kept | |||
| secret from other, non-using entities; thus, the key distribution | secret from other, non-using entities; thus, the key-distribution | |||
| part of key management can be done more easily. | part of key management can be done more easily. | |||
| Asymmetric cryptography can be used to create algorithms for | Asymmetric cryptography can be used to create algorithms for | |||
| encryption, digital signature, and key agreement: | encryption, digital signature, and key agreement: | |||
| - In an asymmetric encryption algorithm (e.g., see: RSA), when | - In an asymmetric encryption algorithm (e.g., see: RSA), when | |||
| Alice wants to ensure confidentiality for data she sends to | Alice wants to ensure confidentiality for data she sends to | |||
| Bob, she encrypts the data with a public key provided by Bob. | Bob, she encrypts the data with a public key provided by Bob. | |||
| Only Bob has the matching private key that is needed to decrypt | Only Bob has the matching private key that is needed to decrypt | |||
| the data. (Compare: seal.) | the data. (Compare: seal.) | |||
| - In an asymmetric digital signature algorithm (e.g., see: DSA), | - In an asymmetric digital signature algorithm (e.g., see: DSA), | |||
| when Alice wants to ensure data integrity or provide | when Alice wants to ensure data integrity or provide | |||
| authentication for data she sends to Bob, she uses her private | authentication for data she sends to Bob, she uses her private | |||
| key to sign the data (i.e., create a digital signature based on | key to sign the data (i.e., create a digital signature based on | |||
| the data). To verify the signature, Bob uses the matching | the data). To verify the signature, Bob uses the matching | |||
| public key that Alice has provided. | public key that Alice has provided. | |||
| - In an asymmetric key agreement algorithm (e.g., see: Diffie- | - In an asymmetric key-agreement algorithm (e.g., see: Diffie- | |||
| Hellman), Alice and Bob each send their own public key to the | Hellman), Alice and Bob each send their own public key to the | |||
| other party. Then each uses their own private key and the | other party. Then each uses their own private key and the | |||
| other's public key to compute the new key value. | other's public key to compute the new key value. | |||
| $ asymmetric key | ||||
| (I) A cryptographic key that is used in an asymmetric | ||||
| cryptographic algorithm. (See: asymmetric cryptography, private | ||||
| key, public key.) | ||||
| $ ATIS | $ ATIS | |||
| (N) See: (Alliance for Telecommunications Industry Solutions | (N) See: "Alliance for Telecommunications Industry Solutions" | |||
| under) ANSI. | under "ANSI". | |||
| $ attack | $ attack | |||
| 1. (I) An intentional act by which an entity attempts to evade | 1. (I) An intentional act by which an entity attempts to evade | |||
| security services and violate the security policy of a system. | security services and violate the security policy of a system. | |||
| That is, an actual assault on system security that derives from an | That is, an actual assault on system security that derives from an | |||
| intelligent threat. (See: penetration, violation, vulnerability.) | intelligent threat. (See: penetration, violation, vulnerability.) | |||
| 2. (I) A method or technique used in an assault (e.g., | 2. (I) A method or technique used in an assault (e.g., | |||
| masquerade). (See: distributed attack.) | masquerade). (See: distributed attack.) | |||
| Tutorial: Attacks can be characterized according to intent: | Tutorial: Attacks can be characterized according to intent: | |||
| - An "active attack" attempts to alter system resources or affect | - An "active attack" attempts to alter system resources or affect | |||
| their operation. | their operation. | |||
| - A "passive attack" attempts to learn or make use of information | - A "passive attack" attempts to learn or make use of information | |||
| from the system but does not affect system resources. (E.g., | from the system but does not affect system resources. (E.g., | |||
| see: wiretapping.) | see: wiretapping.) | |||
| The object of a passive attack might be to obtain data that is | The object of a passive attack might be to obtain data that is | |||
| needed for an off-line attack. | needed for an off-line attack. | |||
| - An "off-line attack" is one in which the attacker obtains data | - An "off-line attack" is one in which the attacker obtains data | |||
| from the target system and then analyzes the data on a | from the target system and then analyzes the data on a | |||
| different system of the attacker's own choosing, possibly in | different system of the attacker's own choosing, possibly in | |||
| preparation for a second stage of attack on the target. | preparation for a second stage of attack on the target. | |||
| Attacks can be characterized according to point of initiation: | Attacks can be characterized according to point of initiation: | |||
| - An "inside attack" is one that is initiated by an entity inside | - An "inside attack" is one that is initiated by an entity inside | |||
| the security perimeter (an "insider"), i.e., an entity that is | the security perimeter (an "insider"), i.e., an entity that is | |||
| authorized to access system resources but uses them in a way | authorized to access system resources but uses them in a way | |||
| not approved by those who granted the authorization. | not approved by those who granted the authorization. | |||
| - An "outside attack" is initiated from outside the perimeter, by | - An "outside attack" is initiated from outside the perimeter, by | |||
| an unauthorized or illegitimate user of the system (an | an unauthorized or illegitimate user of the system (an | |||
| "outsider"). In the Internet, potential outside attackers range | "outsider"). In the Internet, potential outside attackers range | |||
| from amateur pranksters to organized criminals, international | from amateur pranksters to organized criminals, international | |||
| terrorists, and hostile governments. | terrorists, and hostile governments. | |||
| The term "attack" relates to some other basic security terms as | The term "attack" relates to some other basic security terms as | |||
| shown in the following diagram: | shown in the following diagram: | |||
| + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ | + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ | |||
| | An Attack: | |Counter- | | A System Resource: | | | An Attack: | |Counter- | | A System Resource: | | |||
| skipping to change at page 21, line 33 ¶ | skipping to change at page 21, line 49 ¶ | |||
| | | Attacker |<==================||<========= | | | | | Attacker |<==================||<========= | | | |||
| | | i.e., | Passive | | | | | Vulnerability | | | | | i.e., | Passive | | | | | Vulnerability | | | |||
| | | A Threat |<=================>||<========> | | | | | A Threat |<=================>||<========> | | | |||
| | | Agent | or Active | | | | +-------|||-------+ | | | | Agent | or Active | | | | +-------|||-------+ | | |||
| | +----------+ Attack | | | | VVV | | | +----------+ Attack | | | | VVV | | |||
| | | | | | Threat Consequences | | | | | | | Threat Consequences | | |||
| + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ | + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ | |||
| $ attack potential | $ attack potential | |||
| (I) The perceived likelihood of success should an attack be | (I) The perceived likelihood of success should an attack be | |||
| launched, expressed in terms of the attacker's capability (i.e., | launched, expressed in terms of the attacker's ability (i.e., | |||
| expertise and resources) and motivation. (Compare: threat, risk.) | expertise and resources) and motivation. (Compare: threat, risk.) | |||
| $ attack sensing, warning, and response | $ attack sensing, warning, and response | |||
| (I) A set of security services that cooperate with audit service | (I) A set of security services that cooperate with audit service | |||
| to detect and react to indications of threat actions, including | to detect and react to indications of threat actions, including | |||
| both inside and outside attacks. (See: indicator.) | both inside and outside attacks. (See: indicator.) | |||
| $ attack tree | $ attack tree | |||
| (I) A branching, hierarchical data structure that represents a set | (I) A branching, hierarchical data structure that represents a set | |||
| of potential approaches to achieving an event in which system | of potential approaches to achieving an event in which system | |||
| skipping to change at page 22, line 17 ¶ | skipping to change at page 22, line 34 ¶ | |||
| $ attribute | $ attribute | |||
| 1. (N) The information of a particular type concerning an | 1. (N) The information of a particular type concerning an | |||
| identifiable system entity or object. An "attribute type" is the | identifiable system entity or object. An "attribute type" is the | |||
| component of an attribute that indicates the class of information | component of an attribute that indicates the class of information | |||
| given by the attribute; and an "attribute value" is a particular | given by the attribute; and an "attribute value" is a particular | |||
| instance of the class of information indicated by an attribute | instance of the class of information indicated by an attribute | |||
| type. (See: attribute certificate.) | type. (See: attribute certificate.) | |||
| $ attribute authority (AA) | $ attribute authority (AA) | |||
| 1. (I) A CA that issues attribute certificates. | 1. (N) A CA that issues attribute certificates. | |||
| 2. (O) "An authority [that] assigns privileges by issuing | 2. (O) "An authority [that] assigns privileges by issuing | |||
| attribute certificates." [X509] | attribute certificates." [X509] | |||
| Usage: The abbreviation "AA" should not be used in an ISD unless | Deprecated Abbreviation: The abbreviation "AA" SHOULD NOT be used | |||
| it is first defined in the ISD. | in an ISD unless it is first defined in the ISD. | |||
| $ attribute certificate | $ attribute certificate | |||
| 1. (I) A digital certificate that binds a set of descriptive data | 1. (I) A digital certificate that binds a set of descriptive data | |||
| items, other than a public key, either directly to a subject name | items, other than a public key, either directly to a subject name | |||
| or to the identifier of another certificate that is a public-key | or to the identifier of another certificate that is a public-key | |||
| certificate. | certificate. (See: capability token.) | |||
| 2. (N) "A data structure, digitally signed by an [a]ttribute | 2. (O) "A data structure, digitally signed by an [a]ttribute | |||
| [a]uthority, that binds some attribute values with identification | [a]uthority, that binds some attribute values with identification | |||
| information about its holder." [X509] | information about its holder." [X509] | |||
| Tutorial: A public-key certificate binds a subject name to a | Tutorial: A public-key certificate binds a subject name to a | |||
| public key value, along with information needed to perform certain | public key value, along with information needed to perform certain | |||
| cryptographic functions. Other attributes of a subject, such as a | cryptographic functions using that key. Other attributes of a | |||
| security clearance, may be certified in a separate kind of digital | subject, such as a security clearance, may be certified in a | |||
| certificate, called an attribute certificate. A subject may have | separate kind of digital certificate, called an attribute | |||
| multiple attribute certificates associated with its name or with | certificate. A subject may have multiple attribute certificates | |||
| each of its public-key certificates. | associated with its name or with each of its public-key | |||
| certificates. | ||||
| An attribute certificate might be issued to a subject in the | An attribute certificate might be issued to a subject in the | |||
| following situations: | following situations: | |||
| - Different lifetimes: When the lifetime of an attribute binding | - Different lifetimes: When the lifetime of an attribute binding | |||
| is shorter than that of the related public-key certificate, or | is shorter than that of the related public-key certificate, or | |||
| when it is desirable not to need to revoke a subject's public | when it is desirable not to need to revoke a subject's public | |||
| key just to revoke an attribute. | key just to revoke an attribute. | |||
| - Different authorities: When the authority responsible for the | - Different authorities: When the authority responsible for the | |||
| attributes is different than the one that issues the public-key | attributes is different than the one that issues the public-key | |||
| certificate for the subject. (There is no requirement that an | certificate for the subject. (There is no requirement that an | |||
| attribute certificate be issued by the same CA that issued the | attribute certificate be issued by the same CA that issued the | |||
| associated public-key certificate.) | associated public-key certificate.) | |||
| $ audit | $ audit | |||
| See: security audit. | See: security audit. | |||
| $ audit log | $ audit log | |||
| (I) Synonym for "security audit trail". | (I) Synonym for "security audit trail". | |||
| skipping to change at page 23, line 29 ¶ | skipping to change at page 23, line 45 ¶ | |||
| $ AUTH | $ AUTH | |||
| (I) See: POP3 AUTH. | (I) See: POP3 AUTH. | |||
| $ authentic signature | $ authentic signature | |||
| (I) A signature (especially a digital signature) that can be | (I) A signature (especially a digital signature) that can be | |||
| trusted because it can be verified. (See: validate vs. verify.) | trusted because it can be verified. (See: validate vs. verify.) | |||
| $ authenticate | $ authenticate | |||
| (I) Verify (i.e., establish the truth of) an identity claimed by | (I) Verify (i.e., establish the truth of) an identity claimed by | |||
| or for a system entity. (See: authentication, validate vs. verify, | or for a system entity. (See: authentication, validate vs. verify, | |||
| ("relationship between data integrity service and authentication | "relationship between data integrity service and authentication | |||
| services" under) data integrity service.).) | services" under "data integrity service".) | |||
| Deprecated Usage: In general English usage, this term is used with | Deprecated Usage: In general English usage, this term is used with | |||
| the meaning "to prove genuine" (e.g., an art expert authenticates | the meaning "to prove genuine" (e.g., an art expert authenticates | |||
| a Michelangelo painting); but this Internet definition restricts | a Michelangelo painting); but this Internet definition restricts | |||
| usage as follows: | usage as follows: | |||
| - ISDs SHOULD NOT use this term to refer to proving or checking | - ISDs SHOULD NOT use this term to refer to proving or checking | |||
| that data has not been changed, destroyed or lost in an | that data has not been changed, destroyed or lost in an | |||
| unauthorized or accidental manner. Instead use "verify". | unauthorized or accidental manner. Instead use "verify". | |||
| - ISDs SHOULD NOT use this term to refer to proving the truth or | - ISDs SHOULD NOT use this term to refer to proving the truth or | |||
| accuracy of a fact or value such as a digital signature. | accuracy of a fact or value such as a digital signature. | |||
| Instead, use "verify". | Instead, use "verify". | |||
| - ISDs SHOULD NOT use this term to refer to establishing the | - ISDs SHOULD NOT use this term to refer to establishing the | |||
| soundness or correctness of a construct, such as a digital | soundness or correctness of a construct, such as a digital | |||
| certificate. Instead, use "validate". | certificate. Instead, use "validate". | |||
| $ authentication | $ authentication | |||
| (I) The process of verifying an identity claimed by or for a | (I) The process of verifying an identity claimed by or for a | |||
| system entity. (See: authenticate, authentication exchange, | system entity. (See: authenticate, authentication exchange, | |||
| authentication information, credential, data origin | authentication information, credential, data origin | |||
| authentication, peer entity authentication, simple authentication, | authentication, peer entity authentication, "relationship between | |||
| strong authentication, X.509. Also see: ("relationship between | data integrity service and authentication services" under "data | |||
| data integrity service and authentication services" under) data | integrity service", simple authentication, strong authentication, | |||
| integrity service.) | X.509.) | |||
| Tutorial: An authentication process consists of two steps: | Tutorial: An authentication process consists of two steps: | |||
| - Identification step: Presenting an identifier to the security | - Identification step: Presenting an identifier to the security | |||
| system. (Identifiers should be assigned carefully, because | system. (Identifiers should be assigned carefully, because | |||
| authenticated identities are the basis for other security | authenticated identities are the basis for other security | |||
| services, such as access control service.) | services, such as access control service.) | |||
| - Verification step: Presenting or generating authentication | - Verification step: Presenting or generating authentication | |||
| information that acts as evidence to prove the binding between | information that acts as evidence to prove the binding between | |||
| the claimant and the identifier. (See: verification.) | the claimant and the identifier. (See: verification.) | |||
| $ authentication code | $ authentication code | |||
| (D) Synonym for a checksum based on cryptography. (Compare: | (D) Synonym for a checksum based on cryptography. (Compare: | |||
| Message Authentication Code.) | Message Authentication Code.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | |||
| any form of checksum, cryptographic or not; the term mixes | any form of checksum, cryptographic or not. Instead, use | |||
| concepts in a potentially misleading way. Instead, use "checksum", | "checksum", "error detection code", "hash", "keyed hash", "Message | |||
| "error detection code", "hash", "keyed hash", "Message | ||||
| Authentication Code", or "protected checksum", depending on what | Authentication Code", or "protected checksum", depending on what | |||
| is meant. | is meant. | |||
| The word "authentication" is misleading because the checksum may | The term mixes concepts in a potentially misleading way. The word | |||
| be used to perform a data integrity function rather than a data | "authentication" is misleading because the checksum may be used to | |||
| origin authentication function. The word "code" is misleading | perform a data integrity function rather than a data origin | |||
| because it suggests either that encoding or encryption is involved | authentication function. The word "code" is misleading because it | |||
| or that the term refers to computer software. | suggests either that encoding or encryption is involved or that | |||
| the term refers to computer software. | ||||
| $ authentication exchange | $ authentication exchange | |||
| 1. (I) A mechanism to verify the identity of an entity by means of | 1. (I) A mechanism to verify the identity of an entity by means of | |||
| information exchange. | information exchange. | |||
| 2. (O) "A mechanism intended to ensure the identity of an entity | 2. (O) "A mechanism intended to ensure the identity of an entity | |||
| by means of information exchange." [I7498 Part 2] | by means of information exchange." [I7498 Part 2] | |||
| $ Authentication Header (AH) | $ Authentication Header (AH) | |||
| (I) An Internet protocol [R2402] designed to provide | (I) An Internet protocol [R2402] designed to provide | |||
| connectionless data integrity service and connectionless data | connectionless data integrity service and connectionless data | |||
| origin authentication service for IP datagrams, and (optionally) | origin authentication service for IP datagrams, and (optionally) | |||
| to provide partial sequence integrity and protection against | to provide partial sequence integrity and protection against | |||
| replay attacks. (See: IPsec. Compare: ESP.) | replay attacks. (See: IPsec. Compare: ESP.) | |||
| Tutorial: Replay protection may be selected by the receiver when a | Tutorial: Replay protection may be selected by the receiver when a | |||
| security association is established. AH authenticates upper-layer | security association is established. AH authenticates the upper- | |||
| protocol data units and as much of the IP header as possible. | layer PDU that is carried as an IP SDU, and also authenticates as | |||
| However, some IP header fields may change in transit, and the | much of the IP PCI (i.e., the IP header) as possible. However, | |||
| value of these fields, when the packet arrives at the receiver, | some IP header fields may change in transit, and the value of | |||
| may not be predictable by the sender. Thus, the values of such | these fields, when the packet arrives at the receiver, may not be | |||
| fields cannot be protected end-to-end by AH; protection of the IP | predictable by the sender. Thus, the values of such fields cannot | |||
| header by AH is only partial when such fields are present. | be protected end-to-end by AH; protection of the IP header by AH | |||
| is only partial when such fields are present. | ||||
| AH may be used alone, or in combination with the ESP, or in a | AH may be used alone, or in combination with the ESP, or in a | |||
| nested fashion with tunneling. Security services can be provided | nested fashion with tunneling. Security services can be provided | |||
| between a pair of communicating hosts, between a pair of | between a pair of communicating hosts, between a pair of | |||
| communicating security gateways, or between a host and a gateway. | communicating security gateways, or between a host and a gateway. | |||
| ESP can provide nearly the same security services as AH, and ESP | ESP can provide nearly the same security services as AH, and ESP | |||
| can also provide data confidentiality service. The main difference | can also provide data confidentiality service. The main difference | |||
| between authentication services provided by ESP and AH is the | between authentication services provided by ESP and AH is the | |||
| extent of the coverage; ESP does not protect IP header fields | extent of the coverage; ESP does not protect IP header fields | |||
| unless they are encapsulated by AH. | unless they are encapsulated by AH. | |||
| skipping to change at page 25, line 54 ¶ | skipping to change at page 26, line 20 ¶ | |||
| certification authority or to an attribute authority)." [X509] | certification authority or to an attribute authority)." [X509] | |||
| (See: authority.) | (See: authority.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term as defined here; it | Deprecated Term: ISDs SHOULD NOT use this term as defined here; it | |||
| is ambiguous. Instead, use the full term "certification authority | is ambiguous. Instead, use the full term "certification authority | |||
| certificate", "attribute authority certificate", "registration | certificate", "attribute authority certificate", "registration | |||
| authority certificate", etc. at the first instance of usage and | authority certificate", etc. at the first instance of usage and | |||
| then, if it is necessary to shorten text, use AA, CA, RA, and | then, if it is necessary to shorten text, use AA, CA, RA, and | |||
| other abbreviations defined in this Glossary. | other abbreviations defined in this Glossary. | |||
| $ Authority Information Access extension | ||||
| (I) The private extension defined by PKIX for X.509 certificates | ||||
| to indicate "how to access CA information and services for the | ||||
| issuer of the certificate in which the extension appears. | ||||
| Information and services may include on-line validation services | ||||
| and CA policy data." [R3280] (See: private extension.) | ||||
| $ authorization | $ authorization | |||
| 1a. (I) An approval that is granted to a system entity to access a | 1a. (I) An approval that is granted to a system entity to access a | |||
| system resource. (Compare: permission, privilege.) | system resource. (Compare: permission, privilege.) | |||
| Usage: Some synonyms are "permission" and "privilege". Specific | Usage: Some synonyms are "permission" and "privilege". Specific | |||
| terms are preferred in certain contexts: | terms are preferred in certain contexts: | |||
| - /PKI/ "Authorization" SHOULD be used, to align with | - /PKI/ "Authorization" SHOULD be used, to align with | |||
| "certification authority" in the standard [X509]. | "certification authority" in the standard [X509]. | |||
| - /role-based access control/ "Permission" SHOULD be used, to | - /role-based access control/ "Permission" SHOULD be used, to | |||
| align with the standard [ANSI]. | align with the standard [ANSI]. | |||
| - /computer operating systems/ "Privilege" SHOULD be used, to | - /computer operating systems/ "Privilege" SHOULD be used, to | |||
| align with the literature. | align with the literature. (See: privileged process, privileged | |||
| user.) | ||||
| Tutorial: The semantics and granularity of authorizations depend | Tutorial: The semantics and granularity of authorizations depend | |||
| on the application and implementation (see: (first law under) | on the application and implementation (see: "first law" under | |||
| Courtney's laws). An authorization may specify a particular access | "Courtney's laws"). An authorization may specify a particular | |||
| mode -- such as read, write, or execute -- for one or more system | access mode -- such as read, write, or execute -- for one or more | |||
| resources. | system resources. | |||
| 1b. (I) A process for granting approval to a system entity to | 1b. (I) A process for granting approval to a system entity to | |||
| access a system resource. | access a system resource. | |||
| 2. (O) /SET/ "The process by which a properly appointed person or | 2. (O) /SET/ "The process by which a properly appointed person or | |||
| persons grants permission to perform some action on behalf of an | persons grants permission to perform some action on behalf of an | |||
| organization. This process assesses transaction risk, confirms | organization. This process assesses transaction risk, confirms | |||
| that a given transaction does not raise the account holder's debt | that a given transaction does not raise the account holder's debt | |||
| above the account's credit limit, and reserves the specified | above the account's credit limit, and reserves the specified | |||
| amount of credit. (When a merchant obtains authorization, payment | amount of credit. (When a merchant obtains authorization, payment | |||
| for the authorized amount is guaranteed -- provided, of course, | for the authorized amount is guaranteed -- provided, of course, | |||
| that the merchant followed the rules associated with the | that the merchant followed the rules associated with the | |||
| authorization process.)" [SET2] | authorization process.)" [SET2] | |||
| $ authorization credential | $ authorization credential | |||
| (I) See: ("access control" context under) "credential". | (I) See: /access control/ under "credential". | |||
| $ authorize | $ authorize | |||
| (I) Grant an authorization to a system entity. | (I) Grant an authorization to a system entity. | |||
| $ authorized user | $ authorized user | |||
| (I) /access control/ A system entity that accesses a system | (I) /access control/ A system entity that accesses a system | |||
| resource for which the entity has received an authorization. | resource for which the entity has received an authorization. | |||
| (Compare: insider, outsider, unauthorized user.) | (Compare: insider, outsider, unauthorized user.) | |||
| Usage: The term is used in many ways and could easily be | Deprecated Usage: ISDs that use this term SHOULD state a | |||
| misunderstood; ISD that use this term SHOULD state a definition | definition for it because the term is used in many ways and could | |||
| for it. | easily be misunderstood. | |||
| $ automated information system | $ automated information system | |||
| See: information system. | See: information system. | |||
| $ availability | $ availability | |||
| 1. (I) The property of a system or a system resource being | 1. (I) The property of a system or a system resource being | |||
| accessible, or usable or operational upon demand, by an authorized | accessible, or usable or operational upon demand, by an authorized | |||
| system entity, according to performance specifications for the | system entity, according to performance specifications for the | |||
| system; i.e., a system is available if it provides services | system; i.e., a system is available if it provides services | |||
| according to the system design whenever users request them. (See: | according to the system design whenever users request them. (See: | |||
| critical, denial of service. Compare: precedence, reliability, | critical, denial of service. Compare: precedence, reliability, | |||
| survivability.) | survivability.) | |||
| 2. (O) "The property of being accessible and usable upon demand by | 2. (O) "The property of being accessible and usable upon demand by | |||
| an authorized entity." [I7498 Part 2] | an authorized entity." [I7498 Part 2] | |||
| Tutorial: This service addresses the security concerns raised by | ||||
| denial-of-service attacks. It depends on proper management and | ||||
| control of system resources, and thus depends on access control | ||||
| service and other security services. | ||||
| Availability requirements can be specified by quantitative | ||||
| metrics, but sometimes are stated qualitatively, such as in the | ||||
| following: | ||||
| - "Flexible tolerance for delay" may mean that brief system | ||||
| outages do not endanger mission accomplishment, but extended | ||||
| outages may endanger the mission. | ||||
| - "Minimum tolerance for delay" may mean that mission | ||||
| accomplishment requires the system to provide requested | ||||
| services in a short time. | ||||
| $ availability service | $ availability service | |||
| (I) A security service that protects a system to ensure its | (I) A security service that protects a system to ensure its | |||
| availability. | availability. | |||
| Tutorial: This service addresses the security concerns raised by | Tutorial: This service addresses the security concerns raised by | |||
| denial-of-service attacks. It depends on proper management and | denial-of-service attacks. It depends on proper management and | |||
| control of system resources, and thus depends on access control | control of system resources, and thus depends on access control | |||
| service and other security services. | service and other security services. | |||
| $ B1 computer system, B2 computer system, B3 computer system | $ avoidance | |||
| (O) See: TCSEC. | (I) See: secondary definition under "security". | |||
| $ B1, B2, or B3 computer system | ||||
| (O) /TCSEC/ See: Tutorial under "Trusted Computer System | ||||
| Evaluation Criteria". | ||||
| $ back door | $ back door | |||
| 1. (I) /computer security/ A computer system feature -- which may | 1. (I) /computer security/ A computer system feature -- which may | |||
| be (a) an unintentional flaw, (b) a mechanism deliberately | be (a) an unintentional flaw, (b) a mechanism deliberately | |||
| installed by the system's creator, or (c) a mechanism | installed by the system's creator, or (c) a mechanism | |||
| surreptitiously installed by an intruder -- that provides access | surreptitiously installed by an intruder -- that provides access | |||
| to a system resource by other than the usual procedure and usually | to a system resource by other than the usual procedure and usually | |||
| is hidden or otherwise not well-known. (Compare: Trojan Horse. | is hidden or otherwise not well-known. (See: maintenance hook. | |||
| See: maintenance hook.) | Compare: Trojan Horse.) | |||
| Example: A way to access a computer other than through a normal | Example: A way to access a computer other than through a normal | |||
| login. Such an access path is not necessarily designed with | login. Such an access path is not necessarily designed with | |||
| malicious intent; operating systems sometimes are shipped by the | malicious intent; operating systems sometimes are shipped by the | |||
| manufacturer with hidden accounts intended for use by field | manufacturer with hidden accounts intended for use by field | |||
| service technicians or the vendor's maintenance programmers. | service technicians or the vendor's maintenance programmers. | |||
| 2. (I) /cryptography/ A feature of a cryptographic system that | 2. (I) /cryptography/ A feature of a cryptographic system that | |||
| makes it easily possible to break or circumvent the protection | makes it easily possible to break or circumvent the protection | |||
| that the system is designed to provided. | that the system is designed to provided. | |||
| Example: A feature that makes it possible to decrypt cipher text | Example: A feature that makes it possible to decrypt cipher text | |||
| much more quickly than by brute force cryptanalysis, without | much more quickly than by brute force cryptanalysis, without | |||
| having prior knowledge of the decryption key. | having prior knowledge of the decryption key. | |||
| $ back up | $ back up | |||
| (I) /verb/ Create a reserve copy of data (compare: archive) or, | (I) /verb/ Create a reserve copy of data or, more generally, | |||
| more generally, provide alternate means to perform system | provide alternate means to perform system functions despite loss | |||
| functions despite loss of system resources. (See: contingency | of system resources. (See: contingency plan. Compare: archive.) | |||
| plan.) | ||||
| $ backup | $ backup | |||
| (I) /noun or adjective/ Refers to alternate means of performing | (I) /noun or adjective/ Refers to alternate means of performing | |||
| system functions despite loss of system resources. (See: | system functions despite loss of system resources. (See: | |||
| contingency plan). | contingency plan). | |||
| Example: A reserve copy of data, preferably one that is stored | Example: A reserve copy of data, preferably one that is stored | |||
| separately from the original, for use if the original becomes lost | separately from the original, for use if the original becomes lost | |||
| or damaged. (Compare: archive.) | or damaged. (Compare: archive.) | |||
| $ baggage | $ baggage | |||
| (O) /SET/ An "opaque encrypted tuple, which is included in a SET | (O) /SET/ An "opaque encrypted tuple, which is included in a SET | |||
| message but appended as external data to the PKCS encapsulated | message but appended as external data to the PKCS encapsulated | |||
| data. This avoids superencryption of the previously encrypted | data. This avoids superencryption of the previously encrypted | |||
| skipping to change at page 28, line 28 ¶ | skipping to change at page 29, line 19 ¶ | |||
| Deprecated Usage: ISDs SHOULD NOT use this term to describe a data | Deprecated Usage: ISDs SHOULD NOT use this term to describe a data | |||
| element, except in the form "SET(trademark) baggage" with the | element, except in the form "SET(trademark) baggage" with the | |||
| meaning given above. | meaning given above. | |||
| $ baked-in security | $ baked-in security | |||
| (I) The inclusion of security mechanisms in an information system | (I) The inclusion of security mechanisms in an information system | |||
| beginning at an early point in the system's life cycle, i.e., | beginning at an early point in the system's life cycle, i.e., | |||
| during the design phase, or at least early in the implementation | during the design phase, or at least early in the implementation | |||
| phase. (Compare: add-on security.) | phase. (Compare: add-on security.) | |||
| Deprecated Term: It is likely that other cultures have different | Deprecated Term: It is likely that other cultures use different | |||
| metaphors for this concept. Therefore, to ensure international | metaphors for this concept. Therefore, to avoid international | |||
| understanding, ISDs SHOULD NOT use this term. (See: (Deprecated | misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated | |||
| Usage under) Green Book.) | Usage under "Green Book".) | |||
| $ bandwidth | $ bandwidth | |||
| (I) The total width of the frequency band that is available to or | (I) The total width of the frequency band that is available to or | |||
| used by a communication channel; usually expressed in Hertz (Hz). | used by a communication channel; usually expressed in Hertz (Hz). | |||
| [R3753] (Compare: channel capacity.) | (RFC 3753) (Compare: channel capacity.) | |||
| $ bank identification number (BIN) | $ bank identification number (BIN) | |||
| 1. (O) The digits of a credit card number that identify the | 1. (O) The digits of a credit card number that identify the | |||
| issuing bank. (See: primary account number.) | issuing bank. (See: primary account number.) | |||
| 2. (O) /SET/ The first six digits of a primary account number. | 2. (O) /SET/ The first six digits of a primary account number. | |||
| $ Basic Encoding Rules (BER) | $ Basic Encoding Rules (BER) | |||
| (I) A standard for representing ASN.1 data types as strings of | (I) A standard for representing ASN.1 data types as strings of | |||
| octets. [X690] (See: Distinguished Encoding Rules.) | octets. [X690] (See: Distinguished Encoding Rules.) | |||
| Usage: Sometimes incorrectly included under the term ASN.1, which | Deprecated Usage: Sometimes incorrectly treated as part of ASN.1. | |||
| properly refers only to the syntax description language, and not | However, ASN.1 properly refers only to a syntax description | |||
| to the encoding rules for the language. | language, and not to the encoding rules for the language. | |||
| $ Basic Security Option | $ Basic Security Option | |||
| (I) See: (secondary definition under) IPSO. | (I) See: secondary definition under "IPSO". | |||
| $ bastion host | $ bastion host | |||
| (I) A strongly protected computer that is in a network protected | (I) A strongly protected computer that is in a network protected | |||
| by a firewall (or is part of a firewall) and is the only host (or | by a firewall (or is part of a firewall) and is the only host (or | |||
| one of only a few) in the network that can be directly accessed | one of only a few) in the network that can be directly accessed | |||
| from networks on the other side of the firewall. (See: firewall.) | from networks on the other side of the firewall. (See: firewall.) | |||
| Tutorial: Filtering routers in a firewall typically restrict | Tutorial: Filtering routers in a firewall typically restrict | |||
| traffic from the outside network to reaching just one host, the | traffic from the outside network to reaching just one host, the | |||
| bastion host, which usually is part of the firewall. Since only | bastion host, which usually is part of the firewall. Since only | |||
| skipping to change at page 29, line 27 ¶ | skipping to change at page 30, line 19 ¶ | |||
| SMTP) have forwarding built in; other services (e.g., TELNET and | SMTP) have forwarding built in; other services (e.g., TELNET and | |||
| FTP) require a proxy server on the bastion host. | FTP) require a proxy server on the bastion host. | |||
| $ BBN Technologies | $ BBN Technologies | |||
| (O) The research-and-development company (originally called Bolt | (O) The research-and-development company (originally called Bolt | |||
| Baranek and Newman, Inc.) that built the ARPANET. | Baranek and Newman, Inc.) that built the ARPANET. | |||
| $ BCA | $ BCA | |||
| (O) See: brand certification authority. | (O) See: brand certification authority. | |||
| $ BCR (black/crypto/red) | $ BCR | |||
| (N) An experimental, end-to-end, network packet encryption system | (O) See: BLACK/Crypto/RED. | |||
| developed in a working prototype form by BBN and the Collins Radio | ||||
| division of Rockwell Corporation in the 1975-1980 time frame for | ||||
| the U.S. DoD. BCR was the first network security system to support | ||||
| TCP/IP traffic, and it incorporated the first DES chips that were | ||||
| validated by the U.S. National Bureau of Standards (now called | ||||
| NIST). BCR also was the first to use a KDC and an ACC to manage | ||||
| connections. | ||||
| $ BCI | $ BCI | |||
| (O) See: brand CRL identifier. | (O) See: brand CRL identifier. | |||
| $ Bell-LaPadula model | $ Bell-LaPadula model | |||
| (N) A formal, mathematical, state-transition model of | (N) A formal, mathematical, state-transition model of | |||
| confidentiality policy for multilevel-secure computer systems | confidentiality policy for multilevel-secure computer systems | |||
| [Bell]. (Compare: Biba model, Brewer-Nash model.) | [Bell]. (Compare: Biba model, Brewer-Nash model.) | |||
| Tutorial: The model, devised by David Bell and Leonard LaPadula at | Tutorial: The model, devised by David Bell and Leonard LaPadula at | |||
| The MITRE Corporation in 1973, characterizes computer system | The MITRE Corporation in 1973, characterizes computer system | |||
| elements as subjects and objects. To determine whether or not a | elements as subjects and objects. To determine whether or not a | |||
| subject is authorized for a particular access mode on an object, | subject is authorized for a particular access mode on an object, | |||
| the clearance of the subject is compared to the classification of | the clearance of the subject is compared to the classification of | |||
| the object. The model defines the notion of a "secure state", in | the object. The model defines the notion of a "secure state", in | |||
| which the only permitted access modes of subjects to objects are | which the only permitted access modes of subjects to objects are | |||
| in accordance with a specified security policy. It is proven that | in accordance with a specified security policy. It is proven that | |||
| each state transition preserves security by moving from secure | each state transition preserves security by moving from secure | |||
| state to secure state, thereby proving that the system is secure. | state to secure state, thereby proving that the system is secure. | |||
| In this model, a multilevel-secure system satisfies several rules, | In this model, a multilevel-secure system satisfies several rules, | |||
| including the "confinement property" (also called "*-property", | including the "confinement property" (a.k.a. the "*-property"), | |||
| pronounced "star property"), the "simple security property", and | the "simple security property", and the "tranquillity property". | |||
| the "tranquillity property". | ||||
| $ benign | $ benign | |||
| (N) "Condition of cryptographic data [such] that [it] cannot be | (N) "Condition of cryptographic data [such] that [it] cannot be | |||
| compromised by human access [to the data]." [C4009] | compromised by human access [to the data]." [C4009] | |||
| $ benign fill | $ benign fill | |||
| (N) Process by which keying material is generated, distributed, | (N) Process by which keying material is generated, distributed, | |||
| and placed into an ECU without exposure to any human or other | and placed into an ECU without exposure to any human or other | |||
| system entity, except the cryptographic module that consumes and | system entity, except the cryptographic module that consumes and | |||
| uses the material. | uses the material. | |||
| $ BER | $ BER | |||
| (I) See: Basic Encoding Rules. | (I) See: Basic Encoding Rules. | |||
| $ beyond A1 | A1 | |||
| 1. (O) /formal/ A level of security assurance that is beyond the | 1. (O) /formal/ A level of security assurance that is beyond the | |||
| highest level (level A1) of criteria specified by the TCSEC. | highest level (level A1) of criteria specified by the TCSEC. (See: | |||
| Tutorial under "Trusted Computer System Evaluation Criteria".) | ||||
| 2. (O) /informal/ A level of trust so high that it is beyond | 2. (O) /informal/ A level of trust so high that it is beyond | |||
| state-of-the-art technology; i.e., it cannot be provided or | state-of-the-art technology; i.e., it cannot be provided or | |||
| verified by currently available assurance methods, and especially | verified by currently available assurance methods, and especially | |||
| not by currently available formal methods. | not by currently available formal methods. | |||
| $ Biba integrity | ||||
| (N) Synonym for "source integrity". | ||||
| $ Biba model | $ Biba model | |||
| (N) A formal, mathematical, state-transition model of integrity | (N) A formal, mathematical, state-transition model of integrity | |||
| policy for multilevel-secure computer systems [Biba]. (Compare: | policy for multilevel-secure computer systems [Biba]. (See: source | |||
| Bell-LaPadula model.) | integrity. Compare: Bell-LaPadula model.) | |||
| Tutorial: This model for integrity control is analogous to the | Tutorial: This model for integrity control is analogous to the | |||
| Bell-LaPadula model for confidentiality control. Each subject and | Bell-LaPadula model for confidentiality control. Each subject and | |||
| object is assigned an integrity level and, to determine whether or | object is assigned an integrity level and, to determine whether or | |||
| not a subject is authorized for a particular access mode on an | not a subject is authorized for a particular access mode on an | |||
| object, the integrity level of the subject is compared to that of | object, the integrity level of the subject is compared to that of | |||
| the object. The model prohibits the changing of information in an | the object. The model prohibits the changing of information in an | |||
| object by a subject with a lesser or incomparable level. The rules | object by a subject with a lesser or incomparable level. The rules | |||
| of the Biba model are duals of the corresponding rules in the | of the Biba model are duals of the corresponding rules in the | |||
| Bell-LaPadula model. | Bell-LaPadula model. | |||
| skipping to change at page 31, line 11 ¶ | skipping to change at page 31, line 50 ¶ | |||
| System entities are in one-to-one relationships with their | System entities are in one-to-one relationships with their | |||
| billets, but may be in many-to-one and one-to-many relationships | billets, but may be in many-to-one and one-to-many relationships | |||
| with their roles. | with their roles. | |||
| $ BIN | $ BIN | |||
| (O) See: bank identification number. | (O) See: bank identification number. | |||
| $ bind | $ bind | |||
| (I) To inseparably associate by applying some mechanism. | (I) To inseparably associate by applying some mechanism. | |||
| Example: A CA uses a digital signature to bind together (a) a | Example: A CA creates a public-key certificate by using a digital | |||
| subject and (b) a public key, and possibly some additional, | signature to bind together (a) a subject name, (b) a public key, | |||
| secondary data items, to create a public-key certificate. | and usually (c) some additional data items (e.g., see "X.509 | |||
| public-key certificate"). | ||||
| $ biometric authentication | $ biometric authentication | |||
| (I) A method of generating authentication information for a person | (I) A method of generating authentication information for a person | |||
| by digitizing measurements of a physical or behavioral | by digitizing measurements of a physical or behavioral | |||
| characteristic, such as a fingerprint, hand shape, retina pattern, | characteristic, such as a fingerprint, hand shape, retina pattern, | |||
| voiceprint, handwriting style, or face. | voiceprint, handwriting style, or face. | |||
| $ birthday attack | $ birthday attack | |||
| (I) A class of attacks against cryptographic functions, including | (I) A class of attacks against cryptographic functions, including | |||
| both encryption functions and hash functions. The attacks take | both encryption functions and hash functions. The attacks take | |||
| advantage of a statistical property: Given a cryptographic | advantage of a statistical property: Given a cryptographic | |||
| function having an N-bit output, the probability is greater than | function having an N-bit output, the probability is greater than | |||
| 1/2 that for 2**(N/2) randomly chosen inputs, the function will | 1/2 that for 2**(N/2) randomly chosen inputs, the function will | |||
| produce at least two outputs that are identical. (See: (discussion | produce at least two outputs that are identical. (See: Tutorial | |||
| under) hash function.) | under "hash function".) | |||
| Derivation: From the somewhat surprising fact (often called the | Derivation: From the somewhat surprising fact (often called the | |||
| "birthday paradox") that although there are 365 days in a year, | "birthday paradox") that although there are 365 days in a year, | |||
| the probability is greater than 1/2 that two of more people share | the probability is greater than 1/2 that two of more people share | |||
| the same birthday in any randomly chosen group of 23 people. | the same birthday in any randomly chosen group of 23 people. | |||
| Birthday attacks enable an adversary to find two inputs for which | ||||
| a cryptographic function produces the same cipher text (or find | ||||
| two inputs for which a hash functions produces the same hash | ||||
| result) much faster than a brute force attack can; and a clever | ||||
| adversary can use such a capability to create considerable | ||||
| mischief. However, no birthday attack can enable an adversary to | ||||
| decrypt a given cipher text (or find a hash input that results in | ||||
| a given hash result) any faster than a brute force attack can. | ||||
| $ bit | $ bit | |||
| (I) A contraction of the term "binary digit", the smallest unit of | (I) A contraction of the term "binary digit"; the smallest unit of | |||
| information storage, which has two possible states or values that | information storage, which has two possible states or values. The | |||
| are usually represented by the symbols "0" (zero) and "1" (one). | values usually are represented by the symbols "0" (zero) and "1" | |||
| (See: block, byte, word.) | (one). (See: block, byte, word.) | |||
| $ bit string | $ bit string | |||
| (I) A sequence of bits, each of which is either "0" or "1". | (I) A sequence of bits, each of which is either "0" or "1". | |||
| $ BLACK | $ BLACK | |||
| 1. (I) Designation for data that consists only of cipher text, and | 1. (I) Designation for data that consists only of cipher text, and | |||
| for information system equipment items or facilities that handle | for information system equipment items or facilities that handle | |||
| only cipher text. Example: "BLACK key".(Compare: RED. See: color | only cipher text. Example: "BLACK key".(See: color change, | |||
| change, RED/BLACK separation.) | RED/BLACK separation. Compare: RED.) | |||
| 2. (O) /U.S. Government/ "Designation applied to information | 2. (O) /U.S. Government/ "Designation applied to information | |||
| systems, and to associated areas, circuits, components, and | systems, and to associated areas, circuits, components, and | |||
| equipment, in which national security information is encrypted or | equipment, in which national security information is encrypted or | |||
| is not processed. [C4009] | is not processed. [C4009] | |||
| $ BLACK/Crypto/RED (BCR) | ||||
| (N) An experimental, end-to-end, network packet encryption system | ||||
| developed in a working prototype form by BBN and the Collins Radio | ||||
| division of Rockwell Corporation in the 1975-1980 time frame for | ||||
| the U.S. DoD. BCR was the first network security system to support | ||||
| TCP/IP traffic, and it incorporated the first DES chips that were | ||||
| validated by the U.S. National Bureau of Standards (now called | ||||
| NIST). BCR also was the first to use a KDC and an ACC to manage | ||||
| connections. | ||||
| $ BLACK key | $ BLACK key | |||
| (I) A key that is protected with a key-encrypting key and that | (I) A key that is protected with a key-encrypting key and that | |||
| must be decrypted before use. (Compare: RED key. See: BLACK.) | must be decrypted before use. (See: BLACK. Compare: RED key.) | |||
| $ BLACKER | $ BLACKER | |||
| (N) An end-to-end encryption system for computer data networks | (O) An end-to-end encryption system for computer data networks | |||
| that was developed by the U.S. DoD in the 1980s to provide host- | that was developed by the U.S. DoD in the 1980s to provide host- | |||
| to-host data confidentiality service for datagrams at OSIRM layer | to-host data confidentiality service for datagrams at OSIRM Layer | |||
| 3. [Weis] (Compare: Caneware, IPsec.) | 3. [Weis] (Compare: Caneware, IPsec.) | |||
| Tutorial: Each user host connects to its own bump-in-the-wire | Tutorial: Each user host connects to its own bump-in-the-wire | |||
| encryption device called a BLACKER Front End (BFE, TSEC/KI-111), | encryption device called a BLACKER Front End (BFE, TSEC/KI-111), | |||
| through which the host connects to the subnetwork. The system also | through which the host connects to the subnetwork. The system also | |||
| includes two types of centralized devices: one or more KDCs | includes two types of centralized devices: one or more KDCs | |||
| connect to the subnetwork and communicate with assigned sets of | connect to the subnetwork and communicate with assigned sets of | |||
| BFEs, and one or more ACCs connect to the subnetwork and | BFEs, and one or more ACCs connect to the subnetwork and | |||
| communicate with assigned KDCs. BLACKER uses only symmetric | communicate with assigned KDCs. BLACKER uses only symmetric | |||
| encryption. A KDC distributes session keys to BFE pairs as | encryption. A KDC distributes session keys to BFE pairs as | |||
| skipping to change at page 32, line 49 ¶ | skipping to change at page 34, line 8 ¶ | |||
| $ block | $ block | |||
| (I) A bit string or bit vector of finite length. (See: block | (I) A bit string or bit vector of finite length. (See: block | |||
| cipher. Compare: byte, word.) | cipher. Compare: byte, word.) | |||
| Usage: An "N-bit block" contains N bits, which usually are | Usage: An "N-bit block" contains N bits, which usually are | |||
| numbered from left to right as 1, 2, 3, ..., N. | numbered from left to right as 1, 2, 3, ..., N. | |||
| $ block cipher | $ block cipher | |||
| (I) An encryption algorithm that breaks plain text into fixed-size | (I) An encryption algorithm that breaks plain text into fixed-size | |||
| segments and uses the same key to transform each plaintext segment | segments and uses the same key to transform each plaintext segment | |||
| into a fixed-size segment of cipher text. Examples: Blowfish, DEA, | into a fixed-size segment of cipher text. Examples: AES, Blowfish, | |||
| IDEA, RC2, and SKIPJACK. (See: block, mode. Compare: stream | DEA, IDEA, RC2, and SKIPJACK. (See: block, mode. Compare: stream | |||
| cipher.) | cipher.) | |||
| Tutorial: A block cipher can be adapted to have a different | Tutorial: A block cipher can be adapted to have a different | |||
| external interface, such as that of a stream cipher, by using a | external interface, such as that of a stream cipher, by using a | |||
| mode of operation to "package" the basic algorithm. | mode of cryptographic operation to package the basic algorithm. | |||
| (See: CBC, CFB, DEA, ECB, OFB.) | ||||
| $ Blowfish | $ Blowfish | |||
| (N) A symmetric block cipher with variable-length key (32 to 448 | (N) A symmetric block cipher with variable-length key (32 to 448 | |||
| bits) designed in 1993 by Bruce Schneier as an unpatented, | bits) designed in 1993 by Bruce Schneier as an unpatented, | |||
| license-free, royalty-free replacement for DES or IDEA. [Schn] | license-free, royalty-free replacement for DES or IDEA. [Schn] | |||
| (See: Twofish.) | ||||
| $ brand | $ brand | |||
| 1. (I) A distinctive mark or name that identifies a product or | 1. (I) A distinctive mark or name that identifies a product or | |||
| business entity. | business entity. | |||
| 2. (O) /SET/ The name of a payment card. | 2. (O) /SET/ The name of a payment card. (See: BCA.) | |||
| Tutorial: Financial institutions and other companies have founded | Tutorial: Financial institutions and other companies have founded | |||
| payment card brands, protect and advertise the brands, establish | payment card brands, protect and advertise the brands, establish | |||
| and enforce rules for use and acceptance of their payment cards, | and enforce rules for use and acceptance of their payment cards, | |||
| and provide networks to interconnect the financial institutions. | and provide networks to interconnect the financial institutions. | |||
| These brands combine the roles of issuer and acquirer in | These brands combine the roles of issuer and acquirer in | |||
| interactions with cardholders and merchants. [SET1] | interactions with cardholders and merchants. [SET1] | |||
| $ brand certification authority (BCA) | $ brand certification authority (BCA) | |||
| (O) /SET/ A CA owned by a payment card brand, such as MasterCard, | (O) /SET/ A CA owned by a payment card brand, such as MasterCard, | |||
| skipping to change at page 33, line 44 ¶ | skipping to change at page 35, line 4 ¶ | |||
| (I) /cryptography/ To successfully perform cryptanalysis and thus | (I) /cryptography/ To successfully perform cryptanalysis and thus | |||
| succeed in decrypting data or performing some other cryptographic | succeed in decrypting data or performing some other cryptographic | |||
| function, without initially having knowledge of the key that the | function, without initially having knowledge of the key that the | |||
| function requires. (See: penetrate.) | function requires. (See: penetrate.) | |||
| Usage: This term applies to encrypted data or, more generally, to | Usage: This term applies to encrypted data or, more generally, to | |||
| a cryptographic algorithm or cryptographic system. | a cryptographic algorithm or cryptographic system. | |||
| $ Brewer-Nash model | $ Brewer-Nash model | |||
| (N) A security model [BN89] to enforce the Chinese wall policy. | (N) A security model [BN89] to enforce the Chinese wall policy. | |||
| (Compare: Bell-LaPadula model, Clark-Wilson model.) | (Compare: Bell-LaPadula model, Clark-Wilson model.) | |||
| Tutorial: All proprietary information in the set of commercial | Tutorial: All proprietary information in the set of commercial | |||
| firms F(1), F(2), ..., F(N) is categorized into mutually exclusive | firms F(1), F(2), ..., F(N) is categorized into mutually exclusive | |||
| conflict-of-interest classes I(1), I(2), ..., I(M) that apply | conflict-of-interest classes I(1), I(2), ..., I(M) that apply | |||
| across all firms. Each firm belongs to exactly one class. The | across all firms. Each firm belongs to exactly one class. The | |||
| Brewer-Nash model has the following mandatory rules: | Brewer-Nash model has the following mandatory rules: | |||
| - Brewer-Nash Read Rule: Subject S can read information object O | - Brewer-Nash Read Rule: Subject S can read information object O | |||
| from firm F(i) only if either (a) O is from the same firm as | from firm F(i) only if either (a) O is from the same firm as | |||
| some object previously read by S *or* (b) O belongs to a class | some object previously read by S *or* (b) O belongs to a class | |||
| I(i) from which S has not previously read any object. (See: | I(i) from which S has not previously read any object. (See: | |||
| object, subject.) | object, subject.) | |||
| - Brewer-Nash Write Rule: Subject S can write information object | ||||
| - Brewer-Nash Write Rule: Subject S can write information object | ||||
| O to firm F(i) only if (a) S can read O by the Brewer-Nash Read | O to firm F(i) only if (a) S can read O by the Brewer-Nash Read | |||
| Rule *and* (b) no object can be read by S from a different firm | Rule *and* (b) no object can be read by S from a different firm | |||
| F(j), no matter whether F(j) belongs to the same class as F(i) | F(j), no matter whether F(j) belongs to the same class as F(i) | |||
| or to a different class. | or to a different class. | |||
| $ bridge | $ bridge | |||
| (I) A gateway for traffic flowing at OSIRM layer 2 between two | (I) A gateway for traffic flowing at OSIRM Layer 2 between two | |||
| networks (usually two LANs). (Compare: router, bridge CA.) | networks (usually two LANs). (Compare: bridge CA, router.) | |||
| $ bridge CA | $ bridge CA | |||
| (I) A PKI consisting of only a CA that cross-certifies with CAs of | (I) A PKI consisting of only a CA that cross-certifies with CAs of | |||
| some other PKIs. (See: cross-certification. Compare: bridge.) | some other PKIs. (See: cross-certification. Compare: bridge.) | |||
| Tutorial: A bridge CA functions as a hub that enables a | Tutorial: A bridge CA functions as a hub that enables a | |||
| certificate user in any of the PKIs that attach to the bridge, to | certificate user in any of the PKIs that attach to the bridge, to | |||
| validate certficates issued in the other attached PKIs. | validate certificates issued in the other attached PKIs. | |||
| For example, a bridge CA (BCA) CA1 | For example, a bridge CA (BCA) CA1 | |||
| could cross-certify with four ^ | could cross-certify with four ^ | |||
| PKIs that have the roots CA1, | | PKIs that have the roots CA1, | | |||
| CA2, CA3, and CA4. The cross- v | CA2, CA3, and CA4. The cross- v | |||
| certificates that the roots CA2 <-> BCA <-> CA3 | certificates that the roots CA2 <-> BCA <-> CA3 | |||
| exchange with the BCA enable an ^ | exchange with the BCA enable an ^ | |||
| end entity EE1 certified under | | end entity EE1 certified under | | |||
| under CA1 in PK1 to construct v | under CA1 in PK1 to construct v | |||
| a certification path needed to CA4 | a certification path needed to CA4 | |||
| skipping to change at page 35, line 44 ¶ | skipping to change at page 37, line 4 ¶ | |||
| $ bulk encryption | $ bulk encryption | |||
| (N) "Simultaneous encryption of all channels of a multichannel | (N) "Simultaneous encryption of all channels of a multichannel | |||
| telecommunications link." [C4009] (Compare: bulk keying material.) | telecommunications link." [C4009] (Compare: bulk keying material.) | |||
| $ bulk key | $ bulk key | |||
| (D) In a few published descriptions of hybrid encryption for SSH, | (D) In a few published descriptions of hybrid encryption for SSH, | |||
| Windows 2000, and other applications, this term refers to a | Windows 2000, and other applications, this term refers to a | |||
| symmetric key that (a) is used to encrypt a relatively large | symmetric key that (a) is used to encrypt a relatively large | |||
| amount of data and (b) is itself encrypted with a public key. | amount of data and (b) is itself encrypted with a public key. | |||
| (Compare: bulk keying material.) | ||||
| Example: To send a large file to Bob, Alice (a) generates a | Example: To send a large file to Bob, Alice (a) generates a | |||
| symmetric key and uses it to encrypt the file (i.e., encrypt the | symmetric key and uses it to encrypt the file (i.e., encrypt the | |||
| bulk of the information that is to be sent) and then (b) encrypts | bulk of the information that is to be sent) and then (b) encrypts | |||
| that symmetric key (the "bulk key") with Bob's public key. | that symmetric key (the "bulk key") with Bob's public key. | |||
| Deprecated Term: ISDs SHOULD NOT use this term or definition; they | Deprecated Term: ISDs SHOULD NOT use this term or definition; they | |||
| are not well-established and could be confused with the | are not well-established and could be confused with the | |||
| established term "bulk keying material". Instead, use "symmetric | established term "bulk keying material". Instead, use "symmetric | |||
| key" and carefully explain how the key is applied. | key" and carefully explain how the key is applied. | |||
| $ bulk keying material | $ bulk keying material | |||
| (O) Refers to handling keying material in large quantities, e.g., | (N) Refers to handling keying material in large quantities, e.g., | |||
| as a dataset that contains many items of keying material. (See: | as a dataset that contains many items of keying material. (See: | |||
| type 0. Compare: bulk key, bulk encryption.) | type 0. Compare: bulk key, bulk encryption.) | |||
| $ bump-in-the-stack | $ bump-in-the-stack | |||
| (I) An implementation approach that places a network security | (I) An implementation approach that places a network security | |||
| mechanism inside the system that is to be protected. (Compare: | mechanism inside the system that is to be protected. (Compare: | |||
| bump-in-the-wire.) | bump-in-the-wire.) | |||
| Example: IPsec can be implemented inboard, in the protocol stack | Example: IPsec can be implemented inboard, in the protocol stack | |||
| of an existing system or existing system design, by placing a new | of an existing system or existing system design, by placing a new | |||
| layer placed between the existing IP layer and the OSIRM layer 3 | layer between the existing IP layer and the OSIRM Layer 3 drivers. | |||
| drivers. Source code access for the existing stack is not | Source code access for the existing stack is not required, but the | |||
| required, but the system that contains the stack does need to be | system that contains the stack does need to be modified [R2401]. | |||
| modified [R1401]. | ||||
| $ bump-in-the-wire | $ bump-in-the-wire | |||
| (I) An implementation approach that places a network security | (I) An implementation approach that places a network security | |||
| mechanism outside of the system that is to be protected. (Compare: | mechanism outside of the system that is to be protected. (Compare: | |||
| bump-in-the-stack.) | bump-in-the-stack.) | |||
| Example: IPsec can be implemented outboard, in a physically | Example: IPsec can be implemented outboard, in a physically | |||
| separate device, so that the system that receives the IPsec | separate device, so that the system that receives the IPsec | |||
| protection does not need to be modified at all [R1401]. Military- | protection does not need to be modified at all [R2401]. Military- | |||
| grade link encryption has mainly been implemented as bump-in-the- | grade link encryption has mainly been implemented as bump-in-the- | |||
| wire devices. | wire devices. | |||
| $ business case analysis | ||||
| (N) An extended form of cost-benefit analysis that considers | ||||
| factors beyond financial metrics, including security factors such | ||||
| as the requirement for security services, their technical and | ||||
| programmatic feasibility, their qualitative benefits, and | ||||
| associated risks. (See: risk analysis.) | ||||
| $ byte | $ byte | |||
| (I) A fundamental unit of computer storage; the smallest | (I) A fundamental unit of computer storage; the smallest | |||
| addressable unit in a computer's architecture. Usually holds one | addressable unit in a computer's architecture. Usually holds one | |||
| character of information and, today, usually means eight bits. | character of information and, today, usually means eight bits. | |||
| (Compare: octet.) | (Compare: octet.) | |||
| Usage: Understood to be larger than a "bit", but smaller than a | Usage: Understood to be larger than a "bit", but smaller than a | |||
| "word". Although "byte" almost always means "octet" today, some | "word". Although "byte" almost always means "octet" today, some | |||
| computer architectures have had bytes in other sizes (e.g., six | computer architectures have had bytes in other sizes (e.g., six | |||
| bits, nine bits). Therefore, an STD SHOULD state the number of | bits, nine bits). Therefore, an STD SHOULD state the number of | |||
| bits in a byte where the term is first used in the STD. | bits in a byte where the term is first used in the STD. | |||
| $ C field | $ C field | |||
| (D) See: Compartments field. | (D) See: Compartments field. | |||
| $ C1 computer system, C2 computer system | $ C1 or C2 computer system | |||
| (O) See: TCSEC. | (O) /TCSEC/ See: Tutorial under "Trusted Computer System | |||
| Evaluation Criteria". | ||||
| $ CA | $ CA | |||
| (I) See: certification authority. | (I) See: certification authority. | |||
| $ CA certificate | $ CA certificate | |||
| (D) "A [digital] certificate for one CA issued by another CA." | (D) "A [digital] certificate for one CA issued by another CA." | |||
| [X509] | [X509] | |||
| Deprecated Definition: An ISD that uses the term SHOULD state | Deprecated Definition: ISDs SHOULD NOT use the term with this | |||
| precisely how the certificate is constructed and how it is | definition; the definition is ambiguous with regard to how the | |||
| intended to be used; the X.509 definition is ambiguous with regard | certificate is constructed and how it is intended to be used. ISDs | |||
| to those details. (See: certificate profile.) | that use this term SHOULD provide a technical definition for it. | |||
| (See: certificate profile.) | ||||
| - Constraints: A v3 X.509 public-key certificate may have a | Tutorial: There is no single, obvious choice for a technical | |||
| "basicConstraints" extension containing a "cA" value of "TRUE" | definition of this term. Different PKIs can use different | |||
| that specifically indicates that "the certified public key may | certificate profiles, and X.509 provides several choices of how to | |||
| be used to verify certificate signatures." | issue certificates to CAs. For example, one possible definition is | |||
| - Key Usage: A v3 X.509 public-key certificate also may have a | the following: A v3 X.509 public-key certificate that has a | |||
| "key Usage" extension which indicates the purposes for which | "basicConstraints" extension containing a "cA" value of "TRUE". | |||
| the public key may be used. One purpose is "keyCertSign", for | That would specifically indicate that "the certified public key | |||
| verifying a CA's signature on certificates; and if this value | may be used to verify certificate signatures", i.e., that the | |||
| is present, than "cA" is also set to "TRUE" if the certificate | private key may be used by a CA. | |||
| also has a "basicConstraints" extension. | ||||
| However, a CA could be issued a certificate in which "keyCertSign" | However, there also are other ways to indicate such usage. The | |||
| is asserted without "basicConstraints" being present; and an | certificate may have a "key Usage" extension that indicates the | |||
| entity that acts as a CA could be issued a certificate with | purposes for which the public key may be used, and one of the | |||
| "keyUsage" set to other values, either with or without | values that X.509 defines for that extension is "keyCertSign", to | |||
| "keyCertSign". | indicate that the certificate may be used for verifying a CA's | |||
| signature on certificates. If "keyCertSign" is present in a | ||||
| certificate that also has a "basicConstraints" extension, than | ||||
| "cA" is set to "TRUE" in that extension. Alternatively, a CA could | ||||
| be issued a certificate in which "keyCertSign" is asserted without | ||||
| "basicConstraints" being present; and an entity that acts as a CA | ||||
| could be issued a certificate with "keyUsage" set to other values, | ||||
| either with or without "keyCertSign". | ||||
| $ Caesar cipher | $ Caesar cipher | |||
| (I) A cipher that, given an alphabet of N characters, A(1), A(2), | (I) A cipher that, given an alphabet of N characters, A(1), A(2), | |||
| character A(i) by A(i+K, mod N) for some 0<K<N+1. [Schn] | character A(i) by A(i+K, mod N) for some 0<K<N+1. [Schn] | |||
| Examples: (a) During the Gallic wars, Julius Caesar used a cipher | ||||
| Examples: During the Gallic wars, Julius Caesar used a cipher with | with K=3. In a Caesar cipher with K=3 for the English alphabet, A | |||
| K=3. In a Caesar cipher with K=3 for the English alphabet, A is | is replaced by D, B by E, C by F, ..., W by Z, X by A, Y by B, Z | |||
| replaced by D, B by E, C by F, ..., W by Z, X by A, Y by B, Z by | by C. (b) UNIX systems sometimes include "ROT13" software that | |||
| C. | implements a Caesar cipher with K=13 (i.e., ROTate by 13). | |||
| UNIX systems sometimes include ROT13 software that implements a | ||||
| Caesar cipher with K=13 (i.e., ROTate by 13). | ||||
| $ call back | $ call back | |||
| (I) An authentication technique for terminals that remotely access | (I) An authentication technique for terminals that remotely access | |||
| a computer via telephone lines; the host system disconnects the | a computer via telephone lines; the host system disconnects the | |||
| caller and then reconnects on a telephone number that was | caller and then reconnects on a telephone number that was | |||
| previously authorized for that terminal. | previously authorized for that terminal. | |||
| $ CAM | $ CAM | |||
| (O) See: Certificate Arbitrator Module. | (O) See: Certificate Arbitrator Module. | |||
| $ CANEWARE | $ CANEWARE | |||
| (N) A end-to-end encryption system for computer data networks that | (O) A end-to-end encryption system for computer data networks that | |||
| was developed by the U.S. DoD in the 1980s to provide host-to-host | was developed by the U.S. DoD in the 1980s to provide host-to-host | |||
| data confidentiality service for datagrams in OSIRM layer 3. | data confidentiality service for datagrams in OSIRM Layer 3. | |||
| [Roge] (Compare: BLACKER, IPsec.) | [Roge] (Compare: BLACKER, IPsec.) | |||
| Tutorial: Each user host connects to its own bump-in-the-wire | Tutorial: Each user host connects to its own bump-in-the-wire | |||
| encryption device called a CANEWARE Front End (CFE), through which | encryption device called a CANEWARE Front End (CFE), through which | |||
| the host connects to the subnetwork. CANEWARE uses symmetric | the host connects to the subnetwork. CANEWARE uses symmetric | |||
| encryption for CFE-to-CFE traffic, but also uses FIREFLY to | encryption for CFE-to-CFE traffic, but also uses FIREFLY to | |||
| establish those session keys. The public-key certificates issued | establish those session keys. The public-key certificates issued | |||
| by the FIREFLY system include credentials for mandatory access | by the FIREFLY system include credentials for mandatory access | |||
| control. For discretionary access control, the system also | control. For discretionary access control, the system also | |||
| includes one or more centralized CANEWARE Control Processors | includes one or more centralized CANEWARE Control Processors | |||
| skipping to change at page 38, line 25 ¶ | skipping to change at page 39, line 50 ¶ | |||
| subnetwork, so that the subnetwork can operate at a different | subnetwork, so that the subnetwork can operate at a different | |||
| security level than the hosts. (b) Like BLACKER, the CANEWARE | security level than the hosts. (b) Like BLACKER, the CANEWARE | |||
| components are trusted to separate datagrams of different security | components are trusted to separate datagrams of different security | |||
| levels, so that each datagram of a given security level can be | levels, so that each datagram of a given security level can be | |||
| received only by a host that is authorized for that security | received only by a host that is authorized for that security | |||
| level; and thus CANEWARE can separate host communities that | level; and thus CANEWARE can separate host communities that | |||
| operate at different security levels. (c) Unlike a BFE, the host | operate at different security levels. (c) Unlike a BFE, the host | |||
| side of a CFE is not MLS, and treats all packets received from a | side of a CFE is not MLS, and treats all packets received from a | |||
| user host as being at the same mandatory security level. | user host as being at the same mandatory security level. | |||
| $ capability | $ capability list | |||
| (I) /information system/ A mechanism that implements access | ||||
| control for a system entity by enumerating the system resources | ||||
| that the entity is permitted to access and, either implicitly or | ||||
| explicitly, the access modes granted for each resource. (Compare: | ||||
| access control list, access control matrix, access profile, | ||||
| capability token.) | ||||
| $ capability token | ||||
| (I) A token, usually an unforgeable data object, that gives the | (I) A token, usually an unforgeable data object, that gives the | |||
| bearer or holder the right to access a system resource. Possession | bearer or holder the right to access a system resource. Possession | |||
| of the token is accepted by a system as proof that the holder has | of the token is accepted by a system as proof that the holder has | |||
| been authorized to access the resource indicated by the token. | been authorized to access the resource indicated by the token. | |||
| (Compare: access control list. See: attribute certificate, | (See: attribute certificate, capability list, credential, digital | |||
| credential, digital certificate, ticket.) | certificate, ticket, token.) | |||
| $ Capability Maturity Model (CMM) | $ Capability Maturity Model (CMM) | |||
| (N) Method for judging the maturity of software processes in an | (N) Method for judging the maturity of software processes in an | |||
| organization and for identifying crucial practices needed to | organization and for identifying crucial practices needed to | |||
| increase process maturity. [Chris] (Compare: Common Criteria.) | increase process maturity. [Chris] (Compare: Common Criteria.) | |||
| Tutorial: The CMM does not specify security evaluation criteria | Tutorial: The CMM does not specify security evaluation criteria | |||
| (see: assurance level), but its use may improve security | (see: assurance level), but its use may improve security | |||
| assurance. The CMM describes principles and practices that can | assurance. The CMM describes principles and practices that can | |||
| improve software processes in terms of evolving from ad hoc | improve software processes in terms of evolving from ad hoc | |||
| processes to disciplined processes. The CMM has five levels: | processes to disciplined processes. The CMM has five levels: | |||
| - Initial: Software processes are ad hoc or chaotic, and few are | - Initial: Software processes are ad hoc or chaotic, and few are | |||
| well-defined. Success depends on individual effort and heroics. | well-defined. Success depends on individual effort and heroics. | |||
| - Repeatable: Basic project management processes are established | - Repeatable: Basic project management processes are established | |||
| to track cost, schedule, and functionality. Necessary process | to track cost, schedule, and functionality. Necessary process | |||
| discipline is in place to repeat earlier successes on projects | discipline is in place to repeat earlier successes on projects | |||
| with similar applications. | with similar applications. | |||
| - Defined: Software process for both management and engineering | - Defined: Software process for both management and engineering | |||
| activities is documented, standardized, and integrated into a | activities is documented, standardized, and integrated into a | |||
| standard software process for the organization. All projects | standard software process for the organization. Each project | |||
| use approved, tailored version of organization's standard | uses an approved, tailored version of the organization's | |||
| software process for developing and maintaining software. | standard process for developing and maintaining software. | |||
| - Managed: Detailed measures of software process and product | - Managed: Detailed measures of software process and product | |||
| quality are collected. Both software process and products are | quality are collected. Both software process and products are | |||
| quantitatively understood and controlled. | quantitatively understood and controlled. | |||
| - Optimizing: Continuous process improvement is enabled by | - Optimizing: Continuous process improvement is enabled by | |||
| quantitative feedback from the process and from piloting | quantitative feedback from the process and from piloting | |||
| innovative ideas and technologies. | innovative ideas and technologies. | |||
| $ CAPI | $ CAPI | |||
| (I) See: cryptographic application programming interface. | (I) See: cryptographic application programming interface. | |||
| $ CAPSTONE | $ CAPSTONE | |||
| (N) An integrated microcircuit (in MYK-8x series manufactured by | (N) An integrated microcircuit (in MYK-8x series manufactured by | |||
| Mykotronx, Inc.) that implements SKIPJACK, KEA, DSA, SHA, and | Mykotronx, Inc.) that implements SKIPJACK, KEA, DSA, SHA, and | |||
| basic mathematical functions needed to support asymmetric | basic mathematical functions needed to support asymmetric | |||
| skipping to change at page 40, line 18 ¶ | skipping to change at page 41, line 52 ¶ | |||
| and payment gateway CAs. [SET2] | and payment gateway CAs. [SET2] | |||
| $ CAST | $ CAST | |||
| (N) A design procedure for symmetric encryption algorithms, and a | (N) A design procedure for symmetric encryption algorithms, and a | |||
| resulting family of algorithms, invented by Carlisle Adams (C.A.) | resulting family of algorithms, invented by Carlisle Adams (C.A.) | |||
| and Stafford Tavares (S.T.). [R2144, R2612] | and Stafford Tavares (S.T.). [R2144, R2612] | |||
| $ category | $ category | |||
| (I) A grouping of sensitive information items to which a non- | (I) A grouping of sensitive information items to which a non- | |||
| hierarchical restrictive security label is applied to increase | hierarchical restrictive security label is applied to increase | |||
| protection of the data. (See: compartment. Compare: | protection of the data. (See: formal access approval. Compare: | |||
| classification.) | category, classification.) | |||
| $ CAW | $ CAW | |||
| (O) See: certification authority workstation. | (N) See: certification authority workstation. | |||
| $ CBC | $ CBC | |||
| (N) See: cipher block chaining. | (N) See: cipher block chaining. | |||
| $ CCA | $ CCA | |||
| (O) See: cardholder certification authority. | (O) See: cardholder certification authority. | |||
| $ CCEP | $ CCEP | |||
| (O) See: Commercial COMSEC Endorsement Program. | (O) See: Commercial COMSEC Endorsement Program. | |||
| $ CCI | $ CCI | |||
| (O) See: Controlled Cryptographic Item. | (O) See: Controlled Cryptographic Item. | |||
| $ CCITT | $ CCITT | |||
| (N) Acronym for French translation of International Telephone and | (N) Acronym for French translation of International Telephone and | |||
| Telegraph Consultative Committee. Now renamed ITU-T. | Telegraph Consultative Committee. Now renamed ITU-T. | |||
| $ CERIAS | $ CERIAS | |||
| (O) Purdue University's Center for Education and Research in | (O) Purdue University's Center for Education and Research in | |||
| Information Assurance and Security, which includes faculty from | Information Assurance and Security, which includes faculty from | |||
| multiple schools and departments and takes multidisciplinary | multiple schools and departments and takes a multidisciplinary | |||
| approach to security problems ranging from technical to ethical, | approach to security problems ranging from technical to ethical, | |||
| legal, educational, communicational, linguistic, and economic. | legal, educational, communicational, linguistic, and economic. | |||
| $ CERT | $ CERT | |||
| (I) See: computer emergency response team. | (I) See: computer emergency response team. | |||
| $ certificate | $ certificate | |||
| 1. (I) /general English/ A document that attests to the truth of | 1. (I) /general English/ A document that attests to the truth of | |||
| something or the ownership of something. | something or the ownership of something. | |||
| 2. (I) /general security/ See: capability, digital certificate. | 2. (I) /general security/ See: capability token, digital | |||
| certificate. | ||||
| 3. (I) /PKI/ See: attribute certificate, public-key certificate. | 3. (I) /PKI/ See: attribute certificate, public-key certificate. | |||
| $ Certificate Arbitrator Module (CAM) | $ Certificate Arbitrator Module (CAM) | |||
| (O) An open-source software module that is designed to be | (O) An open-source software module that is designed to be | |||
| integrated with an application for the purpose of routing, | integrated with an application for the purpose of routing, | |||
| replying to, and otherwise managing and meditating certificate | replying to, and otherwise managing and meditating certificate | |||
| validation requests between that application and the CAs in the | validation requests between that application and the CAs in the | |||
| ACES PKI. | ACES PKI. | |||
| $ certificate authority | $ certificate authority | |||
| (D) Synonym for "certification authority". | (D) Synonym for "certification authority". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it looks like | Deprecated Term: ISDs SHOULD NOT use this term; it suggests | |||
| sloppy use of "certification authority", which is the term | careless use of the term "certification authority", which is | |||
| standardized by X.509. A person who uses this term probably has | standardized by X.509. A person who uses this term probably has | |||
| not read the PKI standards [X509, R2459]. | never read the basic technical standards for PKI [X509, R3280]. | |||
| $ certificate chain | $ certificate chain | |||
| (D) Synonym for "certification path". (See: trust chain.) | (D) Synonym for "certification path". (See: trust chain.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it duplicates the | Deprecated Term: ISDs SHOULD NOT use this term; it duplicates the | |||
| meaning of a standardized term. Instead, use "certification path". | meaning of a standardized term. Instead, use "certification path". | |||
| $ certificate chain validation | $ certificate chain validation | |||
| (D) Synonym for "certificate validation" or "path validation". | (D) Synonym for "certificate validation" or "path validation". | |||
| skipping to change at page 42, line 8 ¶ | skipping to change at page 43, line 44 ¶ | |||
| Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | |||
| the subject of a digital certificate; the term is potentially | the subject of a digital certificate; the term is potentially | |||
| ambiguous. For example, the term could refer to a system entity or | ambiguous. For example, the term could refer to a system entity or | |||
| component, such as a repository, that simply has possession of a | component, such as a repository, that simply has possession of a | |||
| copy of the certificate. | copy of the certificate. | |||
| $ certificate management | $ certificate management | |||
| (I) The functions that a CA may perform during the life cycle of a | (I) The functions that a CA may perform during the life cycle of a | |||
| digital certificate, including the following: | digital certificate, including the following: | |||
| - Acquire and verify data items to bind into the certificate. | - Acquire and verify data items to bind into the certificate. | |||
| - Encode and sign the certificate. | - Encode and sign the certificate. | |||
| - Store the certificate in a directory or repository. | - Store the certificate in a directory or repository. | |||
| - Renew, rekey, and update the certificate. | - Renew, rekey, and update the certificate. | |||
| - Revoke the certificate and issue a CRL. | - Revoke the certificate and issue a CRL. | |||
| (See: archive management, certificate management, key management, | (See: archive management, certificate management, key management, | |||
| security architecture, token management.) | security architecture, token management.) | |||
| $ certificate management authority (CMA) | $ certificate management authority (CMA) | |||
| (D) /U.S. DoD/ Used to mean either a CA or an RA. [DoD3, SP32] | (D) /U.S. DoD/ Used to mean either a CA or an RA. [DoD3, SP32] | |||
| Deprecated Term: ISDs SHOULD NOT use this term because it is | Deprecated Term: ISDs SHOULD NOT use this term because it is | |||
| potentially ambiguous, such as in a context involve ICRLs. | potentially ambiguous, such as in a context involve ICRLs. | |||
| Instead, use CA, RA, or both, depending on what is meant. | Instead, use CA, RA, or both, depending on what is meant. | |||
| skipping to change at page 42, line 35 ¶ | skipping to change at page 44, line 19 ¶ | |||
| Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | |||
| the subject of a digital certificate; the term is potentially | the subject of a digital certificate; the term is potentially | |||
| ambiguous. For example, the term could refer to a system entity, | ambiguous. For example, the term could refer to a system entity, | |||
| such as a corporation, that has acquired a certificate to operate | such as a corporation, that has acquired a certificate to operate | |||
| equipment, such as a Web server. | equipment, such as a Web server. | |||
| $ certificate path | $ certificate path | |||
| (D) Synonym for "certification path". | (D) Synonym for "certification path". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it looks like | Deprecated Term: ISDs SHOULD NOT use this term; it suggests | |||
| sloppy use of "certification path", which is the term standardized | careless use of "certification path", which is a term standardized | |||
| by X.509. A person who uses this term probably has not read the | by X.509. A person who uses this term probably has never read the | |||
| PKI standards [X509, R2459]. | basic technical standards for PKI [X509, R3280]. | |||
| $ certificate policy | $ certificate policy | |||
| (I) "A named set of rules that indicates the applicability of a | (I) "A named set of rules that indicates the applicability of a | |||
| certificate to a particular community and/or class of application | certificate to a particular community and/or class of application | |||
| with common security requirements." [X509] (Compare: CPS.) | with common security requirements." [X509] (Compare: CPS.) | |||
| Example: The U.S. DoD's certificate policy [DoD3] defines four | Example: The U.S. DoD's certificate policy [DoD3] defines four | |||
| classes (i.e., assurance levels) for X.509 public-key certificates | classes (i.e., assurance levels) for X.509 public-key certificates | |||
| and defines the applicability of those classes. (See: class 2.) | and defines the applicability of those classes. (See: class 2.) | |||
| Tutorial: A certificate policy can help a certificate user to | Tutorial: A certificate policy can help a certificate user to | |||
| decide whether a certificate should be trusted in a particular | decide whether a certificate should be trusted in a particular | |||
| application. "For example, a particular certificate policy might | application. "For example, a particular certificate policy might | |||
| indicate applicability of a type of certificate for the | indicate applicability of a type of certificate for the | |||
| authentication of electronic data interchange transactions for the | authentication of electronic data interchange transactions for the | |||
| trading of goods within a given price range." [R2527] | trading of goods within a given price range." [R3647] | |||
| A v3 X.509 public-key certificate may have a "certificatePolicies" | A v3 X.509 public-key certificate may have a "certificatePolicies" | |||
| extension that lists certificate policies, recognized by the | extension that lists certificate policies, recognized by the | |||
| issuing CA, that apply to the certificate and govern its use. Each | issuing CA, that apply to the certificate and govern its use. Each | |||
| policy is denoted by an object identifier and may optionally have | policy is denoted by an object identifier and may optionally have | |||
| certificate policy qualifiers. (See: certificate profile.) | certificate policy qualifiers. (See: certificate profile.) | |||
| Each SET certificate specifies at least one certificate policy, | Each SET certificate specifies at least one certificate policy, | |||
| that of the SET root CA. SET uses certificate policy qualifiers to | that of the SET root CA. SET uses certificate policy qualifiers to | |||
| point to the actual policy statement and to add qualifying | point to the actual policy statement and to add qualifying | |||
| policies to the root policy. (See: SET qualifier.) | policies to the root policy. (See: SET qualifier.) | |||
| $ certificate policy qualifier | $ certificate policy qualifier | |||
| (I) Information that pertains to a certificate policy and is | (I) Information that pertains to a certificate policy and is | |||
| included in a "certificatePolicies" extension in a v3 X.509 | included in a "certificatePolicies" extension in a v3 X.509 | |||
| public-key certificate. | public-key certificate. | |||
| $ certificate profile | $ certificate profile | |||
| (I) A specification (e.g., [DoD3, R2459]) of the format and | (I) A specification (e.g., [DoD3, R3280]) of the format and | |||
| semantics of public-key certificates or attribute certificates, | semantics of public-key certificates or attribute certificates, | |||
| constructed for use in a specific application context by selecting | constructed for use in a specific application context by selecting | |||
| from among options offered by a broader standard. | from among options offered by a broader standard. | |||
| $ certificate reactivation | $ certificate reactivation | |||
| (I) The act or process by which a digital certificate, which a CA | (I) The act or process by which a digital certificate, which a CA | |||
| has designated for revocation but not yet listed on a CRL, is | has designated for revocation but not yet listed on a CRL, is | |||
| returned to the valid state. | returned to the valid state. | |||
| $ certificate rekey | $ certificate rekey | |||
| skipping to change at page 44, line 23 ¶ | skipping to change at page 46, line 5 ¶ | |||
| number is assigned) but the binding of the public key to the | number is assigned) but the binding of the public key to the | |||
| subject and to other data items stays the same. The other data | subject and to other data items stays the same. The other data | |||
| items are changed, and the old certificate is revoked, only as | items are changed, and the old certificate is revoked, only as | |||
| required by the PKI and CPS to support the renewal. If changes go | required by the PKI and CPS to support the renewal. If changes go | |||
| beyond that, the process is a "certificate rekey" or "certificate | beyond that, the process is a "certificate rekey" or "certificate | |||
| update". | update". | |||
| $ certificate request | $ certificate request | |||
| (D) Synonym for "certification request". | (D) Synonym for "certification request". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it looks like | Deprecated Term: ISDs SHOULD NOT use this term; it suggests | |||
| imprecise use of a term standardized by PKCS #10 and used in PKIX. | careless use of the term "certification request", which is | |||
| Instead, use "certification request". | standardized by PKCS #10 and used in PKIX. Instead, use | |||
| "certification request". | ||||
| $ certificate revocation | $ certificate revocation | |||
| (I) The event that occurs when a CA declares that a previously | (I) The event that occurs when a CA declares that a previously | |||
| valid digital certificate issued by that CA has become invalid; | valid digital certificate issued by that CA has become invalid; | |||
| usually stated with a effective date. | usually stated with a effective date. | |||
| Tutorial: In X.509, a revocation is announced to potential | Tutorial: In X.509, a revocation is announced to potential | |||
| certificate users by issuing a CRL that mentions the certificate. | certificate users by issuing a CRL that mentions the certificate. | |||
| Revocation and listing on a CRL is only necessary prior to the | Revocation and listing on a CRL is only necessary prior to the | |||
| certificate's scheduled expiration. | certificate's scheduled expiration. | |||
| skipping to change at page 44, line 49 ¶ | skipping to change at page 46, line 32 ¶ | |||
| have been invalidated by their issuer prior to when they were | have been invalidated by their issuer prior to when they were | |||
| scheduled to expire. (See: certificate expiration, delta CRL, | scheduled to expire. (See: certificate expiration, delta CRL, | |||
| X.509 certificate revocation list.) | X.509 certificate revocation list.) | |||
| 2. (O) "A signed list indicating a set of certificates that are no | 2. (O) "A signed list indicating a set of certificates that are no | |||
| longer considered valid by the certificate issuer. In addition to | longer considered valid by the certificate issuer. In addition to | |||
| the generic term CRL, some specific CRL types are defined for CRLs | the generic term CRL, some specific CRL types are defined for CRLs | |||
| that cover particular scopes." [X509] | that cover particular scopes." [X509] | |||
| $ certificate revocation tree | $ certificate revocation tree | |||
| (I) A mechanism for distributing notice of certificate | (N) A mechanism for distributing notice of certificate | |||
| revocations; uses a tree of hash results that is signed by the | revocations; uses a tree of hash results that is signed by the | |||
| tree's issuer. Offers an alternative to issuing a CRL, but is not | tree's issuer. Offers an alternative to issuing a CRL, but is not | |||
| supported in X.509. (See: certificate status responder.) | supported in X.509. (See: certificate status responder.) | |||
| $ certificate serial number | $ certificate serial number | |||
| 1. (I) An integer value that (a) is associated with, and may be | 1. (I) An integer value that (a) is associated with, and may be | |||
| carried in, a digital certificate; (b) is assigned to the | carried in, a digital certificate; (b) is assigned to the | |||
| certificate by the certificate's issuer; and (c) is unique among | certificate by the certificate's issuer; and (c) is unique among | |||
| all the certificates produced by that issuer. | all the certificates produced by that issuer. | |||
| 2. (O) "An integer value, unique within the issuing CA, which is | 2. (O) "An integer value, unique within the issuing CA, which is | |||
| unambiguously associated with a certificate issued by that CA." | unambiguously associated with a certificate issued by that CA." | |||
| [X509] | [X509] | |||
| $ certificate status authority | $ certificate status authority | |||
| (D) /U.S. DoD/ "A trusted entity that provides on-line | (D) /U.S. DoD/ "A trusted entity that provides on-line | |||
| verification to a Relying Party of a subject certificate's | verification to a Relying Party of a subject certificate's | |||
| trustworthiness [should say 'validity'], and may also provide | trustworthiness [should instead say 'validity'], and may also | |||
| additional attribute information for the subject certificate." | provide additional attribute information for the subject | |||
| [DoD3] | certificate." [DoD3] | |||
| Deprecated Term: ISDs SHOULD NOT use this term because it is not | Deprecated Term: ISDs SHOULD NOT use this term because it is not | |||
| widely accepted; instead, use "certificate status responder" or | widely accepted; instead, use "certificate status responder" or | |||
| "OCSP server", or otherwise explain what is meant. | "OCSP server", or otherwise explain what is meant. | |||
| $ certificate status responder | $ certificate status responder | |||
| (N) /FPKI/ A trusted on-line server that acts for a CA to provide | (N) /FPKI/ A trusted on-line server that acts for a CA to provide | |||
| authenticated certificate status information to certificate users | authenticated certificate status information to certificate users | |||
| [FPKI]. Offers an alternative to issuing a CRL, but is not | [FPKI]. Offers an alternative to issuing a CRL, but is not | |||
| supported in X.509. (See: certificate revocation tree, OCSP.) | supported in X.509. (See: certificate revocation tree, OCSP.) | |||
| skipping to change at page 46, line 20 ¶ | skipping to change at page 48, line 4 ¶ | |||
| 2. (O) "The process of ensuring that a certificate was valid at a | 2. (O) "The process of ensuring that a certificate was valid at a | |||
| given time, including possibly the construction and processing of | given time, including possibly the construction and processing of | |||
| a certification path, and ensuring that all certificates in that | a certification path, and ensuring that all certificates in that | |||
| path were valid (i.e. were not expired or revoked) at that given | path were valid (i.e. were not expired or revoked) at that given | |||
| time." [X509] | time." [X509] | |||
| Tutorial: To validate a certificate, a certificate user checks | Tutorial: To validate a certificate, a certificate user checks | |||
| that the certificate is properly formed and signed and is | that the certificate is properly formed and signed and is | |||
| currently in force: | currently in force: | |||
| - Checks the syntax and semantics: Parses the certificate's | ||||
| - Checks the syntax and semantics: Parses the certificate's | ||||
| syntax and interprets its semantics, applying rules specified | syntax and interprets its semantics, applying rules specified | |||
| for and by its data fields, such as for critical extensions in | for and by its data fields, such as for critical extensions in | |||
| an X.509 certificate. | an X.509 certificate. | |||
| - Checks the signature: Uses the issuer's public key to verify | - Checks the signature: Uses the issuer's public key to verify | |||
| the digital signature of the CA who issued the certificate in | the digital signature of the CA who issued the certificate in | |||
| question. If the verifier obtains the issuer's public key from | question. If the verifier obtains the issuer's public key from | |||
| the issuer's own public-key certificate, that certificate | the issuer's own public-key certificate, that certificate | |||
| should be validated, too. That validation may lead to yet | should be validated, too. That validation may lead to yet | |||
| another certificate to be validated, and so on. Thus, in | another certificate to be validated, and so on. Thus, in | |||
| general, certificate validation involves discovering and | general, certificate validation involves discovering and | |||
| validating a certification path. | validating a certification path. | |||
| - Checks currency and revocation: Verifies that the certificate | - Checks currency and revocation: Verifies that the certificate | |||
| is currently in force by checking that the current date and | is currently in force by checking that the current date and | |||
| time are within the validity period (if that is specified in | time are within the validity period (if that is specified in | |||
| the certificate) and that the certificate is not listed on a | the certificate) and that the certificate is not listed on a | |||
| CRL or otherwise announced as invalid. (CRLs themselves require | CRL or otherwise announced as invalid. (The CRLs also must be | |||
| a similar validation process.) | checked by a similar validation process.) | |||
| $ certification | $ certification | |||
| 1. (I) /information system/ Comprehensive evaluation (usually made | 1. (I) /information system/ Comprehensive evaluation (usually made | |||
| in support of an accreditation action) of an information system's | in support of an accreditation action) of an information system's | |||
| technical security features and other safeguards to establish the | technical security features and other safeguards to establish the | |||
| extent to which the system's design and implementation meet a set | extent to which the system's design and implementation meet a set | |||
| of specified security requirements. [C4009, FP102, SP37] (See: | of specified security requirements. [C4009, FP102, SP37] (See: | |||
| accreditation. Compare: evaluation.) | accreditation. Compare: evaluation.) | |||
| 2. (I) /digital certificate/ The act or process of vouching for | 2. (I) /digital certificate/ The act or process of vouching for | |||
| skipping to change at page 47, line 33 ¶ | skipping to change at page 49, line 17 ¶ | |||
| provided by a certificate. Thus, a CA should be someone that | provided by a certificate. Thus, a CA should be someone that | |||
| certificate users trust, and usually holds an official position | certificate users trust, and usually holds an official position | |||
| created and granted power by a government, a corporation, or some | created and granted power by a government, a corporation, or some | |||
| other organization. A CA is responsible for managing the life | other organization. A CA is responsible for managing the life | |||
| cycle of certificates (see: certificate management) and, depending | cycle of certificates (see: certificate management) and, depending | |||
| on the type of certificate and the CPS that applies, may be | on the type of certificate and the CPS that applies, may be | |||
| responsible for the life cycle of key pairs associated with the | responsible for the life cycle of key pairs associated with the | |||
| certificates (see: key management). | certificates (see: key management). | |||
| $ certification authority workstation (CAW) | $ certification authority workstation (CAW) | |||
| (O) A computer system that enables a CA to issue digital | (N) A computer system that enables a CA to issue digital | |||
| certificates and supports other certificate management functions | certificates and supports other certificate management functions | |||
| as required. | as required. | |||
| $ certification hierarchy | $ certification hierarchy | |||
| 1. (I) A tree-structured (loop-free) topology of relationships | 1. (I) A tree-structured (loop-free) topology of relationships | |||
| among CAs and the entities to whom the CAs issue public-key | among CAs and the entities to whom the CAs issue public-key | |||
| certificates. (See: hierarchical PKI, hierarchy management.) | certificates. (See: hierarchical PKI, hierarchy management.) | |||
| Tutorial: In this structure, one CA is the top CA, the highest | Tutorial: In this structure, one CA is the top CA, the highest | |||
| level of the hierarchy. (See: root, top CA.) The top CA may issue | level of the hierarchy. (See: root, top CA.) The top CA may issue | |||
| public-key certificates to one or more additional CAs that form | public-key certificates to one or more additional CAs that form | |||
| the second-highest level. Each of these CAs may issue certificates | the second-highest level. Each of these CAs may issue certificates | |||
| to more CAs at the third highest level, and so on. The CAs at the | to more CAs at the third highest level, and so on. The CAs at the | |||
| second-lowest level issue certificates only to non-CA entities | second-lowest level issue certificates only to non-CA entities | |||
| that form the lowest level (see: end entity). Thus, all | that form the lowest level (see: end entity). Thus, all | |||
| certification paths begin at the top CA and descend through zero | certification paths begin at the top CA and descend through zero | |||
| or more levels of other CAs. All certificate users base path | or more levels of other CAs. All certificate users base path | |||
| validations on the top CA's public key. | validations on the top CA's public key. | |||
| 2. (O) /MISSI/ A certification hierarchy for MISSI has three or | 2. (I) /PEM/ A certification hierarchy for PEM has three levels of | |||
| CAs [R1422]: | ||||
| - The highest level is the "Internet Policy Registration | ||||
| Authority". | ||||
| - A CA at the second-highest level is a "policy certification | ||||
| authority". | ||||
| - A CA at the third-highest level is a "certification authority". | ||||
| 3. (O) /MISSI/ A certification hierarchy for MISSI has three or | ||||
| four levels of CAs: | four levels of CAs: | |||
| - A CA at the highest level, the top CA, is a "policy approving | - A CA at the highest level, the top CA, is a "policy approving | |||
| authority". | authority". | |||
| - A CA at the second-highest level is a "policy creation | - A CA at the second-highest level is a "policy creation | |||
| authority". | authority". | |||
| - A CA at the third-highest level is a local authority called a | - A CA at the third-highest level is a local authority called a | |||
| "certification authority". | "certification authority". | |||
| - A CA at the fourth-highest (optional) level is a "subordinate | - A CA at the fourth-highest (optional) level is a "subordinate | |||
| certification authority". | certification authority". | |||
| 3. (O) /PEM/ A certification hierarchy for PEM has three levels of | ||||
| CAs [R1422]: | ||||
| - The highest level is the "Internet Policy Registration | ||||
| Authority". | ||||
| - A CA at the second-highest level is a "policy certification | ||||
| authority". | ||||
| - A CA at the third-highest level is a "certification authority". | ||||
| 4. (O) /SET/ A certification hierarchy for SET has three or four | 4. (O) /SET/ A certification hierarchy for SET has three or four | |||
| levels of CAs: | levels of CAs: | |||
| - The highest level is a "SET root CA". | - The highest level is a "SET root CA". | |||
| - A CA at the second-highest level is a "brand certification | - A CA at the second-highest level is a "brand certification | |||
| authority". | authority". | |||
| - A CA at the third-highest (optional) level is a "geopolitical | - A CA at the third-highest (optional) level is a "geopolitical | |||
| certification authority". | certification authority". | |||
| - A CA at the fourth-highest level is a "cardholder CA", a | - A CA at the fourth-highest level is a "cardholder CA", a | |||
| "merchant CA", or a "payment gateway CA". | "merchant CA", or a "payment gateway CA". | |||
| $ certification path | $ certification path | |||
| 1. (I) An ordered sequence of public-key certificates (or a | 1. (I) A linked sequence of one or more public-key certificates, | |||
| sequence of public-key certificates followed by one attribute | or one or more public-key certificates and one attribute | |||
| certificate) that enables a certificate user to verify the | certificate, that enables a certificate user to verify the | |||
| signature on the last certificate in the path, and thus enables | signature on the last certificate in the path, and thus enables | |||
| the user to obtain a certified public key (or certified | the user to obtain (from that last certificate) a certified public | |||
| attributes) of the entity that is the subject of that last | key, or certified attributes, of the system entity that is the | |||
| certificate. (See: certificate validation, valid certificate.) | subject of that last certificate. (See: trust anchor, certificate | |||
| validation, valid certificate.) | ||||
| 2. (O) "An ordered sequence of certificates of objects in the | 2. (O) "An ordered sequence of certificates of objects in the | |||
| [X.500 Directory Information Tree] which, together with the public | [X.500 Directory Information Tree] which, together with the public | |||
| key of the initial object in the path, can be processed to obtain | key of the initial object in the path, can be processed to obtain | |||
| that of the final object in the path." [R2527, X509] | that of the final object in the path." [R3647, X509] | |||
| Tutorial: The path is the "list of certificates needed to allow a | Tutorial: The list is "linked" in the sense that the digital | |||
| particular user to obtain the public key of another." [X509] The | signature of each certificate (except possibly the first) is | |||
| list is "linked" in the sense that the digital signature of each | verified by the public key contained in the preceding certificate; | |||
| certificate (except the first) is verified by the public key | i.e., the private key used to sign a certificate and the public | |||
| contained in the preceding certificate; i.e., the private key used | key contained in the preceding certificate form a key pair that | |||
| to sign a certificate and the public key contained in the | has previously been bound to the authority that signed. | |||
| preceding certificate form a key pair owned by the entity that | ||||
| signed. | ||||
| In the X.509 quotation in the previous paragraph, the word | The path is the "list of certificates needed to [enable] a | |||
| "particular" points out that a certification path that can be | particular user to obtain the public key [or attributes] of | |||
| validated by one certificate user might not be able to be | another [user]." [X509] Here, the word "particular" points out | |||
| validated by another. That is because either the first certificate | that a certification path that can be validated by one certificate | |||
| should be a trusted certificate (it might be a root certificate) | user might not be able to be validated by another. That is because | |||
| or the signature on the first certificate should be verified by a | either the first certificate needs to be a trusted certificate or | |||
| trusted key (it might be a root key), but such trust is defined | the signature on the first certificate needs to be verifiable by a | |||
| relative to each user, not absolutely for all users. | trusted key (e.g., a root key), but such trust is established only | |||
| relative to a "particular" (i.e., specific) user, not absolutely | ||||
| for all users. | ||||
| $ certification policy | $ certification policy | |||
| (D) Synonym for either "certificate policy" or "certification | (D) Synonym for either "certificate policy" or "certification | |||
| practice statement". | practice statement". | |||
| Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | |||
| either of the terms given here. Instead, use either "certificate | either of those terms; that would be duplicative and would mix | |||
| policy" or "certification practice statement", depending on what | concepts in a potentially misleading way. Instead, use either | |||
| is meant. | "certificate policy" or "certification practice statement", | |||
| depending on what is meant. | ||||
| $ certification practice statement (CPS) | $ certification practice statement (CPS) | |||
| (I) "A statement of the practices which a certification authority | (I) "A statement of the practices which a certification authority | |||
| employs in issuing certificates." [ABA96, R2527] (See: certificate | employs in issuing certificates." [ABA96, R3647] (See: certificate | |||
| policy.) | policy.) | |||
| Tutorial: A CPS is a published security policy that can help a | Tutorial: A CPS is a published security policy that can help a | |||
| certificate user to decide whether a certificate issued by a | certificate user to decide whether a certificate issued by a | |||
| particular CA can be trusted enough to use in a particular | particular CA can be trusted enough to use in a particular | |||
| application. A CPS may be (a) a declaration by a CA of the details | application. A CPS may be (a) a declaration by a CA of the details | |||
| of the system and practices it uses in its certificate management | of the system and practices it uses in its certificate management | |||
| operations, (b) part of a contract between the CA and an entity to | operations, (b) part of a contract between the CA and an entity to | |||
| whom a certificate is issued, (c) a statute or regulation | whom a certificate is issued, (c) a statute or regulation | |||
| applicable to the CA, or (d) a combination of these types | applicable to the CA, or (d) a combination of these types | |||
| involving multiple documents. [ABA] | involving multiple documents. [ABA] | |||
| A CPS is usually more detailed and procedurally oriented than a | A CPS is usually more detailed and procedurally oriented than a | |||
| certificate policy. A CPS applies to a particular CA or CA | certificate policy. A CPS applies to a particular CA or CA | |||
| community, while a certificate policy applies across CAs or | community, while a certificate policy applies across CAs or | |||
| communities. A CA with its single CPS may support multiple | communities. A CA with its single CPS may support multiple | |||
| certificate policies, which may be used for different application | certificate policies, which may be used for different application | |||
| purposes or by different user communities. On the other hand, | purposes or by different user communities. On the other hand, | |||
| multiple CAs, each with a different CPS, may support the same | multiple CAs, each with a different CPS, may support the same | |||
| certificate policy. [R2527] | certificate policy. [R3647] | |||
| $ certification request | $ certification request | |||
| (I) A algorithm-independent transaction format, defined by PCKS | (I) A algorithm-independent transaction format, defined by PKCS | |||
| #10 and used in PKIX, that contains a DN, a public key, and | #10 and used in PKIX, that contains a DN, a public key, and | |||
| optionally a set of attributes, collectively signed by the entity | optionally a set of attributes, collectively signed by the entity | |||
| requesting certification, and sent to a CA, which transforms the | requesting certification, and sent to a CA, which transforms the | |||
| request to an X.509 public-key certificate or another type of | request to an X.509 public-key certificate or another type of | |||
| certificate. | certificate. | |||
| $ certify | $ certify | |||
| 1. (I) Issue a digital certificate and thus vouch for the truth, | 1. (I) Issue a digital certificate and thus vouch for the truth, | |||
| accuracy, and binding between data items in the certificate (e.g., | accuracy, and binding between data items in the certificate (e.g., | |||
| see: X.509 public-key certificate), such as the identity of the | see: X.509 public-key certificate), such as the identity of the | |||
| skipping to change at page 50, line 4 ¶ | skipping to change at page 51, line 42 ¶ | |||
| optionally a set of attributes, collectively signed by the entity | optionally a set of attributes, collectively signed by the entity | |||
| requesting certification, and sent to a CA, which transforms the | requesting certification, and sent to a CA, which transforms the | |||
| request to an X.509 public-key certificate or another type of | request to an X.509 public-key certificate or another type of | |||
| certificate. | certificate. | |||
| $ certify | $ certify | |||
| 1. (I) Issue a digital certificate and thus vouch for the truth, | 1. (I) Issue a digital certificate and thus vouch for the truth, | |||
| accuracy, and binding between data items in the certificate (e.g., | accuracy, and binding between data items in the certificate (e.g., | |||
| see: X.509 public-key certificate), such as the identity of the | see: X.509 public-key certificate), such as the identity of the | |||
| certificate's subject and the ownership of a public key. (See: | certificate's subject and the ownership of a public key. (See: | |||
| certification.) | certification.) | |||
| Usage: To "certify a public key" means to issue a public-key | Usage: To "certify a public key" means to issue a public-key | |||
| certificate that vouches for the binding between the certificate's | certificate that vouches for the binding between the certificate's | |||
| subject and the key. | subject and the key. | |||
| 2. (I) The act by which a CA uses measures to verify the truth, | 2. (I) The act by which a CA uses measures to verify the truth, | |||
| accuracy, and binding between data items in a digital certificate. | accuracy, and binding between data items in a digital certificate. | |||
| Tutorial: A description of the measures used for verification | Tutorial: A description of the measures used for verification | |||
| should be included in the CA's CPS. | should be included in the CA's CPS. | |||
| $ CFB | $ CFB | |||
| (N) See: cipher feedback. | (N) See: cipher feedback. | |||
| $ chain | $ chain | |||
| (D) See: trust chain. | (D) See: trust chain. | |||
| $ Challenge Handshake Authentication Protocol (CHAP) | $ Challenge Handshake Authentication Protocol (CHAP) | |||
| (I) A peer entity authentication method for PPP, using a randomly- | (I) A peer entity authentication method for PPP, using a randomly | |||
| generated challenge and requiring a matching response that depends | generated challenge and requiring a matching response that depends | |||
| on a cryptographic hash of some combination of the challenge and a | on a cryptographic hash of some combination of the challenge and a | |||
| secret key. [R1994] (See: challenge-response, PAP.) | secret key. [R1994] (See: challenge-response, PAP.) | |||
| $ challenge-response | $ challenge-response | |||
| (I) An authentication process that verifies an identity by | (I) An authentication process that verifies an identity by | |||
| requiring correct authentication information to be provided in | requiring correct authentication information to be provided in | |||
| response to a challenge. In a computer system, the authentication | response to a challenge. In a computer system, the authentication | |||
| information is usually a value that is required to be computed in | information is usually a value that is required to be computed in | |||
| response to an unpredictable challenge value, but it might be just | response to an unpredictable challenge value, but it might be just | |||
| password. | password. | |||
| $ Challenge-Response Authentication Mechanism (CRAM) | $ Challenge-Response Authentication Mechanism (CRAM) | |||
| (I) IMAP4 usage: A mechanism [R2195], intended for use with IMAP4 | (I) /IMAP4/ A mechanism [R2195], intended for use with IMAP4 | |||
| AUTHENTICATE, by which an IMAP4 client uses a keyed hash [R2104] | AUTHENTICATE, by which an IMAP4 client uses a keyed hash [R2104] | |||
| to authenticate itself to an IMAP4 server. (See: POP3 APOP.) | to authenticate itself to an IMAP4 server. (See: POP3 APOP.) | |||
| Tutorial: The server includes a unique timestamp in its ready | Tutorial: The server includes a unique timestamp in its ready | |||
| response to the client. The client replies with the client's name | response to the client. The client replies with the client's name | |||
| and the hash result of applying MD5 to a string formed from | and the hash result of applying MD5 to a string formed from | |||
| concatenating the timestamp with a shared secret that is known | concatenating the timestamp with a shared secret that is known | |||
| only to the client and the server. | only to the client and the server. | |||
| $ channel | $ channel | |||
| 1. (I) An information transfer path within a system. (See: covert | 1. (I) An information transfer path within a system. (See: covert | |||
| channel.) | channel.) | |||
| 2. (I) A subdivision of a physical medium allowing possibly shared | 2. (O) "A subdivision of the physical medium allowing possibly | |||
| independent uses of the medium. [R3753] | shared independent uses of the medium." (RFC 3753) | |||
| $ channel capacity | $ channel capacity | |||
| (I) The total capacity of a link to carry information; usually | (I) The total capacity of a link to carry information; usually | |||
| expressed in bits per second. [R3753](Compare: bandwidth.) | expressed in bits per second. (RFC 3753) (Compare: bandwidth.) | |||
| Tutorial: Within a given bandwidth, the theoretical maximum | Tutorial: Within a given bandwidth, the theoretical maximum | |||
| channel capacity is given by Shannon~Os Law. The actual channel | channel capacity is given by Shannon's Law. The actual channel | |||
| capacity is determined by the bandwidth, the coding system used, | capacity is determined by the bandwidth, the coding system used, | |||
| and the signal-to-noise ratio. | and the signal-to-noise ratio. | |||
| $ CHAP | $ CHAP | |||
| (I) See: Challenge Handshake Authentication Protocol. | (I) See: Challenge Handshake Authentication Protocol. | |||
| $ checksum | $ checksum | |||
| (I) A value that (a) is computed by a function that is dependent | (I) A value that (a) is computed by a function that is dependent | |||
| on the contents of a data object and (b) is stored or transmitted | on the contents of a data object and (b) is stored or transmitted | |||
| together with the object, for the purpose of detecting changes in | together with the object, for the purpose of detecting changes in | |||
| the data. (See: cyclic redundancy check, data integrity service, | the data. (See: cyclic redundancy check, data integrity service, | |||
| error detection code, hash, keyed hash, protected checksum.) | error detection code, hash, keyed hash, parity bit, protected | |||
| checksum.) | ||||
| Tutorial: To gain confidence that a data object has not been | Tutorial: To gain confidence that a data object has not been | |||
| changed, an entity that later uses the data can compute a checksum | changed, an entity that later uses the data can independently | |||
| value and compare it with the value that was stored or transmitted | recompute the checksum value and compare the result with the value | |||
| with the object. | that was stored or transmitted with the object. | |||
| Computer systems and networks use checksums (and other mechanisms) | Computer systems and networks use checksums (and other mechanisms) | |||
| to detect accidental changes in data. However, active wiretapping | to detect accidental changes in data. However, active wiretapping | |||
| that changes data could also change an accompanying checksum to | that changes data could also change an accompanying checksum to | |||
| match the changed data. Thus, some checksum functions by | match the changed data. Thus, some checksum functions by | |||
| themselves are not good countermeasures for active attacks. To | themselves are not good countermeasures for active attacks. To | |||
| protect against active attacks, the checksum function needs to be | protect against active attacks, the checksum function needs to be | |||
| well-chosen (see: cryptographic hash), and the checksum result | well-chosen (see: cryptographic hash), and the checksum result | |||
| needs to be cryptographically protected (see: digital signature, | needs to be cryptographically protected (see: digital signature, | |||
| keyed hash). | keyed hash). | |||
| skipping to change at page 52, line 54 ¶ | skipping to change at page 54, line 41 ¶ | |||
| 1. (I) /noun/ Data that has been transformed by encryption so that | 1. (I) /noun/ Data that has been transformed by encryption so that | |||
| its semantic information content (i.e., its meaning) is no longer | its semantic information content (i.e., its meaning) is no longer | |||
| intelligible or directly available. (See: ciphertext. Compare: | intelligible or directly available. (See: ciphertext. Compare: | |||
| clear text, plain text.) | clear text, plain text.) | |||
| 2. (O) "Data produced through the use of encipherment. The | 2. (O) "Data produced through the use of encipherment. The | |||
| semantic content of the resulting data is not available." [I7498 | semantic content of the resulting data is not available." [I7498 | |||
| Part 2] | Part 2] | |||
| $ ciphertext | $ ciphertext | |||
| 1a. (I) /adjective/ Referring to cipher text. (See: cipher text.) | 1. (I) /adjective/ Referring to cipher text. (See: cipher text, | |||
| 1b. (D) /noun/ A synonym for cipher text. (See: cleartext, | Compare: cleartext, plaintext.) | |||
| plaintext.) | ||||
| Deprecated Usage: To avoid ambiguity, ISDs SHOULD differentiate | 2. (D) /noun/ A synonym for cipher text. | |||
| between the noun phrase "cipher text" and the adjective | ||||
| "ciphertext". | Deprecated Usage: ISDs should not use this term as a synonym for | |||
| cipher text. ISDs SHOULD distinguish between the adjective | ||||
| "ciphertext" and the noun phrase "cipher text". | ||||
| $ ciphertext auto-key (CTAK) | $ ciphertext auto-key (CTAK) | |||
| (D) "Cryptographic logic that uses previous cipher text to | (D) "Cryptographic logic that uses previous cipher text to | |||
| generate a key stream." [C4009, A1523] (See: KAK.) | generate a key stream." [C4009, A1523] (See: KAK.) | |||
| Deprecated Term: IDS should not use this term; it is neither well- | Deprecated Term: IDS SHOULD NOT use this term; it is neither well- | |||
| known nor precisely defined. Instead, use terms associated with | known nor precisely defined. Instead, use terms associated with | |||
| modes that are defined in standards, such as CBC, CFB, and OFB. | modes that are defined in standards, such as CBC, CFB, and OFB. | |||
| $ ciphertext-only attack | $ ciphertext-only attack | |||
| (I) A cryptanalysis technique in which the analyst tries to | (I) A cryptanalysis technique in which the analyst tries to | |||
| determine the key solely from knowledge of intercepted cipher text | determine the key solely from knowledge of intercepted cipher text | |||
| (although the analyst may also know other clues, such as the | (although the analyst may also know other clues, such as the | |||
| cryptographic algorithm, the language in which the plain text was | cryptographic algorithm, the language in which the plain text was | |||
| written, the subject matter of the plain text, and some probable | written, the subject matter of the plain text, and some probable | |||
| plaintext words.) | plaintext words.) | |||
| skipping to change at page 53, line 42 ¶ | skipping to change at page 55, line 29 ¶ | |||
| $ CKL | $ CKL | |||
| (I) See: compromised key list. | (I) See: compromised key list. | |||
| $ Clark-Wilson model | $ Clark-Wilson model | |||
| (N) A security model [Clark] to maintain data integrity in the | (N) A security model [Clark] to maintain data integrity in the | |||
| commercial world. (Compare: Bell-LaPadula model.) | commercial world. (Compare: Bell-LaPadula model.) | |||
| $ class 2, 3, 4, 5 | $ class 2, 3, 4, 5 | |||
| (O) /U.S. DoD/ Assurance levels for PKIs, and for X.509 public-key | (O) /U.S. DoD/ Assurance levels for PKIs, and for X.509 public-key | |||
| certificates issued by a PKI. [DoD3] (See: (first law under) | certificates issued by a PKI. [DoD3] (See: "first law" under | |||
| Courtney's laws.) | "Courtney's laws".) | |||
| - "Class 2": Intended for applications handling unclassified, | - "Class 2": Intended for applications handling unclassified, | |||
| low-value data in minimally or moderately protected | low-value data in minimally or moderately protected | |||
| environments. | environments. | |||
| - "Class 3": Intended for applications handling unclassified, | - "Class 3": Intended for applications handling unclassified, | |||
| medium-value data in moderately protected environments, or | medium-value data in moderately protected environments, or | |||
| handling unclassified or high-value data in highly protected | handling unclassified or high-value data in highly protected | |||
| environments, and for discretionary access control of | environments, and for discretionary access control of | |||
| classified data in highly protected environments. | classified data in highly protected environments. | |||
| - "Class 4": Intended for applications handling unclassified, | - "Class 4": Intended for applications handling unclassified, | |||
| high-value data in minimally protected environments. | high-value data in minimally protected environments. | |||
| - "Class 5": Intended for applications handling classified data | - "Class 5": Intended for applications handling classified data | |||
| in minimally protected environments, and for authentication of | in minimally protected environments, and for authentication of | |||
| material that would affect the security of classified systems. | material that would affect the security of classified systems. | |||
| The environments are defined as follows: | The environments are defined as follows: | |||
| - "Highly protected environment": Networks that are protected | - "Highly protected environment": Networks that are protected | |||
| either with encryption devices approved by NSA for protection | either with encryption devices approved by NSA for protection | |||
| of classified data or via physical isolation, and that are | of classified data or via physical isolation, and that are | |||
| certified for processing system-high classified data, where | certified for processing system-high classified data, where | |||
| exposure of unencrypted data is limited to U.S. citizens | exposure of unencrypted data is limited to U.S. citizens | |||
| holding appropriate security clearances. | holding appropriate security clearances. | |||
| - "Moderately protected environment": | - "Moderately protected environment": | |||
| -- Physically isolated unclassified, unencrypted networks in | -- Physically isolated unclassified, unencrypted networks in | |||
| which access is restricted based on legitimate need. | which access is restricted based on legitimate need. | |||
| -- Networks protected by NSA-approved, type 1 encryption, | -- Networks protected by NSA-approved, type 1 encryption, | |||
| accessible by U.S.-authorized foreign nationals. | accessible by U.S.-authorized foreign nationals. | |||
| - "Minimally protected environments": Unencrypted networks | - "Minimally protected environments": Unencrypted networks | |||
| connected to either the Internet or NIPRNET, either directly or | connected to either the Internet or NIPRNET, either directly or | |||
| via a firewall. | via a firewall. | |||
| $ Class D computer system | $ Class A1, B3, B2, B1, C2, or C1 computer system | |||
| (O) See: TCSEC. | (O) /TCSEC/ See: Tutorial under "Trusted Computer System | |||
| Evaluation Criteria". | ||||
| $ classification | $ classification | |||
| (I) A grouping of classified information to which a hierarchical, | 1. (I) A grouping of classified information to which a | |||
| restrictive security label is applied to increase protection of | hierarchical, restrictive security label is applied to increase | |||
| the data from unauthorized disclosure. (See: classified, data | protection of the data from unauthorized disclosure. (See: | |||
| confidentiality service. Compare: compartment.) | aggregation, classified, data confidentiality service. Compare: | |||
| compartment.) | ||||
| 2. (I) An authorized process by which information is determined to | ||||
| be classified and assigned to a security level. (See: | ||||
| declassification.) | ||||
| Usage: Usually understood to involve data confidentiality, but | Usage: Usually understood to involve data confidentiality, but | |||
| ISDs SHOULD make this clear when data also is sensitive in other | ISDs SHOULD make this clear when data also is sensitive in other | |||
| ways and SHOULD use other terms for those other sensitivity | ways and SHOULD use other terms for those other sensitivity | |||
| concepts. (See: sensitive information, data integrity.) | concepts. (See: sensitive information, data integrity.) | |||
| $ classification label | $ classification label | |||
| (I) A security label that tells the degree of harm that will | (I) A security label that tells the degree of harm that will | |||
| result from unauthorized disclosure of the labeled data, and may | result from unauthorized disclosure of the labeled data, and may | |||
| also tell what countermeasures are required to be applied to | also tell what countermeasures are required to be applied to | |||
| skipping to change at page 55, line 12 ¶ | skipping to change at page 57, line 5 ¶ | |||
| Usage: Usually understood to involve data confidentiality, but | Usage: Usually understood to involve data confidentiality, but | |||
| ISDs SHOULD make this clear when data also is sensitive in other | ISDs SHOULD make this clear when data also is sensitive in other | |||
| ways and SHOULD use other terms for those other sensitivity | ways and SHOULD use other terms for those other sensitivity | |||
| concepts. (See: sensitive information, data integrity.) | concepts. (See: sensitive information, data integrity.) | |||
| $ classified | $ classified | |||
| 1. (I) Refers to information (stored or conveyed, in any form) | 1. (I) Refers to information (stored or conveyed, in any form) | |||
| that is formally required by a security policy to receive data | that is formally required by a security policy to receive data | |||
| confidentiality service and to be marked with a security label | confidentiality service and to be marked with a security label | |||
| (which in some cases might be implicit) to indicate its protected | (which in some cases might be implicit) to indicate its protected | |||
| status. (See: classification, classification level. Compare: | status. (See: classify, security level. Compare: unclassified.) | |||
| unclassified.) | ||||
| Usage: Usually understood to involve data confidentiality, but | Usage: Usually understood to involve data confidentiality, but | |||
| ISDs SHOULD make this clear when data also is sensitive in other | ISDs SHOULD make this clear when data also is sensitive in other | |||
| ways and SHOULD use other terms for those other sensitivity | ways and SHOULD use other terms for those other sensitivity | |||
| concepts. (See: sensitive information, data integrity.) | concepts. (See: sensitive information, data integrity.) | |||
| Tutorial: The term is mainly used in government, especially in the | Tutorial: The term is mainly used in government, especially in the | |||
| military, but the underlying concept also applies outside | military, but the underlying concept also applies outside | |||
| government. | government. | |||
| 2. (O) /U.S. DoD/ Information that has been determined pursuant to | 2. (O) /U.S. DoD/ Information that has been determined pursuant to | |||
| Executive Order 12958 ("Classified National Security Information", | Executive Order 12958 ("Classified National Security Information", | |||
| 20 April 1995) or any predecessor order to require protection | 20 April 1995) or any predecessor order to require protection | |||
| against unauthorized disclosure and is marked to indicate its | against unauthorized disclosure and is marked to indicate its | |||
| classified status when in documentary form. | classified status when in documentary form. | |||
| $ classify | ||||
| (I) To officially designate an information item or type of | ||||
| information as being classified and assigned to a specific | ||||
| security level. (See: classified, declassify, security level.) | ||||
| $ clean system | $ clean system | |||
| (I) A computer system in which the operating system and | (I) A computer system in which the operating system and | |||
| application system software and files have been freshly installed | application system software and files have been freshly installed | |||
| from trusted software distribution media. (Compare: secure state.) | from trusted software distribution media. (Compare: secure state.) | |||
| $ clear | $ clear | |||
| (D) /verb/ Synonym for "erase". [C4009] | (D) /verb/ Synonym for "erase". [C4009] | |||
| Deprecated Definition: ISDs SHOULD NOT use the term with this | Deprecated Definition: ISDs SHOULD NOT use the term with this | |||
| definition; it could be confused with "clear text" in which | definition; it could be confused with "clear text" in which | |||
| information is directly recoverable. | information is directly recoverable. | |||
| $ clear text | $ clear text | |||
| 1. (I) /noun/ Data in which the semantic information content | 1. (I) /noun/ Data in which the semantic information content | |||
| (i.e., the meaning) is intelligible or is directly available, | (i.e., the meaning) is intelligible or is directly available, | |||
| i.e., not encrypted. (Compare: cipher text, plain text. See: | i.e., not encrypted. (See: cleartext, in the clear. Compare: | |||
| cleartext, in the clear.) | cipher text, plain text.) | |||
| 2. (O) "Intelligible data, the semantic content of which is | 2. (O) "Intelligible data, the semantic content of which is | |||
| available." [I7498 Part 2] | available." [I7498 Part 2] | |||
| 3. (D) Synonym for "plain text". | 3. (D) Synonym for "plain text". | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "plain text", because the plain text that is input to an | for "plain text", because the plain text that is input to an | |||
| encryption process may itself be cipher text that was output from | encryption process may itself be cipher text that was output from | |||
| an encryption. (See: superencryption.) | an encryption. (See: superencryption.) | |||
| $ clearance | $ clearance | |||
| See: security clearance. | See: security clearance. | |||
| $ clearance level | $ clearance level | |||
| (I) The security level of information to which a security | (I) The security level of information to which a security | |||
| clearance authorizes a person to have access. | clearance authorizes a person to have access. | |||
| $ cleartext | $ cleartext | |||
| 1a. (I) /adjective/ Referring to clear text. (Compare: ciphertext, | 1. (I) /adjective/ Referring to clear text. (See: clear text. | |||
| plaintext. See: clear text.) | Compare: ciphertext, plaintext.) | |||
| Usage: To avoid ambiguity, ISDs SHOULD distinguish between the | 2. (D) /noun/ A synonym for clear text. | |||
| adjective "cleartext" and the noun phrase "clear text". | ||||
| Deprecated Usage: ISDs should not use this term as a synonym for | ||||
| clear text. ISDs SHOULD distinguish between the adjective | ||||
| "cleartext" and the noun phrase "clear text". | ||||
| $ CLEF | $ CLEF | |||
| (N) See: commercially licensed evaluation facility. | (N) See: commercially licensed evaluation facility. | |||
| $ client | $ client | |||
| (I) A system entity that requests and uses a service provided by | (I) A system entity that requests and uses a service provided by | |||
| another system entity, called a "server". (See: server.) | another system entity, called a "server". (See: server.) | |||
| Tutorial: Usually, the requesting entity is a computer process, | Tutorial: Usually, it is understood that the client and server are | |||
| and it makes the request on behalf of a human user. In some cases, | automated components of the system, and the client makes the | |||
| the server may itself be a client of some other server. | request on behalf of a human user. In some cases, the server may | |||
| itself be a client of some other server. | ||||
| $ client-server system | $ client-server system | |||
| (I) A distributed system in which one or more entities, called | (I) A distributed system in which one or more entities, called | |||
| clients, request a specific service from one or more other | clients, request a specific service from one or more other | |||
| entities, called servers, that provide the service to the clients. | entities, called servers, that provide the service to the clients. | |||
| Example: The Word Wide Web, in which servers provided information | Example: The Word Wide Web, in which component servers provide | |||
| that is requested by clients called browsers. | information that is requested by component clients called | |||
| "browsers". | ||||
| $ CLIPPER | $ CLIPPER | |||
| (N) An integrated microcircuit (in MYK-7x series manufactured by | (N) An integrated microcircuit (in MYK-7x series manufactured by | |||
| Mykotronx, Inc.) that implements SKIPJACK, has non-deterministic | Mykotronx, Inc.) that implements SKIPJACK, has non-deterministic | |||
| random number generator, and supports key escrow. (See: Escrowed | random number generator, and supports key escrow. (See: Escrowed | |||
| Encryption Standard. Compare: CLIPPER.) | Encryption Standard. Compare: CLIPPER.) | |||
| Tutorial: The chip was mainly intended for protecting | Tutorial: The chip was mainly intended for protecting | |||
| telecommunications over the public switched network. The key | telecommunications over the public switched network. The key | |||
| escrow scheme for the chip involves a SKIPJACK key that is common | escrow scheme for the chip involves a SKIPJACK key that is common | |||
| skipping to change at page 57, line 10 ¶ | skipping to change at page 59, line 13 ¶ | |||
| Department. | Department. | |||
| $ closed security environment | $ closed security environment | |||
| (O) /U.S. DoD/ A system environment that meets both of the | (O) /U.S. DoD/ A system environment that meets both of the | |||
| following conditions: (a) Application developers (including | following conditions: (a) Application developers (including | |||
| maintainers) have sufficient clearances and authorizations to | maintainers) have sufficient clearances and authorizations to | |||
| provide an acceptable presumption that they have not introduced | provide an acceptable presumption that they have not introduced | |||
| malicious logic. (b) Configuration control provides sufficient | malicious logic. (b) Configuration control provides sufficient | |||
| assurance that system applications and the equipment they run on | assurance that system applications and the equipment they run on | |||
| are protected against the introduction of malicious logic prior to | are protected against the introduction of malicious logic prior to | |||
| and during the operation of applications. [NCS04] (See: (first law | and during the operation of applications. [NCS04] (See: "first | |||
| under) Courtney's laws. Compare: open security environment.) | law" under "Courtney's laws". Compare: open security environment.) | |||
| $ CMA | $ CMA | |||
| (D) See: certificate management authority. | (D) See: certificate management authority. | |||
| $ CMCS | $ CMCS | |||
| (O) See: COMSEC Material Control System. | (O) See: COMSEC Material Control System. | |||
| $ CMM | $ CMM | |||
| (N) See: Capability Maturity Model. | (N) See: Capability Maturity Model. | |||
| $ CMS | $ CMS | |||
| (I) See: Cryptographic Message Syntax. | (I) See: Cryptographic Message Syntax. | |||
| $ code | $ code | |||
| 1. (I) A system of symbols used to represent information, which | 1. (I) A system of symbols used to represent information, which | |||
| might originally have some other representation. Examples: ASCII, | might originally have some other representation. Examples: ASCII, | |||
| BER, country code, Morse code. (See: encode, object code, source | BER, country code, Morse code. (See: encode, object code, source | |||
| code.) | code.) | |||
| Deprecated usage: To avoid confusion with definition 1, ISDs | Deprecated Abbreviation: To avoid confusion with definition 1, | |||
| SHOULD NOT use "code" as an abbreviation for "country code", | ISDs SHOULD NOT use "code" as an abbreviation of "country code", | |||
| "cyclic redundancy code", "Data Authentication Code", "error | "cyclic redundancy code", "Data Authentication Code", "error | |||
| detection code", or "Message Authentication Code". To avoid | detection code", or "Message Authentication Code". To avoid | |||
| misunderstanding, use the fully qualified term in these other | misunderstanding, use the fully qualified term in these other | |||
| cases, at least at the point of first usage. | cases, at least at the point of first usage. | |||
| 2. (I) /cryptography / An encryption algorithm based on | 2. (I) /cryptography/ An encryption algorithm based on | |||
| substitution; i.e., a system for providing data confidentiality by | substitution; i.e., a system for providing data confidentiality by | |||
| using arbitrary groups (called "code groups") of letters, numbers, | using arbitrary groups (called "code groups") of letters, numbers, | |||
| or symbols to represent units of plain text of varying length. | or symbols to represent units of plain text of varying length. | |||
| (See: codebook, cryptography.) | (See: codebook, cryptography.) | |||
| Deprecated Usage: To avoid confusion with definition 1, ISDs | Deprecated Usage: To avoid confusion with definition 1, ISDs | |||
| SHOULD NOT use "code" as synonym for (a) "cipher", "hash", or | SHOULD NOT use "code" as synonym for any of the following terms: | |||
| other words that mean "a cryptographic algorithm"; (b) "cipher | (a) "cipher", "hash", or other words that mean "a cryptographic | |||
| text"; or (c) "encrypt", "hash", or other words that refer to | algorithm"; (b) "cipher text"; or (c) "encrypt", "hash", or other | |||
| applying a cryptographic algorithm. | words that refer to applying a cryptographic algorithm. | |||
| 3. (I) An algorithm based on substitution, but used to shorten | 3. (I) An algorithm based on substitution, but used to shorten | |||
| messages rather than to conceal their content. | messages rather than to conceal their content. | |||
| 4. (I) /computer programming/ To write computer software. (See: | 4. (I) /computer programming/ To write computer software. (See: | |||
| object code, source code.) | object code, source code.) | |||
| Deprecated Usage: To avoid confusion with definition 1, ISDs | ||||
| SHOULD NOT use "code" as an abbreviation for "object code" or | Deprecated Abbreviation: To avoid confusion with definition 1, | |||
| ISDs SHOULD NOT use "code" as an abbreviation of "object code" or | ||||
| "source code". To avoid misunderstanding, use the fully qualified | "source code". To avoid misunderstanding, use the fully qualified | |||
| term in these other cases, at least at the point of first usage. | term in these other cases, at least at the point of first usage. | |||
| $ code book | $ code book | |||
| 1. (I) Document containing a systematically arranged list of | 1. (I) Document containing a systematically arranged list of | |||
| plaintext units and their ciphertext equivalents. [C4009] | plaintext units and their ciphertext equivalents. [C4009] | |||
| 2. (I) An encryption algorithm that uses a word substitution | 2. (I) An encryption algorithm that uses a word substitution | |||
| technique. [C4009] (See: code, ECB.) | technique. [C4009] (See: code, ECB.) | |||
| $ code signing | $ code signing | |||
| (I) A security mechanism that uses a digital signature to provide | (I) A security mechanism that uses a digital signature to provide | |||
| data origin authentication for software that is being distributed | data origin authentication for software that is being distributed | |||
| for use. (See: mobile code, trusted distribution.) | for use. (See: mobile code, trusted distribution.) | |||
| $ COI | $ COI | |||
| (I) See: community of interest. | (I) See: community of interest. | |||
| $ cold start | $ cold start | |||
| (N) /cryptographic module/ A procedure for initially keying | (N) /cryptographic module/ A procedure for initially keying | |||
| cryptographic equipment. [C4009] | cryptographic equipment. [C4009] | |||
| $ color change | $ color change | |||
| (I) In a system being operated in periods processing mode, the act | (I) In a system being operated in periods processing mode, the act | |||
| of purging all information from one processing period and then | of purging all information from one processing period and then | |||
| changing over to the next processing period. (See: BLACK, RED.) | changing over to the next processing period. (See: BLACK, RED.) | |||
| $ Commercial COMSEC Endorsement Program (CCEP) | $ Commercial COMSEC Endorsement Program (CCEP) | |||
| (N) "Relationship between NSA and industry in which NSA provides | (O) "Relationship between NSA and industry in which NSA provides | |||
| the COMSEC expertise (i.e., standards, algorithms, evaluations, | the COMSEC expertise (i.e., standards, algorithms, evaluations, | |||
| and guidance) and industry provides design, development, and | and guidance) and industry provides design, development, and | |||
| production capabilities to produce a type 1 or type 2 product." | production capabilities to produce a type 1 or type 2 product." | |||
| [C4009] | [C4009] | |||
| $ commercially licensed evaluation facility (CLEF) | $ commercially licensed evaluation facility (CLEF) | |||
| (N) An organization that has official approval to evaluate the | (N) An organization that has official approval to evaluate the | |||
| security of products and systems in accordance with the Common | security of products and systems in accordance with the Common | |||
| Criteria, ITSEC, or some other standard. | Criteria, ITSEC, or some other standard. | |||
| $ Committee on National Security Systems (CNSS) | ||||
| (O) A U.S. Government, interagency, standing committee of the | ||||
| President's Critical Infrastructure Protection Board. The CNSS is | ||||
| chaired by the Secretary of Defense and provides a forum for the | ||||
| discussion of policy issues, sets national policy, and promulgates | ||||
| direction, operational procedures, and guidance for the security | ||||
| of national security systems. The Secretary of Defense and the | ||||
| Director of Central Intelligence are responsible for developing | ||||
| and overseeing the implementation of Government-wide policies, | ||||
| principles, standards, and guidelines for the security of systems | ||||
| that handle national security information. | ||||
| $ Common Criteria for Information Technology Security | $ Common Criteria for Information Technology Security | |||
| (N) A standard for evaluating information technology (IT) products | (N) A standard for evaluating information technology (IT) products | |||
| and systems. It states requirements for security functions and for | and systems. It states requirements for security functions and for | |||
| assurance measures. [CCIB] (See: CLEF, EAL, packages, protection | assurance measures. [CCIB] (See: CLEF, EAL, packages, protection | |||
| profile, security target, TOE. Compare: CMM.) | profile, security target, TOE. Compare: CMM.) | |||
| Tutorial: Canada, France, Germany, the Netherlands, the United | Tutorial: Canada, France, Germany, the Netherlands, the United | |||
| Kingdom, and the United States (NIST and NSA) began developing | Kingdom, and the United States (NIST and NSA) began developing | |||
| this standard in 1993, based on the European ITSEC, the Canadian | this standard in 1993, based on the European ITSEC, the Canadian | |||
| Trusted Computer Product Evaluation Criteria (CTCPEC), and the | Trusted Computer Product Evaluation Criteria (CTCPEC), and the | |||
| skipping to change at page 59, line 33 ¶ | skipping to change at page 61, line 48 ¶ | |||
| cryptographic algorithms. | cryptographic algorithms. | |||
| Part 1, Introduction and General Model, defines general concepts | Part 1, Introduction and General Model, defines general concepts | |||
| and principles of IT security evaluation; presents a general model | and principles of IT security evaluation; presents a general model | |||
| of evaluation; and defines constructs for expressing IT security | of evaluation; and defines constructs for expressing IT security | |||
| objectives, for selecting and defining IT security requirements, | objectives, for selecting and defining IT security requirements, | |||
| and for writing high-level specifications for products and | and for writing high-level specifications for products and | |||
| systems. | systems. | |||
| Part 2, Security Functional Requirements, contains a catalog of | Part 2, Security Functional Requirements, contains a catalog of | |||
| well-defined and understood security functional requirements that | well-defined and well-understood functional requirement statements | |||
| are intended to be used as a standard way of expressing the | that are intended to be used as a standard way of expressing the | |||
| security requirements for IT products and systems. | security requirements for IT products and systems. | |||
| Part 3, Security Assurance Requirements, contains a catalog of | Part 3, Security Assurance Requirements, contains a catalog of | |||
| assurance components for use as a standard way of expressing the | assurance components for use as a standard way of expressing the | |||
| such requirements for IT products and systems, and defines | such requirements for IT products and systems, and defines | |||
| evaluation criteria for protection profiles and security targets. | evaluation criteria for protection profiles and security targets. | |||
| $ Common IP Security Option (CIPSO) | $ Common IP Security Option (CIPSO) | |||
| (I) See: (secondary definition under) IPSO. | (I) See: secondary definition under "IPSO". | |||
| $ common name | $ common name | |||
| (N) A character string that (a) may be a part of the X.500 DN of a | (N) A character string that (a) may be a part of the X.500 DN of a | |||
| Directory object ("commonName" attribute), (b) is a (possibly | Directory object ("commonName" attribute), (b) is a (possibly | |||
| ambiguous) name by which the object is commonly known in some | ambiguous) name by which the object is commonly known in some | |||
| limited scope (such as an organization), and (c) conforms to the | limited scope (such as an organization), and (c) conforms to the | |||
| naming conventions of the country or culture with which it is | naming conventions of the country or culture with which it is | |||
| associated. [X520] (See: ("subject" and "issuer" under) X.509 | associated. [X520] (See: "subject" and "issuer" under "X.509 | |||
| public-key certificate.) | public-key certificate".) | |||
| Examples: "Dr. Albert Einstein", "The United Nations", and "12-th | Examples: "Dr. Albert Einstein", "The United Nations", and "12-th | |||
| Floor Laser Printer". | Floor Laser Printer". | |||
| $ communications cover | $ communications cover | |||
| (N) "Concealing or altering of characteristic communications | (N) "Concealing or altering of characteristic communications | |||
| patterns to hide information that could be of value to an | patterns to hide information that could be of value to an | |||
| adversary." [C4009] (See: operations security, traffic-flow | adversary." [C4009] (See: operations security, traffic-flow | |||
| confidentiality, TRANSEC.) | confidentiality, TRANSEC.) | |||
| skipping to change at page 60, line 34 ¶ | skipping to change at page 62, line 49 ¶ | |||
| $ community of interest (COI) | $ community of interest (COI) | |||
| 1. (I) A set of entities that operate under a common security | 1. (I) A set of entities that operate under a common security | |||
| policy. (Compare: domain.) | policy. (Compare: domain.) | |||
| 2. (O) /U.S. DoD/ "A collaborative group of users who exchange | 2. (O) /U.S. DoD/ "A collaborative group of users who exchange | |||
| information in support of shared missions, business processes, and | information in support of shared missions, business processes, and | |||
| objectives." | objectives." | |||
| $ community risk | $ community risk | |||
| (O) Probability that a particular vulnerability will be exploited | (N) Probability that a particular vulnerability will be exploited | |||
| within an interacting population and adversely affect some members | within an interacting population and adversely affect some members | |||
| of that population. [C4009] | of that population. [C4009] (See: Morris worm.) | |||
| $ community string | $ community string | |||
| (I) A community name in the form of an octet string that serves as | (I) A community name in the form of an octet string that serves as | |||
| a cleartext password in SNMP version 1. [R1157] | a cleartext password in SNMP version 1. (RFC 1157) | |||
| $ compartment | $ compartment | |||
| (I) A grouping of sensitive information items that require special | 1. (I) A grouping of sensitive information items that require | |||
| access controls beyond those normally provided for the basic | special access controls beyond those normally provided for the | |||
| classification level of the information. (See: category.) | basic classification level of the information. (See: compartmented | |||
| security mode. Compare: category, classification.) | ||||
| Usage: The term is usually understood to include the special | Usage: The term is usually understood to include the special | |||
| handling procedures to be used for the information. | handling procedures to be used for the information. | |||
| 2. (I) Synonym for "category". | ||||
| Deprecated Usage: This Glossary defines "category" with a slightly | ||||
| narrower meaning than "compartment". That is, a security label is | ||||
| assigned to a category because the data owner needs to handle the | ||||
| data as compartment. However, a compartment could receive special | ||||
| protection in a system without being assigned a category label. | ||||
| $ compartmented security mode | ||||
| (N) A mode of system operation wherein all users having access to | ||||
| the system have the necessary security clearance for the single, | ||||
| hierarchical classification level of all data handled by the | ||||
| system, but some users do not have the clearance for a non- | ||||
| hierarchical category of some data handled by the system. (See: | ||||
| category, /system operation/ under "mode", protection level, | ||||
| security clearance.) | ||||
| Usage: Usually abbreviated as "compartmented mode". This term was | ||||
| defined in U.S. Government policy on system accreditation. In this | ||||
| mode a system may hand (a) a single hierarchical classification | ||||
| level and (b) multiple non-hierarchical categories within that | ||||
| level. | ||||
| $ Compartments field | $ Compartments field | |||
| (I) A 16-bit field (the "C field") that specifies compartment | (I) A 16-bit field (the "C field") that specifies compartment | |||
| values in the security option (option type 130) of version 4 IP's | values in the security option (option type 130) of version 4 IP's | |||
| datagram header format. The valid field values are assigned by the | datagram header format. The valid field values are assigned by the | |||
| U.S. Government, as specified in RFC 791. | U.S. Government, as specified in RFC 791. | |||
| Deprecated Definition: ISDs SHOULD NOT use the abbreviation "C | Deprecated Abbreviation: ISDs SHOULD NOT use the abbreviation "C | |||
| field"; the abbreviation is potentially ambiguous. Instead, use | field"; the abbreviation is potentially ambiguous. Instead, use | |||
| "Compartments field". | "Compartments field". | |||
| $ component | $ component | |||
| See: system component. | See: system component. | |||
| $ compression | $ compression | |||
| (I) A process that encodes information in a way that minimizes the | (I) A process that encodes information in a way that minimizes the | |||
| number of resulting code symbols and thus reduces storage space or | number of resulting code symbols and thus reduces storage space or | |||
| transmission time. | transmission time. | |||
| skipping to change at page 61, line 49 ¶ | skipping to change at page 64, line 35 ¶ | |||
| before the encryption operation. | before the encryption operation. | |||
| $ compromise | $ compromise | |||
| See: data compromise, security compromise. | See: data compromise, security compromise. | |||
| $ compromise recovery | $ compromise recovery | |||
| (I) The process of regaining a secure state for a system after | (I) The process of regaining a secure state for a system after | |||
| detecting that the system has experienced a security compromise. | detecting that the system has experienced a security compromise. | |||
| $ compromised key list (CKL) | $ compromised key list (CKL) | |||
| (O) /MISSI/ A list that identifies keys for which unauthorized | (N) /MISSI/ A list that identifies keys for which unauthorized | |||
| disclosure or alteration may have occurred. (See: compromise.) | disclosure or alteration may have occurred. (See: compromise.) | |||
| Tutorial: A CKL is issued by an CA, like a CRL is issued. But a | Tutorial: A CKL is issued by an CA, like a CRL is issued. But a | |||
| CKL lists only KMIDs, not subjects that hold the keys, and not | CKL lists only KMIDs, not subjects that hold the keys, and not | |||
| certificates in which the keys are bound. | certificates in which the keys are bound. | |||
| $ COMPUSEC | $ COMPUSEC | |||
| (I) See: computer security. | (I) See: computer security. | |||
| $ computer system | ||||
| (I) A synonym for "information system", or a component thereof. | ||||
| (Compare: computer platform.) | ||||
| $ computer emergency response team (CERT) | $ computer emergency response team (CERT) | |||
| (I) An organization that studies computer and network INFOSEC in | (I) An organization that studies computer and network INFOSEC in | |||
| order to provide incident response services to victims of attacks, | order to provide incident response services to victims of attacks, | |||
| publish alerts concerning vulnerabilities and threats, and offer | publish alerts concerning vulnerabilities and threats, and offer | |||
| other information to help improve computer and network security. | other information to help improve computer and network security. | |||
| (See: CSIRT, security incident.) | (See: CSIRT, security incident.) | |||
| Examples: CERT Coordination Center at Carnegie-Mellon University | Examples: CERT Coordination Center at Carnegie-Mellon University | |||
| (sometimes called "the" CERT); CIAC. | (sometimes called "the" CERT); CIAC. | |||
| $ Computer Incident Advisory Capability (CIAC) | $ Computer Incident Advisory Capability (CIAC) | |||
| (O) The centralized CSIRT of the U.S Department of Energy; a | (O) The centralized CSIRT of the U.S Department of Energy; a | |||
| member of FIRST. | member of FIRST. | |||
| $ computer network | $ computer network | |||
| (I) A collection of host computers together with the subnetwork or | (I) A collection of host computers together with the subnetwork or | |||
| internetwork through which they can exchange data. | internetwork through which they can exchange data. | |||
| Usage: This definition is intended to cover systems of all sizes | Usage: This definition is intended to cover systems of all sizes | |||
| and types, ranging from the complex Internet to a simple system | and types, ranging from the complex Internet to a simple system | |||
| composed of a personal computer dialing in as a remote terminal of | composed of a personal computer dialing in as a remote terminal of | |||
| another computer. | another computer. | |||
| $ computer platform | $ computer platform | |||
| (I) A combination of computer hardware and an operating system | (I) A combination of computer hardware and an operating system | |||
| (which may consist of software, firmware, or both) for that | (which may consist of software, firmware, or both) for that | |||
| hardware. | hardware. (Compare: computer system.) | |||
| $ computer security (COMPUSEC) | $ computer security (COMPUSEC) | |||
| (I) Measures to implement and assure security services in a | (I) Measures to implement and assure security services in a | |||
| computer system, particularly those that assure access control | computer system, particularly those that assure access control | |||
| service. | service. | |||
| Usage: Usually refers to internal controls (functions, features, | Usage: Usually refers to internal controls (functions, features, | |||
| and technical characteristics) that are implemented in software | and technical characteristics) that are implemented in software | |||
| (especially in operating systems); sometimes refers to internal | (especially in operating systems); sometimes refers to internal | |||
| controls implemented in hardware; rarely used to refer to external | controls implemented in hardware; rarely used to refer to external | |||
| skipping to change at page 63, line 53 ¶ | skipping to change at page 66, line 44 ¶ | |||
| Security Foundation chartered by the U.S. Government) have not | Security Foundation chartered by the U.S. Government) have not | |||
| been implemented at all, and others (e.g., codifying Generally | been implemented at all, and others (e.g., codifying Generally | |||
| Accepted System Security Principles similar to accounting | Accepted System Security Principles similar to accounting | |||
| principles) have been implemented but not widely adopted [SP14, | principles) have been implemented but not widely adopted [SP14, | |||
| SP27]. | SP27]. | |||
| $ COMSEC | $ COMSEC | |||
| (I) See: communication security. | (I) See: communication security. | |||
| $ COMSEC account | $ COMSEC account | |||
| (N) /U.S. Government/ "Administrative entity, identified by an | (O) /U.S. Government/ "Administrative entity, identified by an | |||
| account number, used to maintain accountability, custody, and | account number, used to maintain accountability, custody, and | |||
| control of COMSEC material." [C4009] (See: COMSEC custodian.) | control of COMSEC material." [C4009] (See: COMSEC custodian.) | |||
| $ COMSEC accounting | $ COMSEC accounting | |||
| (I) /U.S. Government/ The process of creating, collecting, and | (I) /U.S. Government/ The process of creating, collecting, and | |||
| maintaining data records that describe the status and custody of | maintaining data records that describe the status and custody of | |||
| designated items of COMSEC material. (See: accounting legend | designated items of COMSEC material. (See: accounting legend | |||
| code.) | code.) | |||
| Tutorial: Almost any secure information system needs to record a | Tutorial: Almost any secure information system needs to record a | |||
| security audit trail, but a system that manages COMSEC material | security audit trail, but a system that manages COMSEC material | |||
| needs to record additional data about the status and custody of | needs to record additional data about the status and custody of | |||
| COMSEC items. | COMSEC items. | |||
| - COMSEC tracking: The process of automatically collecting, | - COMSEC tracking: The process of automatically collecting, | |||
| recording, and managing information that describes the status | recording, and managing information that describes the status | |||
| of designated items of COMSEC material at all times during each | of designated items of COMSEC material at all times during each | |||
| product~Os lifecycle. | product's lifecycle. | |||
| - COMSEC controlling: The process of supplementing tracking data | - COMSEC controlling: The process of supplementing tracking data | |||
| with custody data, which consists of explicit acknowledgements | with custody data, which consists of explicit acknowledgements | |||
| of system entities that they (a) have received specific COMSEC | of system entities that they (a) have received specific COMSEC | |||
| items and (b) are responsible for preventing exposure of those | items and (b) are responsible for preventing exposure of those | |||
| items. | items. | |||
| For example, a key management system that serves a large customer | For example, a key management system that serves a large customer | |||
| base needs to record tracking data for the same reasons that a | base needs to record tracking data for the same reasons that a | |||
| national parcel delivery system does, i.e., to answer the question | national parcel delivery system does, i.e., to answer the question | |||
| "Where is that thing now?". If keys are encrypted immediately upon | "Where is that thing now?". If keys are encrypted immediately upon | |||
| generation and handled only in BLACK form between the point of | generation and handled only in BLACK form between the point of | |||
| skipping to change at page 64, line 48 ¶ | skipping to change at page 67, line 38 ¶ | |||
| controlling is retained indefinitely to ensure accountability and | controlling is retained indefinitely to ensure accountability and | |||
| support compromise recovery. | support compromise recovery. | |||
| $ COMSEC boundary | $ COMSEC boundary | |||
| (N) "Definable perimeter encompassing all hardware, firmware, and | (N) "Definable perimeter encompassing all hardware, firmware, and | |||
| software components performing critical COMSEC functions, such as | software components performing critical COMSEC functions, such as | |||
| key generation and key handling and storage." [C4009] [Compare: | key generation and key handling and storage." [C4009] [Compare: | |||
| cryptographic boundary.] | cryptographic boundary.] | |||
| $ COMSEC custodian | $ COMSEC custodian | |||
| (N) /U.S. Government/ "Individual designated by proper authority | (O) /U.S. Government/ "Individual designated by proper authority | |||
| to be responsible for the receipt, transfer, accounting, | to be responsible for the receipt, transfer, accounting, | |||
| safeguarding, and destruction of COMSEC material assigned to a | safeguarding, and destruction of COMSEC material assigned to a | |||
| COMSEC account." [C4009] | COMSEC account." [C4009] | |||
| $ COMSEC material | $ COMSEC material | |||
| (N) /U.S. Government/ "Item designed to secure or authenticate | (N) /U.S. Government/ "Item designed to secure or authenticate | |||
| communications. [It] includes but is not limited to key, | communications. [It] includes but is not limited to key, | |||
| equipment, devices, documents, firmware, or software that embodies | equipment, devices, documents, firmware, or software that embodies | |||
| or describes cryptographic logic and other items that perform | or describes cryptographic logic and other items that perform | |||
| COMSEC functions." [C4009] (Compare: keying material.) | COMSEC functions." [C4009] (Compare: keying material.) | |||
| skipping to change at page 65, line 20 ¶ | skipping to change at page 68, line 12 ¶ | |||
| which COMSEC material marked 'CRYPTO' is distributed, controlled, | which COMSEC material marked 'CRYPTO' is distributed, controlled, | |||
| and safeguarded." [C4009] (See: COMSEC account, COMSEC custodian.) | and safeguarded." [C4009] (See: COMSEC account, COMSEC custodian.) | |||
| $ confidentiality | $ confidentiality | |||
| See: data confidentiality. | See: data confidentiality. | |||
| $ configuration control | $ configuration control | |||
| (I) The process of regulating changes to hardware, firmware, | (I) The process of regulating changes to hardware, firmware, | |||
| software, and documentation throughout the development and | software, and documentation throughout the development and | |||
| operational life of a system. (See: administrative security, | operational life of a system. (See: administrative security, | |||
| trusted distribution.) | harden, trusted distribution.) | |||
| Tutorial: Configuration control helps protect against unauthorized | Tutorial: Configuration control helps protect against unauthorized | |||
| or malicious alteration of a system and thus provides assurance of | or malicious alteration of a system and thus provides assurance of | |||
| system integrity. (See: malicious logic.) | system integrity. (See: malicious logic.) | |||
| $ confinement property | $ confinement property | |||
| (N) /formal model/ Property of a system whereby a subject has | (N) /formal model/ Property of a system whereby a subject has | |||
| write access to an object only if the classification of the object | write access to an object only if the classification of the object | |||
| dominates the clearance of the subject. (See: *-property, Bell- | dominates the clearance of the subject. (See: *-property, Bell- | |||
| LaPadula model.) | LaPadula model.) | |||
| $ connectionless data integrity service | $ connectionless integrity service | |||
| (I) A security service that provides data integrity service for an | (I) Synonym for "datagram integrity service". | |||
| individual IP datagram, by detecting modification of the datagram, | ||||
| without regard to the ordering of the datagram in a stream of | ||||
| datagrams. | ||||
| Tutorial: In contrast, a connection-oriented data integrity | ||||
| service usually would be able to detect lost or reordered | ||||
| datagrams within a stream of datagrams. | ||||
| $ constraint | $ constraint | |||
| (I) /access control/ A limitation on the function of an identity, | (I) /access control/ A limitation on the function of an identity, | |||
| role, or privilege. (See: rule-based access control.) | role, or privilege. (See: rule-based access control.) | |||
| Tutorial: In effect, a constraint is a form of security policy and | Tutorial: In effect, a constraint is a form of security policy and | |||
| may be either static or dynamic: | may be either static or dynamic: | |||
| - "Static constraint": A constraint that must be satisfied at the | - "Static constraint": A constraint that must be satisfied at the | |||
| time the policy is defined, and then continues to be satisfied | time the policy is defined, and then continues to be satisfied | |||
| until the constraint is removed. | until the constraint is removed. | |||
| - "Dynamic constraint": A constraint that may be defined to apply | - "Dynamic constraint": A constraint that may be defined to apply | |||
| at various times that the identity, role, or other object of | at various times that the identity, role, or other object of | |||
| the constraint is active in the system. | the constraint is active in the system. | |||
| $ content filter | $ content filter | |||
| (I) /World Wide Web/ Application software used to prevent access | (I) /World Wide Web/ Application software used to prevent access | |||
| to certain Web servers, such as by parents who do not want their | to certain Web servers, such as by parents who do not want their | |||
| children to access pornography. (See: filter, guard.) | children to access pornography. (See: filter, guard.) | |||
| Tutorial: The filter is usually browser-based, but could be part | Tutorial: The filter is usually browser-based, but could be part | |||
| of an intermediate cache server. The two basic content filtering | of an intermediate cache server. The two basic content filtering | |||
| techniques are (a) to block a specified list of URLs and (b) to | techniques are (a) to block a specified list of URLs and (b) to | |||
| block material that contains specified words and phrases. | block material that contains specified words and phrases. | |||
| $ contingency plan | $ contingency plan | |||
| (I) A plan for emergency response, backup operations, and post- | (I) A plan for emergency response, backup operations, and post- | |||
| disaster recovery in a system as part of a security program to | disaster recovery in a system as part of a security program to | |||
| ensure availability of critical system resources and facilitate | ensure availability of critical system resources and facilitate | |||
| continuity of operations in a crisis. [NCS04] (See: availability.) | continuity of operations in a crisis. [NCS04] (See: availability.) | |||
| $ controlled access protection | $ controlled access protection | |||
| (N) The C2 level of criteria described in the TCSEC. | (O) /TCSEC/ The level of evaluation criteria for a C2 computer | |||
| system. | ||||
| Tutorial: The major features of the C2 level are individual | Tutorial: The major features of the C2 level are individual | |||
| accountability, audit, access control, and object reuse. | accountability, audit, access control, and object reuse. | |||
| $ controlled cryptographic item (CCI) | $ controlled cryptographic item (CCI) | |||
| (O) /U.S. Government/ "Secure telecommunications or information | (O) /U.S. Government/ "Secure telecommunications or information | |||
| handling equipment, or associated cryptographic component, that is | handling equipment, or associated cryptographic component, that is | |||
| unclassified but governed by a special set of control | unclassified but governed by a special set of control | |||
| requirements." [C4009] (Compare: EUCI.) | requirements." [C4009] (Compare: EUCI.) | |||
| skipping to change at page 66, line 46 ¶ | skipping to change at page 69, line 31 ¶ | |||
| CCI equipment uses a classified cryptographic logic, but the | CCI equipment uses a classified cryptographic logic, but the | |||
| hardware or firmware embodiment of that logic is unclassified. | hardware or firmware embodiment of that logic is unclassified. | |||
| Drawings, software implementations, and other descriptions of that | Drawings, software implementations, and other descriptions of that | |||
| logic remain classified. [N4001] | logic remain classified. [N4001] | |||
| $ controlled interface | $ controlled interface | |||
| (I) A mechanism that facilitates the adjudication of the different | (I) A mechanism that facilitates the adjudication of the different | |||
| security policies of interconnected systems. (See: domain, guard.) | security policies of interconnected systems. (See: domain, guard.) | |||
| $ controlled security mode | $ controlled security mode | |||
| (D) /U.S. DoD/ A mode of operation of an information system, | (D) A mode of system operation wherein (a) two or more security | |||
| wherein at least some users with access to the system have neither | levels of information are allowed to be handled concurrently | |||
| a security clearance nor need to know for all classified material | within the same system when some users having access to the system | |||
| contained in the system. However, separation and control of users | have neither a security clearance nor need-to-know for some of the | |||
| and classified material on the basis, respectively, of clearance | data handled by the system, but (b) separation of the users and | |||
| and classification level are not essentially under operating | the classified material on the basis, respectively, of clearance | |||
| system control like they are in multilevel security mode. [DoD2] | and classification level are not dependent only on operating | |||
| system control (like they are in multilevel security mode). (See: | ||||
| /system operation/ under "mode", protection level.) | ||||
| Deprecated Term: ISDs SHOULD NOT use this term. It was defined in | Deprecated Term: ISDs SHOULD NOT use this term. It was defined in | |||
| a version of U.S. DoD policy on system accreditation but was | a Government policy regarding system accreditation but was | |||
| subsumed by "partitioned security mode" in a later version. | subsumed by "partitioned security mode" in a later policy. | |||
| Tutorial: Controlled mode was intended to encourage ingenuity in | Tutorial: Controlled mode was intended to encourage ingenuity in | |||
| meeting the security requirements of Defense policy in ways less | meeting data confidentiality requirements in ways less restrictive | |||
| restrictive than "dedicated security mode" and "system high | than "dedicated security mode" and "system-high security mode", | |||
| security mode", but at a level of risk lower than that generally | but at a level of risk lower than that generally associated with | |||
| associated with the true "multilevel security mode". This was to | the true "multilevel security mode". This was intended to be | |||
| be accomplished by implementation of explicit augmenting measures | accomplished by implementation of explicit augmenting measures to | |||
| to reduce or remove a substantial measure of system software | reduce or remove a substantial measure of system software | |||
| vulnerability together with specific limitation of the security | vulnerability together with specific limitation of the security | |||
| clearance levels of users permitted concurrent access to the | clearance levels of users having concurrent access to the system. | |||
| system. | ||||
| $ controlling authority | $ controlling authority | |||
| (O) /U.S. Government/ "Official responsible for directing the | (O) /U.S. Government/ "Official responsible for directing the | |||
| operation of a cryptonet and for managing the operational use and | operation of a cryptonet and for managing the operational use and | |||
| control of keying material assigned to the cryptonet." [C4009, | control of keying material assigned to the cryptonet." [C4009, | |||
| N4006] | N4006] | |||
| $ cookie | $ cookie | |||
| 1. (I) /HTTP/ Data exchanged between an HTTP server and a browser | 1. (I) /HTTP/ Data exchanged between an HTTP server and a browser | |||
| (a client of the server) to store state information on the client | (a client of the server) to store state information on the client | |||
| skipping to change at page 67, line 42 ¶ | skipping to change at page 70, line 28 ¶ | |||
| may include a description of the range of URLs for which the state | may include a description of the range of URLs for which the state | |||
| is valid. Future requests made by the client in that range will | is valid. Future requests made by the client in that range will | |||
| also send the current value of the cookie to the server. Cookies | also send the current value of the cookie to the server. Cookies | |||
| can be used to generate profiles of web usage habits, and thus may | can be used to generate profiles of web usage habits, and thus may | |||
| infringe on personal privacy. | infringe on personal privacy. | |||
| 2. (I) /IPsec/ Data objects exchanged by ISAKMP to prevent certain | 2. (I) /IPsec/ Data objects exchanged by ISAKMP to prevent certain | |||
| denial-of-service attacks during the establishment of a security | denial-of-service attacks during the establishment of a security | |||
| association. | association. | |||
| 3. (D) /access control/ Synonym for "capability" or "ticket. | 3. (D) /access control/ Synonym for "capability token" or "ticket. | |||
| Deprecated Definition: ISDs SHOULD NOT use this term with this | Deprecated Definition: ISDs SHOULD NOT use this term with this | |||
| definition; that would duplicate the meaning of better-established | definition; that would duplicate the meaning of better-established | |||
| terms and mix concepts in a potentially misleading way. | terms and mix concepts in a potentially misleading way. | |||
| $ Coordinated Universal Time (UTC) | $ Coordinated Universal Time (UTC) | |||
| (N) UTC is derived from International Atomic Time (TAI) by adding | (N) UTC is derived from International Atomic Time (TAI) by adding | |||
| a number of leap seconds. The International Bureau of Weights and | a number of leap seconds. The International Bureau of Weights and | |||
| Measures computes TAI once each month by averaging data from many | Measures computes TAI once each month by averaging data from many | |||
| laboratories. (See: GeneralizedTime, UTCTime.) | laboratories. (See: GeneralizedTime, UTCTime.) | |||
| $ copy | $ copy | |||
| See: card copy. | See: card copy. | |||
| $ correction | ||||
| (I) See: secondary definition under "security". | ||||
| $ correctness | $ correctness | |||
| (I) "The property of a system that is guaranteed as the result of | (I) "The property of a system that is guaranteed as the result of | |||
| formal verification activities." [Huff] (See: correctness proof, | formal verification activities." [Huff] (See: correctness proof, | |||
| verification.) | verification.) | |||
| $ correctness integrity | $ correctness integrity | |||
| (I) Accuracy and consistency of the information that data values | (I) The property that the information represented by data is | |||
| represent, rather than of the data itself. Closely related to | accurate and consistent. (Compare: data integrity, source | |||
| issues of accountability and error handling. (See: data integrity, | integrity.) | |||
| source integrity.) | Tutorial: IDS SHOULD NOT use this term without providing a | |||
| definition; the term is neither well-known nor precisely defined. | ||||
| Data integrity refers to the constancy of data values, and source | ||||
| integrity refers to confidence in data values. However, | ||||
| correctness integrity refers to confidence in the underlying | ||||
| information that data values represent, and this property is | ||||
| closely related to issues of accountability and error handling. | ||||
| $ correctness proof | $ correctness proof | |||
| (I) A mathematical proof of consistency between a specification | (I) A mathematical proof of consistency between a specification | |||
| for system security and the implementation of that specification. | for system security and the implementation of that specification. | |||
| (See: correctness, formal specification.) | (See: correctness, formal specification.) | |||
| $ corruption | $ corruption | |||
| A type of threat action that undesirably alters system operation | (I) A type of threat action that undesirably alters system | |||
| by adversely modifying system functions or data. (See: | operation by adversely modifying system functions or data. (See: | |||
| disruption.) | disruption.) | |||
| Usage: This type includes the following subtypes: | Usage: This type includes the following subtypes: | |||
| - "Tampering": In context of corruption, deliberately altering a | - "Tampering": In context of corruption, deliberately altering a | |||
| system's logic, data, or control information to interrupt or | system's logic, data, or control information to interrupt or | |||
| prevent correct operation of system functions. (See: (main | prevent correct operation of system functions. (See: misuse, | |||
| entry for) tampering.) | main entry for "tampering".) | |||
| - "Malicious logic": In context of corruption, any hardware, | - "Malicious logic": In context of corruption, any hardware, | |||
| firmware, or software (e.g., a computer virus) intentionally | firmware, or software (e.g., a computer virus) intentionally | |||
| introduced into a system to modify system functions or data. | introduced into a system to modify system functions or data. | |||
| (See: (main entry for) malicious logic.) | (See: incapacitation, main entry for "malicious logic", | |||
| - "Human error": In context of corruption, human action or | masquerade, misuse.) | |||
| - "Human error": In context of corruption, human action or | ||||
| inaction that unintentionally results in the alteration of | inaction that unintentionally results in the alteration of | |||
| system functions or data. | system functions or data. | |||
| - "Hardware or software error": In context of corruption, error | - "Hardware or software error": In context of corruption, error | |||
| that results in the alteration of system functions or data. | that results in the alteration of system functions or data. | |||
| - "Natural disaster": In context of corruption, any "act of God" | - "Natural disaster": In context of corruption, any "act of God" | |||
| (e.g., power surge caused by lightning) that alters system | (e.g., power surge caused by lightning) that alters system | |||
| functions or data. [FP031 section 2] | functions or data. [FP031 section 2] | |||
| $ counter-countermeasure | $ counter-countermeasure | |||
| (I) An action, device, procedure, or technique used by an attacker | (I) An action, device, procedure, or technique used by an attacker | |||
| to offset a defensive countermeasure. | to offset a defensive countermeasure. | |||
| Tutorial: For every countermeasure devised to protect computers | Tutorial: For every countermeasure devised to protect computers | |||
| and networks, some cracker probably will be able to devise a | and networks, some cracker probably will be able to devise a | |||
| counter-countermeasure. Thus, systems must use "defense in depth". | counter-countermeasure. Thus, systems must use "defense in depth". | |||
| skipping to change at page 69, line 19 ¶ | skipping to change at page 72, line 16 ¶ | |||
| $ country code | $ country code | |||
| (I) An identifier that is defined for a nation by ISO. [I3166] | (I) An identifier that is defined for a nation by ISO. [I3166] | |||
| Tutorial: For each nation, ISO Standard 3166 defines a unique two- | Tutorial: For each nation, ISO Standard 3166 defines a unique two- | |||
| character alphabetic code, a unique three-character alphabetic | character alphabetic code, a unique three-character alphabetic | |||
| code, and a three-digit code. Among many uses of these codes, the | code, and a three-digit code. Among many uses of these codes, the | |||
| two-character codes are used as top-level domain names. | two-character codes are used as top-level domain names. | |||
| $ Courtney's laws | $ Courtney's laws | |||
| Tutorial: The following principles for managing system security | (N) Principles for managing system security that were stated by | |||
| were stated by Robert H. Courtney, Jr.: [Murr] | Robert H. Courtney, Jr. | |||
| - Courtney's first law: You cannot say anything interesting about | ||||
| the security of a system except in the context of a particular | Tutorial: Bill Murray codified Courtney's laws as follows: [Murr] | |||
| application and environment. | - Courtney's first law: You cannot say anything interesting | |||
| - Courtney's second law: Never spend more money eliminating a | (i.e., significant) about the security of a system except in | |||
| the context of a particular application and environment. | ||||
| - Courtney's second law: Never spend more money eliminating a | ||||
| security exposure than tolerating it will cost you. (See: | security exposure than tolerating it will cost you. (See: | |||
| acceptable risk, risk analysis.) | acceptable risk, risk analysis.) | |||
| -- First corollary: Perfect security has infinite cost. | -- First corollary: Perfect security has infinite cost. | |||
| -- Second corollary: There is no such thing as zero risk. | -- Second corollary: There is no such thing as zero risk. | |||
| - Courtney's third law: There are no technical solutions to | - Courtney's third law: There are no technical solutions to | |||
| management problems, but there are management solutions to | management problems, but there are management solutions to | |||
| technical problems. | technical problems. | |||
| $ covert action | $ covert action | |||
| (I) An operation that is planned and executed in a way that | (I) An operation that is planned and executed in a way that | |||
| conceals the identity of the operator. | conceals the identity of the operator. | |||
| $ covert channel | $ covert channel | |||
| 1. (I) An unintended or unauthorized intra-system channel that | 1. (I) An unintended or unauthorized intra-system channel that | |||
| enables two cooperating entities to transfer information in a way | enables two cooperating entities to transfer information in a way | |||
| that violates the system's security policy but does not exceed the | that violates the system's security policy but does not exceed the | |||
| entities' access authorizations. (See: covert storage channel, | entities' access authorizations. (See: covert storage channel, | |||
| covert timing channel, out of band.) | covert timing channel, out-of-band, tunnel.) | |||
| 2. (O) "A communications channel that allows two cooperating | 2. (O) "A communications channel that allows two cooperating | |||
| processes to transfer information in a manner that violates the | processes to transfer information in a manner that violates the | |||
| system's security policy." [NCS04] | system's security policy." [NCS04] | |||
| Tutorial: The cooperating entities can be either two insiders or | Tutorial: The cooperating entities can be either two insiders or | |||
| an insider and an outsider. Of course, an outsider has no access | an insider and an outsider. Of course, an outsider has no access | |||
| authorization at all. A covert channel is a system feature that | authorization at all. A covert channel is a system feature that | |||
| the system architects neither designed nor intended for | the system architects neither designed nor intended for | |||
| information transfer. | information transfer. | |||
| skipping to change at page 70, line 18 ¶ | skipping to change at page 73, line 17 ¶ | |||
| $ covert timing channel | $ covert timing channel | |||
| (I) A system feature that enable one system entity to signal | (I) A system feature that enable one system entity to signal | |||
| information to another by modulating its own use of a system | information to another by modulating its own use of a system | |||
| resource in such a way as to affect system response time observed | resource in such a way as to affect system response time observed | |||
| by the second entity. (See: covert channel.) | by the second entity. (See: covert channel.) | |||
| $ CPS | $ CPS | |||
| (I) See: certification practice statement. | (I) See: certification practice statement. | |||
| $ cracker | $ cracker | |||
| (I) Someone who tries to break the security of, and gain access | (I) Someone who tries to break the security of, and gain | |||
| to, someone else's system without being invited. (Compare: hacker. | unauthorized access to, someone else's system, often with | |||
| See: adversary, intruder, packet monkey, script kiddy.) | malicious intent. (See: adversary, intruder, packet monkey, script | |||
| kiddy. Compare: hacker.) | ||||
| $ CRAM | $ CRAM | |||
| (I) See: Challenge-Response Authentication Mechanism. | (I) See: Challenge-Response Authentication Mechanism. | |||
| $ CRC | $ CRC | |||
| (I) See: cyclic redundancy check. | (I) See: cyclic redundancy check. | |||
| $ credential | $ credential | |||
| 1. (I) /authentication/ "Identity credential": A data object that | 1. (I) /authentication/ "identifier credential": A data object | |||
| is a portable representation of the association between an | that is a portable representation of the association between a | |||
| identifier and a unit of authentication information, and that can | identifier and a unit of authentication information, and that can | |||
| be transferred or presented for use in proving a claim of that | be presented for use in verifying an identity claimed by an entity | |||
| identity. Example: X.509 public-key certificate. (See: anonymous | that attempts to access a system. Example: X.509 public-key | |||
| credential.) | certificate. (See: anonymous credential.) | |||
| 2. (I) /access control/ "Authorization credential": A data object | 2. (I) /access control/ "authorization credential": A data object | |||
| that is a portable representation of the association between an | that is a portable representation of the association between an | |||
| identifier and one or more access, and that can be transferred or | identifier and one or more access authorizations, and that can be | |||
| presented for use when attempting to exercise such access. | presented for use in verifying those authorizations for an entity | |||
| Example: X.509 attribute certificate. (See: capability, ticket.) | that attempts such access. Example: X.509 attribute certificate. | |||
| (See: capability token, ticket.) | ||||
| 3. (D) /OSIRM/ "Data that is transferred to establish the claimed | 3. (D) /OSIRM/ "Data that is transferred to establish the claimed | |||
| identity of an entity." [I7498 Part 2] | identity of an entity." [I7498 Part 2] | |||
| Deprecated Definition: ISDs should not use the term with this | Deprecated Definition: ISDs SHOULD NOT use the term with this | |||
| definition. As explained in the tutorial below, an authentication | definition. As explained in the tutorial below, an authentication | |||
| process can involve the transfer of multiple data objects, and not | process can involve the transfer of multiple data objects, and not | |||
| all of those are credentials. | all of those are credentials. | |||
| 4. (D) /U.S. Government/ "An object that is verified when | 4. (D) /U.S. Government/ "An object that is verified when | |||
| presented to the verifier in an authentication transaction." | presented to the verifier in an authentication transaction." | |||
| [M0404] | [M0404] | |||
| Deprecated Definition: ISDs should not use the term with this | Deprecated Definition: ISDs SHOULD NOT use the term with this | |||
| definition; it mixes concepts in a potentially misleading way. For | definition; it mixes concepts in a potentially misleading way. For | |||
| example, in an authentication process, it is the identity that is | example, in an authentication process, it is the identity that is | |||
| "verified", not the credential; the credential is "validated". | "verified", not the credential; the credential is "validated". | |||
| (See: validate vs. verify.) | (See: validate vs. verify.) | |||
| Tutorial: In general English, "credentials" are evidence or | Tutorial: In general English, "credentials" are evidence or | |||
| testimonials that (a) support a claim of identity or authorization | testimonials that (a) support a claim of identity or authorization | |||
| and (b) usually are intended to be used more than once (i.e., a | and (b) usually are intended to be used more than once (i.e., a | |||
| credential's life is long compared to the time needed for one | credential's life is long compared to the time needed for one | |||
| use). Some examples are a policeman's badge, an automobile | use). Some examples are a policeman's badge, an automobile | |||
| driver's license, and a national passport. An authentication or | driver's license, and a national passport. An authentication or | |||
| access control process that uses a badge, license, or passport is | access control process that uses a badge, license, or passport is | |||
| outwardly simple: the holder just shows the thing. | outwardly simple: the holder just shows the thing. | |||
| The problem with adopting this term in Internet security is that | The problem with adopting this term in Internet security is that | |||
| an automation authentication or access control process requires | an automated process for authentication or access control usually | |||
| multiple steps using multiple data objects, and it might not be | requires multiple steps using multiple data objects, and it might | |||
| immediately obvious which of those objects should get the name | not be immediately obvious which of those objects should get the | |||
| "credential". | name "credential". | |||
| For example, if the verification step in a user authentication | For example, if the verification step in a user authentication | |||
| process employs public-key technology, then the process involves | process employs public-key technology, then the process involves | |||
| at least three data items: (a) the user's private key, (b) a | at least three data items: (a) the user's private key, (b) a | |||
| signed value -- signed with that private key and passed to the | signed value -- signed with that private key and passed to the | |||
| system, perhaps in response to a challenge from the system -- and | system, perhaps in response to a challenge from the system -- and | |||
| (c) the user's public-key certificate, which is validated by the | (c) the user's public-key certificate, which is validated by the | |||
| system and provides the public key needed to verify the signature. | system and provides the public key needed to verify the signature. | |||
| - Private key: The private key is *not* a credential, because it | - Private key: The private key is *not* a credential, because it | |||
| is never transferred or presented. Instead, the private key is | is never transferred or presented. Instead, the private key is | |||
| "authentication information", which is associated with the | "authentication information", which is associated with the | |||
| user's identifier for a specified period of time and can be | user's identifier for a specified period of time and can be | |||
| used in multiple authentications during that time. | used in multiple authentications during that time. | |||
| - Signed value: The signed value is *not* a credential; the | - Signed value: The signed value is *not* a credential; the | |||
| signed value is only ephemeral, not long lasting. The OSIRM | signed value is only ephemeral, not long lasting. The OSIRM | |||
| definition could be interpreted to call the signed value a | definition could be interpreted to call the signed value a | |||
| credential, but that would conflict with general English. | credential, but that would conflict with general English. | |||
| - Certificate. The user's certificate *is* a credential. It can | - Certificate: The user's certificate *is* a credential. It can | |||
| be "transferred" or "presented" to any person or process that | be "transferred" or "presented" to any person or process that | |||
| needs it at any time. A public-key certificate may be used as | needs it at any time. A public-key certificate may be used as | |||
| an "identity credential", and an attribute certificate may be | an "identity credential", and an attribute certificate may be | |||
| used as an "authorization credential". | used as an "authorization credential". | |||
| $ critical | $ critical | |||
| 1. (I) /system resource/ A condition of a system resource such | 1. (I) /system resource/ A condition of a system resource such | |||
| that denial of access to, or lack of availability of, that | that denial of access to, or lack of availability of, that | |||
| resource would jeopardize a system user's ability to perform a | resource would jeopardize a system user's ability to perform a | |||
| primary function or would result in other serious consequences, | primary function or would result in other serious consequences, | |||
| skipping to change at page 74, line 5 ¶ | skipping to change at page 77, line 5 ¶ | |||
| ciphertext; and these generalize to the other kinds of | ciphertext; and these generalize to the other kinds of | |||
| cryptography. | cryptography. | |||
| $ crypto, CRYPTO | $ crypto, CRYPTO | |||
| 1. (N) A prefix ("crypto-") that means "cryptographic". | 1. (N) A prefix ("crypto-") that means "cryptographic". | |||
| Usage: ISDs MAY use this prefix when it part of a term listed in | Usage: ISDs MAY use this prefix when it part of a term listed in | |||
| this Glossary. Otherwise, ISDs SHOULD avoid this prefix; instead, | this Glossary. Otherwise, ISDs SHOULD avoid this prefix; instead, | |||
| use the adjective "cryptographic". | use the adjective "cryptographic". | |||
| 2. (D) /slang/ In lower case, "crypto" is a synonym for the | 2. (D) In lower case, "crypto" is an abbreviation for the | |||
| adjective "cryptographic", or for the nouns "cryptography" or | adjective "cryptographic", or for the nouns "cryptography" or | |||
| "cryptographic component". | "cryptographic component". | |||
| Deprecated Term: ISDs SHOULD NOT use this slang term; it could be | Deprecated Abbreviation: ISDs SHOULD NOT use this term because it | |||
| misunderstood. | could easily be misunderstood. | |||
| 3. (O) /U.S. Government/ In upper case, "CRYPTO" is a marking or | 3. (O) /U.S. Government/ In upper case, "CRYPTO" is a marking or | |||
| designator that identifies "COMSEC keying material used to secure | designator that identifies "COMSEC keying material used to secure | |||
| or authenticate telecommunications carrying classified or | or authenticate telecommunications carrying classified or | |||
| sensitive U.S. Government or U.S. Government-derived information." | sensitive U.S. Government or U.S. Government-derived information." | |||
| [C4009] | [C4009] | |||
| $ cryptographic | $ cryptographic | |||
| (I) An adjective that refers to cryptography. | (I) An adjective that refers to cryptography. | |||
| $ cryptographic algorithm | $ cryptographic algorithm | |||
| (I) An algorithm that uses the science of cryptography, including | (I) An algorithm that uses the science of cryptography, including | |||
| (a) encryption algorithms, (b) cryptographic hash algorithms, (c) | (a) encryption algorithms, (b) cryptographic hash algorithms, (c) | |||
| digital signature algorithms, and (d) key agreement algorithms. | digital signature algorithms, and (d) key-agreement algorithms. | |||
| $ cryptographic application programming interface (CAPI) | $ cryptographic application programming interface (CAPI) | |||
| (I) The source code formats and procedures through which an | (I) The source code formats and procedures through which an | |||
| application program accesses cryptographic services, which are | application program accesses cryptographic services, which are | |||
| defined abstractly compared to their actual implementation. | defined abstractly compared to their actual implementation. | |||
| Example, see: PKCS #11, [R2628]. | Example, see: PKCS #11, [R2628]. | |||
| $ cryptographic association | $ cryptographic association | |||
| (I) A security association that involves the use of cryptography | (I) A security association that involves the use of cryptography | |||
| to provide security services for data exchanged by the associated | to provide security services for data exchanged by the associated | |||
| entities. (See: ISAKMP.) | entities. (See: ISAKMP.) | |||
| $ cryptographic boundary | $ cryptographic boundary | |||
| (I) See: (secondary definition under) cryptographic module. | (I) See: secondary definition under "cryptographic module". | |||
| $ cryptographic card | $ cryptographic card | |||
| (I) A cryptographic token in the form of a smart card or a PC | (I) A cryptographic token in the form of a smart card or a PC | |||
| card. | card. | |||
| $ cryptographic component | $ cryptographic component | |||
| (I) A generic term for any system component that involves | (I) A generic term for any system component that involves | |||
| cryptography. (See: cryptographic module.) | cryptography. (See: cryptographic module.) | |||
| $ cryptographic hash | $ cryptographic hash | |||
| (I) See: (secondary definition under) hash function. | (I) See: secondary definition under "hash function". | |||
| $ cryptographic ignition key (CIK) | $ cryptographic ignition key (CIK) | |||
| 1. (I) A physical (usually electronic) token used to store, | 1. (I) A physical (usually electronic) token used to store, | |||
| transport, and protect cryptographic keys. Usage: Sometimes | transport, and protect cryptographic keys. Usage: Sometimes | |||
| abbreviated as "crypto-ignition key". (Compare: fill device.) | abbreviated as "crypto-ignition key". (Compare: fill device.) | |||
| Tutorial: A typical use is to divide a split key between a CIK and | Tutorial: A typical use is to divide a split key between a CIK and | |||
| a cryptographic module, so that it is necessary to combine the two | a cryptographic module, so that it is necessary to combine the two | |||
| to regenerate a key-encrypting key and thus activate the module | to regenerate a key-encrypting key and thus activate the module | |||
| and other keys it contains. | and other keys it contains. | |||
| 2. (O) "Device or electronic key used to unlock the secure mode of | 2. (O) "Device or electronic key used to unlock the secure mode of | |||
| cryptographic equipment." [C4009] | cryptographic equipment." [C4009] | |||
| $ cryptographic key | $ cryptographic key | |||
| (I) See: key. Usage: Usually shortened to just "key". | (I) See: key. Usage: Usually shortened to just "key". | |||
| skipping to change at page 75, line 42 ¶ | skipping to change at page 78, line 43 ¶ | |||
| $ cryptographic system | $ cryptographic system | |||
| 1. (I) A set of cryptographic algorithms together with the key | 1. (I) A set of cryptographic algorithms together with the key | |||
| management processes that support use of the algorithms in some | management processes that support use of the algorithms in some | |||
| application context. | application context. | |||
| Usage: ISDs SHOULD use definition 1 because it covers a wider | Usage: ISDs SHOULD use definition 1 because it covers a wider | |||
| range of algorithms than definition 2. | range of algorithms than definition 2. | |||
| 2. (O) "A collection of transformations from plain text into | 2. (O) "A collection of transformations from plain text into | |||
| cipher text and vice versa [which would exclude digital signature, | cipher text and vice versa [which would exclude digital signature, | |||
| cryptographic hash, and key agreement algorithms], the particular | cryptographic hash, and key-agreement algorithms], the particular | |||
| transformation(s) to be used being selected by keys. The | transformation(s) to be used being selected by keys. The | |||
| transformations are normally defined by a mathematical algorithm." | transformations are normally defined by a mathematical algorithm." | |||
| [X509] | [X509] | |||
| $ cryptographic token | $ cryptographic token | |||
| 1. (I) A portable, user-controlled, physical device (e.g., smart | 1. (I) A portable, user-controlled, physical device (e.g., smart | |||
| card or PCMCIA card) used to store cryptographic information and | card or PCMCIA card) used to store cryptographic information and | |||
| possibly also perform cryptographic functions. (See: cryptographic | possibly also perform cryptographic functions. (See: cryptographic | |||
| card, token.) | card, token.) | |||
| skipping to change at page 76, line 29 ¶ | skipping to change at page 79, line 30 ¶ | |||
| methods used in encipherment and decipherment." [I7498 Part 2] | methods used in encipherment and decipherment." [I7498 Part 2] | |||
| Tutorial: Comprehensive coverage of applied cryptographic | Tutorial: Comprehensive coverage of applied cryptographic | |||
| protocols and algorithms is provided by Schneier [Schn]. | protocols and algorithms is provided by Schneier [Schn]. | |||
| Businesses and governments use cryptography to make data | Businesses and governments use cryptography to make data | |||
| incomprehensible to outsiders; to make data incomprehensible to | incomprehensible to outsiders; to make data incomprehensible to | |||
| both outsiders and insiders, the data is sent to lawyers for a | both outsiders and insiders, the data is sent to lawyers for a | |||
| rewrite. | rewrite. | |||
| $ Cryptoki | $ Cryptoki | |||
| (N) See: (secondary definition under) PKCS #11. | (N) A CAPI defined in PKCS #11. Pronunciation: "CRYPTO-key". | |||
| Derivation: Abbreviation of "cryptographic token interface". | ||||
| $ cryptology | $ cryptology | |||
| (I) The science of secret communication, that includes both | (I) The science of secret communication, that includes both | |||
| cryptography and cryptanalysis. | cryptography and cryptanalysis. | |||
| Tutorial: Sometimes the term is used more broadly to denote | Tutorial: Sometimes the term is used more broadly to denote | |||
| activity that includes both rendering signals secure (see: signal | activity that includes both rendering signals secure (see: signal | |||
| security) and extracting information from signals (see: signal | security) and extracting information from signals (see: signal | |||
| intelligence) [Kahn]. | intelligence) [Kahn]. | |||
| skipping to change at page 77, line 46 ¶ | skipping to change at page 80, line 47 ¶ | |||
| $ cyclic redundancy check (CRC) | $ cyclic redundancy check (CRC) | |||
| (I) A type of checksum algorithm that is not a cryptographic hash | (I) A type of checksum algorithm that is not a cryptographic hash | |||
| but is used to implement data integrity service where accidental | but is used to implement data integrity service where accidental | |||
| changes to data are expected. Sometimes called "cyclic redundancy | changes to data are expected. Sometimes called "cyclic redundancy | |||
| code". | code". | |||
| $ DAC | $ DAC | |||
| (N) See: Data Authentication Code, discretionary access control. | (N) See: Data Authentication Code, discretionary access control. | |||
| Deprecated Usage: This abbreviation is ambiguous; therefore, ISDs | Deprecated Usage: ISDs that use this term SHOULD state a | |||
| that use it SHOULD state a definition for it. | definition for it because this abbreviation is ambiguous. | |||
| $ daemon | $ daemon | |||
| (I) A computer program that is not invoked explicitly but waits | (I) A computer program that is not invoked explicitly but waits | |||
| until a specified condition occurs, and then runs with no | until a specified condition occurs, and then runs with no | |||
| associated user (principal), usually for an administrative | associated user (principal), usually for an administrative | |||
| purpose. (See: zombie.) | purpose. (See: zombie.) | |||
| $ dangling threat | $ dangling threat | |||
| (N) A threat to a system for which there is no corresponding | (O) A threat to a system for which there is no corresponding | |||
| vulnerability and, therefore, no implied risk. [C4009] | vulnerability and, therefore, no implied risk. [C4009] | |||
| $ dangling vulnerability | $ dangling vulnerability | |||
| (N) A vulnerability of a system for which there is no | (O) A vulnerability of a system for which there is no | |||
| corresponding threat and, therefore, no implied risk. [C4009] | corresponding threat and, therefore, no implied risk. [C4009] | |||
| $ DASS | $ DASS | |||
| (I) See: Distributed Authentication Security Service. | (I) See: Distributed Authentication Security Service. | |||
| $ data | $ data | |||
| (I) Information in a specific representation, usually as a | (I) Information in a specific representation, usually as a | |||
| sequence of symbols that have meaning and especially a | sequence of symbols that have meaning. | |||
| representation that can be processed or produced by a computer. | ||||
| Usage: Refers to both (a) representations that can be recognized, | ||||
| processed, or produced by a computer or other type of machine, and | ||||
| (b) representations that can be handled by a human. | ||||
| $ Data Authentication Algorithm, data authentication algorithm | $ Data Authentication Algorithm, data authentication algorithm | |||
| (N) /capitalized/ The ANSI standard for a keyed hash function that | (N) /capitalized/ The ANSI standard for a keyed hash function that | |||
| is equivalent to DES cipher block chaining with IV = 0. [A9009] | is equivalent to DES cipher block chaining with IV = 0. [A9009] | |||
| (D) /not capitalized/ Synonym for "checksum". | (D) /not capitalized/ Synonym for "checksum". | |||
| Deprecated Term: ISDs SHOULD NOT use the uncapitalized form, "data | Deprecated Term: ISDs SHOULD NOT use the uncapitalized form, "data | |||
| authentication algorithm", as a synonym for other kinds of | authentication algorithm", as a synonym for other kinds of | |||
| checksums. | checksums. | |||
| $ Data Authentication Code, data authentication code | $ Data Authentication Code, data authentication code | |||
| 1. (N) /capitalized/ A specific U.S. Government standard [FP113] | 1. (N) /capitalized/ A specific U.S. Government standard [FP113] | |||
| for a checksum that is computed by the Data Authentication | for a checksum that is computed by the Data Authentication | |||
| Algorithm. (Also known as the ANSI standard Message Authentication | Algorithm. Usage: a.k.a. Message Authentication Code [A9009].) | |||
| Code [A9009].) (See: DAC.) | (See: DAC.) | |||
| 2. (D) /not capitalized/ Synonym for checksum. | 2. (D) /not capitalized/ Synonym for checksum. | |||
| Deprecated Term: ISDs SHOULD NOT use "data authentication code" as | Deprecated Term: ISDs SHOULD NOT use "data authentication code" as | |||
| a synonym for other kinds of checksums; that usage would mix | a synonym for other kinds of checksums; that usage would mix | |||
| concepts in a potentially misleading way (see: authentication | concepts in a potentially misleading way (see: authentication | |||
| code). Instead, use "checksum", "error detection code", "hash", | code). Instead, use "checksum", "error detection code", "hash", | |||
| "keyed hash", "Message Authentication Code", or "protected | "keyed hash", "Message Authentication Code", or "protected | |||
| checksum", depending on what is meant. | checksum", depending on what is meant. | |||
| $ data compromise | $ data compromise | |||
| (I) A security incident in which information is exposed to | (I) A security incident in which information is exposed to | |||
| potential unauthorized access, such that unauthorized disclosure, | potential unauthorized access, such that unauthorized disclosure, | |||
| alteration, or use of the information may have occurred. (Compare: | alteration, or use of the information may have occurred. (Compare: | |||
| security compromise.) | security compromise.) | |||
| (O) A "compromise" is "A communication or physical transfer of | (O) A "compromise" is a "communication or physical transfer of | |||
| information to an unauthorized recipient." [DoD5] | information to an unauthorized recipient." [DoD5] | |||
| $ data confidentiality | $ data confidentiality | |||
| (I) The property that data is not disclosed to system entities | (I) The property that data is not disclosed to system entities | |||
| unless they have been authorized to know the data. (See: Bell- | unless they have been authorized to know the data. (See: Bell- | |||
| LaPadula model, classification, data confidentiality service. | LaPadula model, classification, data confidentiality service. | |||
| Compare: privacy.) | Compare: privacy.) | |||
| (D) "The property that information is not made available or | (D) "The property that information is not made available or | |||
| disclosed to unauthorized individuals, entities, or processes | disclosed to unauthorized individuals, entities, or processes | |||
| [i.e., to any unauthorized system entity]." [I7498 Part 2]. | [i.e., to any unauthorized system entity]." [I7498 Part 2]. | |||
| Deprecated Definition: The phrase "made available" might be | Deprecated Definition: The phrase "made available" might be | |||
| interpreted to mean that the data could be altered, and that would | interpreted to mean that the data could be altered, and that would | |||
| confuse this term with the concept of "data integrity". | confuse this term with the concept of "data integrity". | |||
| $ data confidentiality service | $ data confidentiality service | |||
| (I) A security service that protects data against unauthorized | (I) A security service that protects data against unauthorized | |||
| disclosure. (See: access control, data confidentiality, flow | disclosure. (See: access control, data confidentiality, datagram | |||
| control, inference control.) | confidentiality service, flow control, inference control.) | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "privacy", which is a different concept. | for "privacy", which is a different concept. | |||
| $ Data Encryption Algorithm (DEA) | $ Data Encryption Algorithm (DEA) | |||
| (N) A symmetric block cipher, defined in the U.S. Government's | (N) A symmetric block cipher, defined in the U.S. Government's | |||
| DES. DEA uses a 64-bit key, of which 56 bits are independently | DES. DEA uses a 64-bit key, of which 56 bits are independently | |||
| chosen and 8 are parity bits, and maps a 64-bit block into another | chosen and 8 are parity bits, and maps a 64-bit block into another | |||
| 64-bit block. [FP046] (See: AES, symmetric cryptography.) | 64-bit block. [FP046] (See: AES, symmetric cryptography.) | |||
| skipping to change at page 79, line 44 ¶ | skipping to change at page 82, line 48 ¶ | |||
| (I) A cryptographic key that is used to encipher application data. | (I) A cryptographic key that is used to encipher application data. | |||
| (Compare: key-encrypting key.) | (Compare: key-encrypting key.) | |||
| $ Data Encryption Standard (DES) | $ Data Encryption Standard (DES) | |||
| (N) A U.S. Government standard [FP046] that specifies the DEA and | (N) A U.S. Government standard [FP046] that specifies the DEA and | |||
| states policy for using the algorithm to protect unclassified, | states policy for using the algorithm to protect unclassified, | |||
| sensitive data. (See: AES.) | sensitive data. (See: AES.) | |||
| $ data integrity | $ data integrity | |||
| 1. (I) The property that data has not been changed, destroyed, or | 1. (I) The property that data has not been changed, destroyed, or | |||
| lost in an unauthorized or accidental manner. (See: Biba model, | lost in an unauthorized or accidental manner. (See: data integrity | |||
| data integrity service.) | service. Compare: correctness integrity, source integrity.) | |||
| 2. (O) "The property that information has not been modified or | 2. (O) "The property that information has not been modified or | |||
| destroyed in an unauthorized manner." [I7498 Part 2] | destroyed in an unauthorized manner." [I7498 Part 2] | |||
| Usage: Deals with (a) constancy of and confidence in data values, | Usage: Deals with (a) constancy of and confidence in data values, | |||
| and not with either (b) information that the values represent | and not with either (b) information that the values represent | |||
| (see: correctness integrity) or (c) the trustworthiness of the | (see: correctness integrity) or (c) the trustworthiness of the | |||
| source of the values (see: source integrity). | source of the values (see: source integrity). | |||
| $ data integrity service | $ data integrity service | |||
| (I) A security service that protects against unauthorized changes | (I) A security service that protects against unauthorized changes | |||
| to data, including both intentional change or destruction and | to data, including both intentional change or destruction and | |||
| accidental change or loss, by ensuring that changes to data are | accidental change or loss, by ensuring that changes to data are | |||
| detectable. (See: data integrity.) | detectable. (See: data integrity, checksum, datagram integrity | |||
| service.) | ||||
| Tutorial: A data integrity service can only detect a change and | Tutorial: A data integrity service can only detect a change and | |||
| report it to an appropriate system entity; changes cannot be | report it to an appropriate system entity; changes cannot be | |||
| prevented unless the system is perfect (error-free) and no | prevented unless the system is perfect (error-free) and no | |||
| malicious user has access. However, a system that offers data | malicious user has access. However, a system that offers data | |||
| integrity service might also attempt to correct and recover from | integrity service might also attempt to correct and recover from | |||
| changes. | changes. | |||
| The ability of this service to detect changes is limited by the | ||||
| technology of the mechanisms used to implement the service. For | ||||
| example, if the mechanism were a one-bit parity check across each | ||||
| entire SDU, then changes to an odd number of bits in an SDU would | ||||
| be detected, but changes to an even number of bits would not. | ||||
| Relationship between data integrity service and authentication | Relationship between data integrity service and authentication | |||
| services: Although data integrity service is defined separately | services: Although data integrity service is defined separately | |||
| from data origin authentication service and peer entity | from data origin authentication service and peer entity | |||
| authentication service, it is closely related to them. | authentication service, it is closely related to them. | |||
| Authentication services depend, by definition, on companion data | Authentication services depend, by definition, on companion data | |||
| integrity services. Data origin authentication service provides | integrity services. Data origin authentication service provides | |||
| verification that the identity of the original source of a | verification that the identity of the original source of a | |||
| received data unit is as claimed; there can be no such | received data unit is as claimed; there can be no such | |||
| verification if the data unit has been altered. Peer entity | verification if the data unit has been altered. Peer entity | |||
| authentication service provides verification that the identity of | authentication service provides verification that the identity of | |||
| skipping to change at page 80, line 49 ¶ | skipping to change at page 84, line 9 ¶ | |||
| service, this service is independent of any association between | service, this service is independent of any association between | |||
| the originator and the recipient, and the data in question may | the originator and the recipient, and the data in question may | |||
| have originated at any time in the past. | have originated at any time in the past. | |||
| A digital signature mechanism can be used to provide this service, | A digital signature mechanism can be used to provide this service, | |||
| because someone who does not know the private key cannot forge the | because someone who does not know the private key cannot forge the | |||
| correct signature. However, by using the signer's public key, | correct signature. However, by using the signer's public key, | |||
| anyone can verify the origin of correctly signed data. | anyone can verify the origin of correctly signed data. | |||
| This service is usually bundled with connectionless data integrity | This service is usually bundled with connectionless data integrity | |||
| service. (See: ("relationship between data integrity service and | service. (See: "relationship between data integrity service and | |||
| authentication services" under) data integrity service. | authentication services" under "data integrity service". | |||
| $ data owner | $ data owner | |||
| (O) /U.S. Government/ The organization that has the final | (N) The organization that has the final statutory and operational | |||
| statutory and operational authority for specified information. | authority for specified information. | |||
| $ data privacy | $ data privacy | |||
| (D) Synonym for "data confidentiality". | (D) Synonym for "data confidentiality". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | |||
| in a potentially misleading way. Instead, use either "data | in a potentially misleading way. Instead, use either "data | |||
| confidentiality" or "privacy" or both, depending on what is meant. | confidentiality" or "privacy" or both, depending on what is meant. | |||
| $ data recovery | $ data recovery | |||
| 1. (I) /cryptanalysis/ A process for learning, from some cipher | 1. (I) /cryptanalysis/ A process for learning, from some cipher | |||
| skipping to change at page 81, line 29 ¶ | skipping to change at page 84, line 40 ¶ | |||
| $ data security | $ data security | |||
| (I) The protection of data from disclosure, alteration, | (I) The protection of data from disclosure, alteration, | |||
| destruction, or loss that either is accidental or is intentional | destruction, or loss that either is accidental or is intentional | |||
| but unauthorized. | but unauthorized. | |||
| Tutorial: Both data confidentiality service and data integrity | Tutorial: Both data confidentiality service and data integrity | |||
| service are needed to achieve data security. | service are needed to achieve data security. | |||
| $ datagram | $ datagram | |||
| (I) "A self-contained, independent entity of data [i.e., a data | (I) "A self-contained, independent entity of data [i.e., a packet] | |||
| object, a discrete set of bits] carrying sufficient information to | carrying sufficient information to be routed from the source | |||
| be routed from the source to the destination." [R1983] | [computer] to the destination computer without reliance on earlier | |||
| exchanges between this source and destination computer and the | ||||
| transporting network." Example: A PDU of IP. [R1983] | ||||
| $ datagram confidentiality service | ||||
| (I) A data confidentiality service that preserves the | ||||
| confidentiality of data in a single, independent, packet; i.e., | ||||
| the service applies to datagrams one-at-a-time. Example: ESP. | ||||
| (See: data confidentiality.) | ||||
| Usage: When a protocol is said to provide data confidentiality | ||||
| service, this is usually understood to mean that only the SDU is | ||||
| protected in each packet. ISDs that use the term to mean that the | ||||
| entire PDU is protected should include a highlighted definition. | ||||
| Tutorial: This basic form of network confidentiality service | ||||
| suffices for protecting the data in a stream of packets in both | ||||
| connectionless and connection-oriented protocols. Except perhaps | ||||
| for traffic flow confidentiality, nothing further is needed to | ||||
| protect the confidentiality of data carried by a packet stream. | ||||
| The OSIRM distinguishes between connection confidentiality and | ||||
| connectionless confidentiality. The IPS need not make that | ||||
| distinction, because those services are just instances of the same | ||||
| service (i.e., datagram confidentiality) being offered in two | ||||
| different protocol contexts. (For data integrity service, however, | ||||
| additional effort is needed to protect a stream, and the IPS does | ||||
| need to distinguish between "datagram integrity service" and | ||||
| "stream integrity service".) | ||||
| $ datagram integrity service | ||||
| (I) A data integrity service that preserves the integrity of data | ||||
| in a single, independent, data packet (i.e., the service applies | ||||
| to datagrams one-at-a-time). (See: data integrity. Compare: stream | ||||
| integrity service.) | ||||
| Tutorial: The ability to provide appropriate data integrity is | ||||
| important in many Internet security situations, and so there are | ||||
| different kinds of data integrity services suited to different | ||||
| applications. This service is the simplest kind; it is suitable | ||||
| for connectionless data transfers. | ||||
| Datagram integrity service usually is designed only to attempt to | ||||
| detect changes to the SDU in each packet, but it might also | ||||
| attempt to detect changes to some or all of the PCI in each packet | ||||
| (see: selective field integrity). In contrast to this simple, one- | ||||
| at-a-time service, some security situations demand a more complex | ||||
| service that also attempts to detect deleted, inserted, or | ||||
| reordered datagrams within a stream of datagrams (see: stream | ||||
| integrity service). | ||||
| $ DEA | $ DEA | |||
| (N) See: Data Encryption Algorithm. | (N) See: Data Encryption Algorithm. | |||
| $ deception | $ deception | |||
| (I) A circumstance or event that may result in an authorized | (I) A circumstance or event that may result in an authorized | |||
| entity receiving false data and believing it to be true. (See: | entity receiving false data and believing it to be true. (See: | |||
| authentication.) | authentication.) | |||
| Tutorial: This is a type of threat consequence, and it can be | Tutorial: This is a type of threat consequence, and it can be | |||
| skipping to change at page 81, line 55 ¶ | skipping to change at page 86, line 10 ¶ | |||
| $ decipher | $ decipher | |||
| (D) Synonym for "decrypt". | (D) Synonym for "decrypt". | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "decrypt". However, see usage note under "encryption". | for "decrypt". However, see usage note under "encryption". | |||
| $ decipherment | $ decipherment | |||
| (D) Synonym for "decryption". | (D) Synonym for "decryption". | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "decryption". However, see the usage note under "encryption". | for "decryption". However, see the Usage note under "encryption". | |||
| $ declassification | ||||
| (I) An authorized process by which information is declassified. | ||||
| (See: classification.) | ||||
| $ declassify | ||||
| (I) To officially remove the security level designation of a | ||||
| classified information item or information type, such that the | ||||
| information is no longer classified (i.e., becomes unclassified). | ||||
| (See: classified, classify, security level. Compare: downgrade.) | ||||
| $ decode | $ decode | |||
| 1. (I) Convert encoded data back to its original form of | 1. (I) Convert encoded data back to its original form of | |||
| representation. (Compare: decrypt.) | representation. (Compare: decrypt.) | |||
| 2. (D) Synonym for "decrypt". | 2. (D) Synonym for "decrypt". | |||
| Deprecated Definition: Encoding is not usually meant to conceal | Deprecated Definition: Encoding is not usually meant to conceal | |||
| meaning. Therefore, ISDs SHOULD NOT use this term as a synonym for | meaning. Therefore, ISDs SHOULD NOT use this term as a synonym for | |||
| "decrypt", because that would mix concepts in a potentially | "decrypt", because that would mix concepts in a potentially | |||
| misleading way. | misleading way. | |||
| $ decrypt | $ decrypt | |||
| (I) Cryptographically restore cipher text to the plaintext form it | (I) Cryptographically restore cipher text to the plaintext form it | |||
| had before encryption. | had before encryption. | |||
| $ decryption | $ decryption | |||
| (I) See: (secondary definition under) encryption. | (I) See: secondary definition under "encryption". | |||
| $ dedicated security mode | $ dedicated security mode | |||
| (I) A mode of operation of an information system, wherein all | (I) A mode of system operation wherein all users having access to | |||
| users have the clearance or authorization, and the need-to-know, | the system possess, for all data handled by the system, both (a) | |||
| for all data handled by the system. In this mode, the system may | all necessary authorizations (i.e., security clearance and formal | |||
| handle either (a) a single classification level or category of | access approval) and (b) a need-to-know. (See: /system operation/ | |||
| information or (b) a range of levels and categories. [DoD2] | under "mode", formal access approval, need to know, protection | |||
| level, security clearance.) | ||||
| Usage: This mode was defined in U.S. DoD policy on system | Usage: Usually abbreviated as "dedicated mode". This mode was | |||
| accreditation, but the term is also used outside the Government. | defined in U.S. Government policy on system accreditation, but the | |||
| term is also used outside the Government. In this mode, the system | ||||
| may handle either (a) a single classification level or category of | ||||
| information or (b) a range of levels and categories. | ||||
| $ default account | $ default account | |||
| (I) A system login account (usually accessed with a user | (I) A system login account (usually accessed with a user | |||
| identifier and password) that has been predefined in a | identifier and password) that has been predefined in a | |||
| manufactured system to permit initial access when the system is | manufactured system to permit initial access when the system is | |||
| first put into service. | first put into service. (See: harden.] | |||
| Tutorial: Sometimes, the default user name and password are the | Tutorial: A default account becomes a serious vulnerability if not | |||
| same in each copy of the system. In any case, when the system is | properly administered. Sometimes, the default identifier and | |||
| put into service, the default password should immediately be | password are well-known because they are the same in each copy of | |||
| changed or the default account should be disabled. | the system. In any case, when a system is put into service, any | |||
| default password should immediately be changed or the default | ||||
| account should be disabled. | ||||
| $ defense in depth | $ defense in depth | |||
| (I) An approach to constructing security architectures that uses | (I) An approach to constructing security architectures that uses | |||
| layered and complementary security mechanisms and countermeasures, | layered and complementary security mechanisms and countermeasures, | |||
| so that if one security mechanism is defeated, one or more other | so that if one security mechanism is defeated, one or more other | |||
| mechanisms (which are "behind" or "beneath" the first mechanism) | mechanisms (which are "behind" or "beneath" the first mechanism) | |||
| still provide protection. | still provide protection. | |||
| Tutorial: This concept is appealing because it aligns with | Tutorial: This concept is appealing because it aligns with | |||
| traditional warfare doctrine, which applies defense in depth to | traditional warfare doctrine, which applies defense in depth to | |||
| physical, geospatial structures. It is more difficult to apply the | physical, geospatial structures. It is more difficult to apply the | |||
| concept to logical, cyberspace structures of computer networks. | concept to logical, cyberspace structures of computer networks. | |||
| The concept assumes that networks have a spatial or topological | The concept assumes that networks have a spatial or topological | |||
| representation. It also assumes that there can be implemented -- | representation. It also assumes that there can be implemented -- | |||
| from the "outer perimeter" of a network, through its various | from the "outer perimeter" of a network, through its various | |||
| "layers" of components, to its "center" (i.e., to the subscriber | "layers" of components, to its "center" (i.e., to the subscriber | |||
| application systems supported by the network) -- a varied series | application systems supported by the network) -- a varied series | |||
| of countermeasures that together provide adequate protection. | of countermeasures that together provide adequate protection. | |||
| However, it is more difficult to map the topology of networks and | However, it is more difficult to map the topology of networks and | |||
| make certain that no paths exist by which an attacker could bypass | make certain that no path exists by which an attacker could bypass | |||
| defensive layers. | all defensive layers. | |||
| $ Defense Information Infrastructure (DII) | $ Defense Information Infrastructure (DII) | |||
| (O) /U.S. DoD/ The U.S. DoD's shared or interconnected system of | (O) /U.S. DoD/ The U.S. DoD's shared, interconnected system of | |||
| computers, communications, data, applications, security, people, | computers, communications, data, applications, security, people, | |||
| training, and other support structure, serving local and worldwide | training, and support structures, serving information needs | |||
| information needs. (See: DISN.) | worldwide. (See: DISN.) Usage: Has evolved to be called the GIG. | |||
| Tutorial: The DII connects U.S. DoD mission support, command and | Tutorial: The DII connects mission support, command and control, | |||
| control, and intelligence computers and users through voice, data, | and intelligence computers and users through voice, data, imagery, | |||
| imagery, video, and multimedia services, and provides information | video, and multimedia services, and provides information | |||
| processing and value-added services to subscribers over the DISN. | processing and value-added services to subscribers over the DISN. | |||
| Users' own data and application software are not considered part | Users' own data and application software are not considered part | |||
| of the DII. | of the DII. | |||
| $ Defense Information Systems Network (DISN) | $ Defense Information Systems Network (DISN) | |||
| (O) /U.S. DoD/ The U.S. DoD's consolidated, worldwide, enterprise | (O) /U.S. DoD/ The U.S. DoD's consolidated, worldwide, enterprise | |||
| level telecommunications infrastructure that provides end-to-end | level telecommunications infrastructure that provides end-to-end | |||
| information transfer for supporting military operations; a part of | information transfer for supporting military operations; a part of | |||
| the DII. | the DII. (Compare: GIG.) | |||
| $ degauss | $ degauss | |||
| 1a. (N) Apply a magnetic field to permanently remove, erase, or | 1a. (N) Apply a magnetic field to permanently remove, erase, or | |||
| clear data from a magnetic storage medium, such as a tape or disk | clear data from a magnetic storage medium, such as a tape or disk | |||
| [NCS25]. | [NCS25]. | |||
| 1b. (N) Reduce magnetic flux density to zero by applying a | 1b. (N) Reduce magnetic flux density to zero by applying a | |||
| reversing magnetic field. (See: magnetic remanence.) | reversing magnetic field. (See: magnetic remanence.) | |||
| $ degausser | $ degausser | |||
| (N) An electrical device that can degauss magnetic storage media. | (N) An electrical device that can degauss magnetic storage media. | |||
| $ DEK | $ DEK | |||
| (I) See: data encryption key. | (I) See: data encryption key. | |||
| $ delay | ||||
| (I) /packet/ See: secondary definition under "stream integrity | ||||
| service". | ||||
| $ deletion | ||||
| (I) /packet/ See: secondary definition under "stream integrity | ||||
| service". | ||||
| $ delta CRL | $ delta CRL | |||
| (I) A partial CRL that only contains entries for X.509 | (I) A partial CRL that only contains entries for X.509 | |||
| certificates that have been revoked since the issuance of a prior, | certificates that have been revoked since the issuance of a prior, | |||
| base CRL. This method can be used to partition CRLs that become | base CRL. This method can be used to partition CRLs that become | |||
| too large and unwieldy. (Compare: CRL distribution point.) | too large and unwieldy. (Compare: CRL distribution point.) | |||
| $ demilitarized zone (DMZ) | $ demilitarized zone (DMZ) | |||
| (D) Synonym for "buffer zone". | (D) Synonym for "buffer zone". | |||
| Deprecated Term: ISDs SHOULD NOT use this term with this | Deprecated Usage: ISDs SHOULD NOT use this definition because such | |||
| definition; that would mix concepts in a potentially misleading | usage would mix concepts in a potentially misleading way. (See: | |||
| way. (See: (Deprecated Usage under) Green Book.) | Deprecated Usage under "Green Book".) | |||
| $ denial of service | $ denial of service | |||
| (I) The prevention of authorized access to a system resource or | (I) The prevention of authorized access to a system resource or | |||
| the delaying of system operations and functions. (See: | the delaying of system operations and functions. (See: | |||
| availability, critical, flooding.) | availability, critical, flooding.) | |||
| Tutorial: A denial-of-service attack can prevent the normal | Tutorial: A denial-of-service attack can prevent the normal | |||
| conduct of business on the Internet. There are four types of | conduct of business on the Internet. There are four types of | |||
| solutions to this security problem: | solutions to this security problem: | |||
| - Awareness: Maintaining cognizance of security threats and | - Awareness: Maintaining cognizance of security threats and | |||
| vulnerabilities. (See: CERT.) | vulnerabilities. (See: CERT.) | |||
| - Detection: Finding attacks on end systems and subnetworks. | - Detection: Finding attacks on end systems and subnetworks. | |||
| (See: intrusion detection.) | (See: intrusion detection.) | |||
| - Prevention: Following defensive practices on network-connected | - Prevention: Following defensive practices on network-connected | |||
| systems. (See: [RFC 2167].) | systems. (See: [R2827].) | |||
| - Response: Reacting effectively when attacks occur. (See: CSIRT, | - Response: Reacting effectively when attacks occur. (See: CSIRT, | |||
| contingency plan.) | contingency plan.) | |||
| $ DES | $ DES | |||
| (N) See: Data Encryption Standard. | (N) See: Data Encryption Standard. | |||
| $ designated approving authority (DAA) | $ designated approving authority (DAA) | |||
| (O) /U.S. Government/ Synonym for "accreditor". | (O) /U.S. Government/ Synonym for "accreditor". | |||
| $ detection | ||||
| (I) See: secondary definition under "security". | ||||
| $ deterrence | ||||
| (I) See: secondary definition under "security". | ||||
| $ dictionary attack | $ dictionary attack | |||
| (I) An attack that uses a brute-force technique of successively | (I) An attack that uses a brute-force technique of successively | |||
| trying all the words in some large, exhaustive list. | trying all the words in some large, exhaustive list. | |||
| Examples: An attack on an authentication service by trying all | Examples: Attack an authentication service by trying all possible | |||
| possible passwords. An attack on encryption by encrypting some | passwords. Attack an encryption service by encrypting some known | |||
| known plaintext phrase with all possible keys so that the key for | plaintext phrase with all possible keys so that the key for any | |||
| any given encrypted message containing that phrase may be obtained | given encrypted message containing that phrase may be obtained by | |||
| by lookup. | lookup. | |||
| $ Diffie-Hellman | $ Diffie-Hellman | |||
| (N) A key-agreement algorithm published in 1976 by Whitfield | (N) A key-agreement algorithm published in 1976 by Whitfield | |||
| Diffie and Martin Hellman [DH76, R2631]. | Diffie and Martin Hellman [DH76, R2631]. | |||
| Tutorial: Diffie-Hellman does key establishment, not encryption. | Tutorial: Diffie-Hellman does key establishment, not encryption. | |||
| However, the key that it produces may be used for encryption, for | However, the key that it produces may be used for encryption, for | |||
| further key management operations, or for any other cryptography. | further key management operations, or for any other cryptography. | |||
| The algorithm is described in [R2631] and [Schn]. In brief, Alice | The algorithm is described in [R2631] and [Schn]. In brief, Alice | |||
| skipping to change at page 85, line 18 ¶ | skipping to change at page 90, line 5 ¶ | |||
| authenticate each party to the other, a protocol based on the | authenticate each party to the other, a protocol based on the | |||
| algorithm may be vulnerable to a man-in-the-middle attack. | algorithm may be vulnerable to a man-in-the-middle attack. | |||
| $ digest | $ digest | |||
| See: message digest. | See: message digest. | |||
| $ digital certificate | $ digital certificate | |||
| (I) A certificate document in the form of a digital data object (a | (I) A certificate document in the form of a digital data object (a | |||
| data object used by a computer) to which is appended a computed | data object used by a computer) to which is appended a computed | |||
| digital signature value that depends on the data object. (See: | digital signature value that depends on the data object. (See: | |||
| attribute certificate, capability, public-key certificate.) | attribute certificate, public-key certificate.) | |||
| Deprecated Usage: ISDs SHOULD NOT use this term to refer to a | Deprecated Usage: ISDs SHOULD NOT use this term to refer to a | |||
| signed CRL or CKL. Although the recommended definition can be | signed CRL or CKL. Although the recommended definition can be | |||
| interpreted to include other signed items, the security community | interpreted to include other signed items, the security community | |||
| does not use the term with those meanings. | does not use the term with those meanings. | |||
| $ digital certification | $ digital certification | |||
| (D) Synonym for "certification". | (D) Synonym for "certification". | |||
| Deprecated Definition: ISDs SHOULD NOT use this definition unless | Deprecated Definition: ISDs SHOULD NOT use this definition unless | |||
| skipping to change at page 85, line 46 ¶ | skipping to change at page 90, line 33 ¶ | |||
| originally written in a non-electronic, non-magnetic medium | originally written in a non-electronic, non-magnetic medium | |||
| (usually ink on paper) or is an analogue of a document of that | (usually ink on paper) or is an analogue of a document of that | |||
| type. | type. | |||
| $ digital envelope | $ digital envelope | |||
| (I) A combination of (a) encrypted content data (of any kind) | (I) A combination of (a) encrypted content data (of any kind) | |||
| intended for a recipient and (b) the content encryption key in an | intended for a recipient and (b) the content encryption key in an | |||
| encrypted form that has been prepared for the use of the | encrypted form that has been prepared for the use of the | |||
| recipient. | recipient. | |||
| Usage: In ISDs, the term should be defined at the point of first | Usage: In ISDs, the term SHOULD be defined at the point of first | |||
| use because, although the term is defined in PKCS #7 and used in | use because, although the term is defined in PKCS #7 and used in | |||
| S/MIME, it is not widely known. | S/MIME, it is not widely known. | |||
| Tutorial: Digital enveloping is not simply a synonym for | Tutorial: Digital enveloping is not simply a synonym for | |||
| implementing data confidentiality with encryption; digital | implementing data confidentiality with encryption; digital | |||
| enveloping is a hybrid encryption scheme to "seal" a message or | enveloping is a hybrid encryption scheme to "seal" a message or | |||
| other data, by encrypting the data and sending both it and a | other data, by encrypting the data and sending both it and a | |||
| protected form of the key to the intended recipient, so that no | protected form of the key to the intended recipient, so that no | |||
| one other than the intended recipient can "open" the message. In | one other than the intended recipient can "open" the message. In | |||
| PCKS #7, it means first encrypting the data using a symmetric | PKCS #7, it means first encrypting the data using a symmetric | |||
| encryption algorithm and a secret key, and then encrypting the | encryption algorithm and a secret key, and then encrypting the | |||
| secret key using an asymmetric encryption algorithm and the public | secret key using an asymmetric encryption algorithm and the public | |||
| key of the intended recipient. In S/MIME, additional methods are | key of the intended recipient. In S/MIME, additional methods are | |||
| defined for encrypting the content encryption key. | defined for encrypting the content encryption key. | |||
| $ Digital ID(service mark) | $ Digital ID(service mark) | |||
| Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | (D) Synonym for "digital certificate". | |||
| "digital certificate". The term (a) is the service mark of a | ||||
| commercial firm and (b) unnecessarily duplicates the meaning of | Deprecated Term: ISDs SHOULD NOT use this term. It is a service | |||
| other, well-established terms. (See: credential.) | mark of a commercial firm, and it unnecessarily duplicates the | |||
| meaning of a better-established term. (See: credential.) | ||||
| $ digital key | $ digital key | |||
| Usage: The adjective "digital" need not be used with "key" or | (D) A synonym for an input parameter of a cryptographic algorithm | |||
| "cryptographic key", unless the context is insufficient to | or other process. | |||
| distinguish the digital key from another kind of key, such as a | ||||
| Deprecated Usage: The adjective "digital" need not be used with | ||||
| "key" or "cryptographic key", unless the context is insufficient | ||||
| to distinguish the digital key from another kind of key, such as a | ||||
| metal key for a door lock. | metal key for a door lock. | |||
| $ digital notary | $ digital notary | |||
| (I) An electronic functionary analogous to a notary public. | (I) An electronic functionary analogous to a notary public. | |||
| Provides a trusted time stamp for a digital document, so that | Provides a trusted time stamp for a digital document, so that | |||
| someone can later prove that the document existed at that point in | someone can later prove that the document existed at that point in | |||
| time; verifies the signature(s) on a signed document before | time; verifies the signature(s) on a signed document before | |||
| applying the stamp. (See: notarization.) | applying the stamp. (See: notarization.) | |||
| $ digital signature | $ digital signature | |||
| skipping to change at page 86, line 43 ¶ | skipping to change at page 91, line 35 ¶ | |||
| integrity. (See: data origin authentication service, data | integrity. (See: data origin authentication service, data | |||
| integrity service, signer. Compare: digitized signature, | integrity service, signer. Compare: digitized signature, | |||
| electronic signature.) | electronic signature.) | |||
| 2. (I) "Data appended to, or a cryptographic transformation of, a | 2. (I) "Data appended to, or a cryptographic transformation of, a | |||
| data unit that allows a recipient of the data unit to prove the | data unit that allows a recipient of the data unit to prove the | |||
| source and integrity of the data unit and protect against forgery, | source and integrity of the data unit and protect against forgery, | |||
| e.g. by the recipient." [I7498 Part 2] | e.g. by the recipient." [I7498 Part 2] | |||
| Tutorial: A digital signature should have these properties: | Tutorial: A digital signature should have these properties: | |||
| - Uniquely identify a system entity as being the signer. | - Uniquely identify a system entity as being the signer. | |||
| - Be under the signer's sole control, so that it cannot be | - Be under the signer's sole control, so that it cannot be | |||
| created by any other entity. | created by any other entity. | |||
| - Be capable of being verified. (See: validate vs. verify.) | - Be capable of being verified. (See: validate vs. verify.) | |||
| - Be bound to the signed data object in such a way that if the | - Be bound to the signed data object in such a way that if the | |||
| data is changed, then when an attempt is made to verify the | data is changed, then when an attempt is made to verify the | |||
| signature, it will be seen as not authentic. | signature, it will be seen as not authentic. | |||
| To achieve these properties, the data object is first input to a | To achieve these properties, the data object is first input to a | |||
| hash function, and then the hash result is cryptographically | hash function, and then the hash result is cryptographically | |||
| transformed using a private key of the signer. The final resulting | transformed using a private key of the signer. The final resulting | |||
| value is called the digital signature of the data object. The | value is called the digital signature of the data object. The | |||
| signature value is a protected checksum, because the properties of | signature value is a protected checksum, because the properties of | |||
| a cryptographic hash ensure that if the data object is changed, | a cryptographic hash ensure that if the data object is changed, | |||
| the digital signature will no longer match it. The digital | the digital signature will no longer match it. The digital | |||
| signature is unforgeable because one cannot be certain of | signature is unforgeable because one cannot be certain of | |||
| correctly creating or changing the signature without knowing the | correctly creating or changing the signature without knowing the | |||
| private key of the supposed signer. | private key of the supposed signer. | |||
| Some digital signature schemes use a asymmetric encryption | Some digital signature schemes use an asymmetric encryption | |||
| algorithm (e.g., see: RSA) to transform the hash result. Thus, | algorithm (e.g., see: RSA) to transform the hash result. Thus, | |||
| when Alice needs to sign a message to send to Bob, she can use her | when Alice needs to sign a message to send to Bob, she can use her | |||
| private key to encrypt the hash result. Bob receives both the | private key to encrypt the hash result. Bob receives both the | |||
| message and the digital signature. Bob can use Alice's public key | message and the digital signature. Bob can use Alice's public key | |||
| to decrypt the signature, and then compare the plaintext result to | to decrypt the signature, and then compare the plaintext result to | |||
| the hash result that he computes by hashing the message himself. | the hash result that he computes by hashing the message himself. | |||
| If the values are equal, Bob accepts the message because he is | If the values are equal, Bob accepts the message because he is | |||
| certain that it is from Alice and has arrived unchanged. If the | certain that it is from Alice and has arrived unchanged. If the | |||
| values are not equal, Bob rejects the message because either the | values are not equal, Bob rejects the message because either the | |||
| message or the signature was altered in transit. | message or the signature was altered in transit. | |||
| skipping to change at page 88, line 11 ¶ | skipping to change at page 92, line 54 ¶ | |||
| unobtrusive. Depending on the particular technique that is used, | unobtrusive. Depending on the particular technique that is used, | |||
| digital watermarking can assist in proving ownership, controlling | digital watermarking can assist in proving ownership, controlling | |||
| duplication, tracing distribution, ensuring data integrity, and | duplication, tracing distribution, ensuring data integrity, and | |||
| performing other functions to protect intellectual property | performing other functions to protect intellectual property | |||
| rights. [ACM] | rights. [ACM] | |||
| $ digitized signature | $ digitized signature | |||
| (D) Denotes various forms of digitized images of handwritten | (D) Denotes various forms of digitized images of handwritten | |||
| signatures. (Compare: digital signature). | signatures. (Compare: digital signature). | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it looks like | Deprecated Term: ISDs SHOULD NOT use this term without including | |||
| sloppy use of "digital signature", which is the term standardized | this definition. This term suggests careless use of "digital | |||
| by [I7498 Part 2]. (See: electronic signature.) | signature", which is the term standardized by [I7498 Part 2]. | |||
| (See: electronic signature.) | ||||
| $ DII | $ DII | |||
| (O) See: Defense Information Infrastructure. | (O) See: Defense Information Infrastructure. | |||
| $ directory, Directory | $ directory, Directory | |||
| 1. (I) /not capitalized/ Refers generically to a database server | 1. (I) /not capitalized/ Refers generically to a database server | |||
| or other system that provides information -- such as a digital | or other system that stores and provides access to values of | |||
| certificate or CRL -- about an entity whose name is known. | descriptive or operational data items that are associated with the | |||
| (Compare: repository.) | components of a system. (Compare: repository.) | |||
| 2. (N) /capitalized/ Refers specifically to the X.500 Directory. | 2. (N) /capitalized/ Refers specifically to the X.500 Directory. | |||
| (See: DN, X.500.) | (See: DN, X.500.) | |||
| $ Directory Access Protocol (DAP) | $ Directory Access Protocol (DAP) | |||
| (N) An OSI protocol [X519] for communication between a Directory | (N) An OSI protocol [X519] for communication between a Directory | |||
| User Agent (a type of X.500 client) and a Directory System Agent | User Agent (a type of X.500 client) and a Directory System Agent | |||
| (a type of X.500 server). (See: LDAP.) | (a type of X.500 server). (See: LDAP.) | |||
| $ disaster plan | $ disaster plan | |||
| (O) Synonym for "contingency plan". | (O) Synonym for "contingency plan". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; instead, for | Deprecated Term: ISDs SHOULD NOT use this term; instead, for | |||
| consistency and neutrality of language, ISDs SHOULD use | consistency and neutrality of language, ISDs SHOULD use | |||
| "contingency plan". | "contingency plan". | |||
| $ disclosure | $ disclosure | |||
| See: unauthorized disclosure. Compare: exposure. | See: unauthorized disclosure. Compare: exposure. | |||
| $ discretionary access control | $ discretionary access control | |||
| 1a. (I) An access control service that enforces a security policy | 1a. (I) An access control service that (a) enforces a security | |||
| based on the identity of system entities and the authorizations | policy based on the identity of system entities and the | |||
| associated with those identities. (See: access control list, DAC, | authorizations associated with the identities and (b) incorporates | |||
| identity-based security policy, mandatory access control.) | a concept of ownership in which access rights for a system | |||
| resource may be granted and revoked by the entity that owns the | ||||
| resource. (See: access control list, DAC, identity-based security | ||||
| policy, mandatory access control.) | ||||
| Derivation: This service is termed "discretionary" because an | Derivation: This service is termed "discretionary" because an | |||
| entity can be granted access rights to a resource such that the | entity can be granted access rights to a resource such that the | |||
| entity can by its own volition enable other entities to access the | entity can by its own volition enable other entities to access the | |||
| resource. That is, the service can incorporate a concept of | resource. | |||
| ownership in which access rights can be granted and revoked by the | ||||
| user that owns the resource. | ||||
| 1b. (O) /formal model/ "A means of restricting access to objects | 1b. (O) /formal model/ "A means of restricting access to objects | |||
| based on the identity of subjects and/or groups to which they | based on the identity of subjects and/or groups to which they | |||
| belong. The controls are discretionary in the sense that a subject | belong. The controls are discretionary in the sense that a subject | |||
| with a certain access permission is capable of passing that | with a certain access permission is capable of passing that | |||
| permission (perhaps indirectly) on to any other subject." [DoD1] | permission (perhaps indirectly) on to any other subject." [DoD1] | |||
| $ DISN | $ DISN | |||
| (O) See: Defense Information Systems Network (DISN). | (O) See: Defense Information Systems Network (DISN). | |||
| $ disruption | $ disruption | |||
| (I) A circumstance or event that interrupts or prevents the | (I) A circumstance or event that interrupts or prevents the | |||
| correct operation of system services and functions. (See: | correct operation of system services and functions. (See: | |||
| availability, critical, system integrity.) | availability, critical, system integrity, threat consequence.) | |||
| Tutorial: Disruption is a type of threat consequence; it can be | Tutorial: Disruption is a type of threat consequence; it can be | |||
| caused by the following types of threat actions: incapacitation, | caused by the following types of threat actions: incapacitation, | |||
| corruption, and obstruction. | corruption, and obstruction. | |||
| $ Distinguished Encoding Rules (DER) | $ Distinguished Encoding Rules (DER) | |||
| (N) A subset of the Basic Encoding Rules, which gives exactly one | (N) A subset of the Basic Encoding Rules that always provides only | |||
| way to represent any ASN.1 value as an octet string [X690]. | one way to encode any data structure defined by ASN.1. [X690]. | |||
| Tutorial: There usually is more than one way to encode ASN.1 in | Tutorial: For a data structure defined abstractly in ASN.1, BER | |||
| BER. Therefore, DER is used in applications in which a unique | often provides for encoding the structure into an octet string in | |||
| more than one way, so that two separate BER implementations can | ||||
| legitimately produce different octet strings for the same ASN.1 | ||||
| definition. However, some applications require all encodings of a | ||||
| structure to be the same, so that encodings can be compared for | ||||
| equality. Therefore, DER is used in applications in which unique | ||||
| encoding is needed, such as when a digital signature is computed | encoding is needed, such as when a digital signature is computed | |||
| on an ASN.1 value. | on a structure defined by ASN.1. | |||
| $ distinguished name (DN) | $ distinguished name (DN) | |||
| (N) An identifier that uniquely represents an object in the X.500 | (N) An identifier that uniquely represents an object in the X.500 | |||
| Directory Information Tree (DIT) [X501]. (Compare: domain name, | Directory Information Tree (DIT) [X501]. (Compare: domain name, | |||
| identity.) | identity.) | |||
| Tutorial: A DN is a set of attribute values that identify the path | Tutorial: A DN is a set of attribute values that identify the path | |||
| leading from the base of the DIT to the object that is named. An | leading from the base of the DIT to the object that is named. An | |||
| X.509 public-key certificate or CRL contains a DN that identifies | X.509 public-key certificate or CRL contains a DN that identifies | |||
| its issuer, and an X.509 attribute certificate contains a DN or | its issuer, and an X.509 attribute certificate contains a DN or | |||
| skipping to change at page 90, line 35 ¶ | skipping to change at page 95, line 35 ¶ | |||
| $ DNS | $ DNS | |||
| (I) See: Domain Name System. | (I) See: Domain Name System. | |||
| $ doctrine | $ doctrine | |||
| See: security doctrine. | See: security doctrine. | |||
| $ DoD | $ DoD | |||
| (N) Department of Defense. | (N) Department of Defense. | |||
| Usage: To ensure international understanding, ISDs should use this | Usage: To avoid international misunderstanding, ISDs SHOULD use | |||
| abbreviation only with a national qualifier (e.g., U.S. DoD). | this abbreviation only with a national qualifier (e.g., U.S. DoD). | |||
| $ DOI | $ DOI | |||
| (I) See: Domain of Interpretation. | (I) See: Domain of Interpretation. | |||
| $ domain | $ domain | |||
| 1a. (I) /general security/ An environment or context that is | 1a. (I) /general security/ An environment or context that (a) | |||
| includes a set of system resources and a set of system entities | ||||
| that have the right to access the resources and (b) usually is | ||||
| defined by a security policy, security model, or security | defined by a security policy, security model, or security | |||
| architecture to include a set of system resources and a set of | architecture. (See: domain of interpretation, security perimeter. | |||
| system entities that have the right to access the resources. (See: | Compare: COI, enclave.) | |||
| domain of interpretation, security perimeter. Compare: COI, | ||||
| enclave.) | ||||
| Tutorial: A "controlled interface" or "guard" is required to | Tutorial: A "controlled interface" or "guard" is required to | |||
| transfer information between network domains that operate under | transfer information between network domains that operate under | |||
| different security policies. | different security policies. | |||
| 1b. (O) /security policy/ A set of users, their information | 1b. (O) /security policy/ A set of users, their information | |||
| objects, and a common security policy. [DGSA, SP33] | objects, and a common security policy. [DGSA, SP33] | |||
| 2. (N) /computer security/ A operating state or mode of a set of | ||||
| 1c. (O) /security policy/ A system or collection of systems that | ||||
| (a) belongs to a community of interest that implements a | ||||
| consistent security policy and (b) is administered by a single | ||||
| authority. | ||||
| 2. (O) /computer security/ A operating state or mode of a set of | ||||
| computer hardware. | computer hardware. | |||
| Tutorial: Most computers have at least two hardware operating | Tutorial: Most computers have at least two hardware operating | |||
| modes [Gass]: | modes [Gass]: | |||
| - "Privileged" mode: Also called "executive", "master", "system", | - "Privileged" mode: Also called "executive", "master", "system", | |||
| kernel", or "supervisor" mode. In this mode, software can | kernel", or "supervisor" mode. In this mode, software can | |||
| execute any machine instruction and access any machine storage. | execute all machine instructions and access all storage | |||
| - "Unprivileged" mode: Also called "user", "application", or | locations. | |||
| - "Unprivileged" mode: Also called "user", "application", or | ||||
| "problem" mode. In this mode, software is restricted to a | "problem" mode. In this mode, software is restricted to a | |||
| subset of the instructions and a subset of the storage. | subset of the instructions and a subset of the storage | |||
| locations. | ||||
| 3. (I) /Internet/ That part of the Internet domain name space tree | 3. (O) "A distinct scope within which certain common | |||
| (RFC 1034) that is at or below the name that specifies the domain. | characteristics are exhibited and common rules are observed." | |||
| A domain is a subdomain of another domain if it is contained | [CORBA] | |||
| within that domain. For example, D.C.B.A is a subdomain of C.B.A. | ||||
| (See: Domain Name System.) | ||||
| 4. (O) /MISSI/ The domain of a MISSI CA is the set of MISSI users | 4. (O) /MISSI/ The domain of a MISSI CA is the set of MISSI users | |||
| whose certificates are signed by the CA. | whose certificates are signed by the CA. | |||
| 5. (O) /OSI/ An administrative partition of a complex distributed | 5. (I) /Internet/ That part of the tree-structured name space of | |||
| OSI system. | the DNS that is at or below the name that specifies the domain. A | |||
| domain is a subdomain of another domain if it is contained within | ||||
| that domain. For example, D.C.B.A is a subdomain of C.B.A | ||||
| 6. (O) "A distinct scope within which certain common | 6. (O) /OSI/ An administrative partition of a complex distributed | |||
| characteristics are exhibited and common rules are observed." | OSI system. | |||
| [CORBA] | ||||
| $ domain name | $ domain name | |||
| (I) The style of identifier -- a sequence of case-insensitive | (I) The style of identifier that is defined for subtrees in the | |||
| ASCII labels separated by dots (e.g., "bbn.com") -- defined for | Internet DNS -- i.e., a sequence of case-insensitive ASCII labels | |||
| subtrees in the Internet DNS and used in other Internet | separated by dots (e.g., "bbn.com") -- and also is used in other | |||
| identifiers, like host names (e.g., "rosslyn.bbn.com"), mailbox | types of Internet identifiers, such as host names (e.g., | |||
| names (e.g., "rshirey@bbn.com."), and URLs (e.g., | "rosslyn.bbn.com"), mailbox names (e.g., "rshirey@bbn.com.") and | |||
| "http://www.rosslyn.bbn.com./foo"). (See: DN, domain.) | URLs (e.g., "http://www.rosslyn.bbn.com./foo"). (See: DN, domain.) | |||
| Tutorial: The name space of the DNS (RFC 1591) is a tree structure | Tutorial: The name space of the DNS is a tree structure in which | |||
| in which each node and leaf holds records describing a resource. | each node and leaf holds records describing a resource. Each node | |||
| Each node has a label. The domain name of a node is the list of | has a label. The domain name of a node is the list of labels on | |||
| labels on the path from the node to the root of the tree. The | the path from the node to the root of the tree. The labels in a | |||
| labels in a domain name are printed or read left to right, from | domain name are printed or read left to right, from the most | |||
| the most specific (lowest, farthest from the root) to the least | specific (lowest, farthest from the root) to the least specific | |||
| specific (highest, closest to the root), but the root's label is | (highest, closest to the root), but the root's label is the null | |||
| the null string. (See: country code.) | string. (See: country code.) | |||
| $ Domain Name System (DNS) | $ Domain Name System (DNS) | |||
| (I) The main Internet operations database, which is distributed | (I) The main Internet operations database, which is distributed | |||
| over a collection of servers and used by client software for | over a collection of servers and used by client software for | |||
| purposes such as translating a domain name-style host name into an | purposes such as (a) translating a domain name-style host name | |||
| IP address (e.g., "rosslyn.bbn.com" is "192.1.7.10") and locating | into an IP address (e.g., "rosslyn.bbn.com" translates to | |||
| a host that accepts mail for some mailbox address. [R1034] | "192.1.7.10") and (b) locating a host that accepts mail for a | |||
| Tutorial: The DNS has three major components: (a) Domain name | given mailbox address. (RFC 1034) | |||
| space and resource records: Specifications for the tree-structured | ||||
| domain name space, and data associated with the names. (b) Name | ||||
| servers: Programs that hold information about a subset of the | ||||
| tree's structure and data holdings, and also hold pointers to | ||||
| other name servers that can provide information from any part of | ||||
| the tree. (c) Resolvers: Programs that extract information from | ||||
| name servers in response to client requests; typically, system | ||||
| routines directly accessible to user programs. | ||||
| Extensions to the DNS [R2065, R2137, R2536] support (a) key | Tutorial: The DNS has three major components: | |||
| - Domain name space and resource records: Specifications for the | ||||
| tree-structured domain name space, and data associated with the | ||||
| names. | ||||
| - Name servers: Programs that hold information about a subset of | ||||
| the tree's structure and data holdings, and also hold pointers | ||||
| to other name servers that can provide information from any | ||||
| part of the tree. | ||||
| - Resolvers: Programs that extract information from name servers | ||||
| in response to client requests; typically, system routines | ||||
| directly accessible to user programs. | ||||
| Extensions to the DNS [R2535, R2536, R3007] support (a) key | ||||
| distribution for public keys needed for the DNS and for other | distribution for public keys needed for the DNS and for other | |||
| protocols, (b) data origin authentication service and data | protocols, (b) data origin authentication service and data | |||
| integrity service for resource records, (c) data origin | integrity service for resource records, (c) data origin | |||
| authentication service for transactions between resolvers and | authentication service for transactions between resolvers and | |||
| servers, and (d) access control of records. | servers, and (d) access control of records. | |||
| $ domain of interpretation (DOI) | $ domain of interpretation (DOI) | |||
| (I) /IPsec/ An ISAKMP/IKE DOI defines payload formats, exchange | (I) /IPsec/ An DOI for ISAKMP or IKE defines payload formats, | |||
| types, and conventions for naming security-relevant information | exchange types, and conventions for naming security-relevant | |||
| such as security policies or cryptographic algorithms and modes. | information such as security policies or cryptographic algorithms | |||
| Example: See [R2407]. | and modes. Example: See [R2407]. | |||
| Derivation: The DOI concept is based on work by the TSIG's CIPSO | Derivation: The DOI concept is based on work by the TSIG's CIPSO | |||
| Working Group. | Working Group. | |||
| $ dominate | $ dominate | |||
| (I) Security level A is said to "dominate" security level B if the | (I) Security level A is said to "dominate" security level B if the | |||
| hierarchical classification level of A is greater (higher) than or | (hierarchical) classification level of A is greater (higher) than | |||
| equal to that of B and the nonhierarchical categories of A include | or equal to that of B, and A's (nonhierarchical) categories | |||
| all of those of B. (See: lattice, lattice model.) | include all of B's categories. (See: lattice, lattice model.) | |||
| $ dongle | $ dongle | |||
| (I) A portable, physical, usually electronic device that is | (I) A portable, physical, usually electronic device that is | |||
| required to be attached to a computer to enable a particular | required to be attached to a computer to enable a particular | |||
| software program to run. (See: token.) | software program to run. (See: token.) | |||
| Tutorial: A dongle is essentially a physical key used for copy | Tutorial: A dongle is essentially a physical key used for copy | |||
| protection of software, because the program will not run unless | protection of software; that is, the program will not run unless | |||
| the matching dongle is attached. When the software runs, it | the matching dongle is attached. When the software runs, it | |||
| periodically queries the dongle and quits if the dongle does not | periodically queries the dongle and quits if the dongle does not | |||
| reply with the proper authentication information. Dongles were | reply with the proper authentication information. Dongles were | |||
| originally constructed as an EPROM (erasable programmable read- | originally constructed as an EPROM (erasable programmable read- | |||
| only memory) to be connected to a serial input-output port of a | only memory) to be connected to a serial input-output port of a | |||
| personal computer. | personal computer. | |||
| $ downgrade | $ downgrade | |||
| (I) /data security/ Reduce the classification level of data | (I) /data security/ Reduce the security level of data (especially | |||
| without changing the information content of the data. (Compare: | the classification level) without changing the information content | |||
| upgrade. See: regrade.) | of the data. (See: regrade, upgrade. Compare: declassify.) | |||
| $ draft RFC | $ draft RFC | |||
| Deprecated Term: ISDs SHOULD NOT use this term; the Request for | (D) A preliminary, temporary version of a document that is | |||
| Comment series is archival in nature and does not have a "draft" | intended to become an RFC. | |||
| category. (See: Internet Draft, (Draft Standard under) Internet | ||||
| Standard).) | Deprecated Term: ISDs SHOULD NOT use this term. The RFC series is | |||
| archival in nature and consists only of documents in permanent | ||||
| form. A document that is intended to become an RFC usually needs | ||||
| to be published first as an "Internet-Draft" (RFC 2026). (See: | ||||
| "Draft Standard" under "Internet Standard".) | ||||
| $ Draft Standard | $ Draft Standard | |||
| (I) See: (secondary definition under) Internet Standard. | (I) See: secondary definition under "Internet Standard". | |||
| $ DSA | $ DSA | |||
| (N) See: Digital Signature Algorithm. | (N) See: Digital Signature Algorithm. | |||
| $ DSS | $ DSS | |||
| (N) See: Digital Signature Standard. | (N) See: Digital Signature Standard. | |||
| $ dual control | $ dual control | |||
| (I) A procedure that uses two or more entities (usually persons) | (I) A procedure that uses two or more entities (usually persons) | |||
| operating in concert to protect a system resource, such that no | operating in concert to protect a system resource, such that no | |||
| single entity acting alone can access that resource. (See: no-lone | single entity acting alone can access that resource. (See: no-lone | |||
| zone, separation of duties, split knowledge.) | zone, separation of duties, split knowledge.) | |||
| $ dual signature | $ dual signature | |||
| (O) /SET/ A single digital signature that protects two separate | (O) /SET/ A single digital signature that protects two separate | |||
| messages by including the hash results for both sets in a single | messages by including the hash results for both sets in a single | |||
| encrypted value. [SET2] | encrypted value. [SET2] | |||
| Deprecated Term: ISDs SHOULD NOT use this term except when | Deprecated Usage: ISDs SHOULD NOT use this term except when | |||
| qualified as "SET(trademark) dual signature" with this definition. | qualified as "SET(trademark) dual signature" with this definition. | |||
| Tutorial: Generated by hashing each message separately, | Tutorial: Generated by hashing each message separately, | |||
| concatenating the two hash results, and then hashing that value | concatenating the two hash results, and then hashing that value | |||
| and encrypting the result with the signer's private key. Done to | and encrypting the result with the signer's private key. Done to | |||
| reduce the number of encryption operations and to enable | reduce the number of encryption operations and to enable | |||
| verification of data integrity without complete disclosure of the | verification of data integrity without complete disclosure of the | |||
| data. | data. | |||
| $ dual-use certificate | $ dual-use certificate | |||
| (I) A certificate that is intended for use with both digital | (O) A certificate that is intended for use with both digital | |||
| signature and data encryption services. [SP32] | signature and data encryption services. [SP32] | |||
| Usage: An ISD that uses the term SHOULD state a definition by | Usage: ISDs that use this term SHOULD state a definition for it by | |||
| identifying the intended uses of the certificate, because there | identifying the intended uses of the certificate, because there | |||
| are more than just these two. A v3 X.509 public-key certificate | are more than just these two uses mentioned in the NIST | |||
| may have a "key Usage" extension, which indicates the purposes for | publication. A v3 X.509 public-key certificate may have a "key | |||
| which the public key may be used. (See: certificate profile.) | Usage" extension, which indicates the purposes for which the | |||
| public key may be used. (See: certificate profile.) | ||||
| $ duty | $ duty | |||
| (I) An attribute of a role that obligates an entity playing the | (I) An attribute of a role that obligates an entity playing the | |||
| role to perform one or more tasks, which usually are essential for | role to perform one or more tasks, which usually are essential for | |||
| the functioning of the system. [Sand] (Compare authorization, | the functioning of the system. [Sand] (Compare authorization, | |||
| privilege. See: role, billet.) | privilege. See: role, billet.) | |||
| $ e-cash | $ e-cash | |||
| (D) Electronic cash; money that is in the form of data and can be | (O) Electronic cash; money that is in the form of data and can be | |||
| used as a payment mechanism on the Internet. | used as a payment mechanism on the Internet. | |||
| Deprecated Usage: Many different types of electronic cash have | Deprecated Usage: ISDs that use this term SHOULD state a | |||
| been devised, using a variety of security mechanisms; therefore, | definition for it because many different types of electronic cash | |||
| ISDs that use the term SHOULD state a definition for it. | have been devised with a variety of security mechanisms. | |||
| $ EAP | $ EAP | |||
| (I) See: Extensible Authentication Protocol. | (I) See: Extensible Authentication Protocol. | |||
| $ EAL | $ EAL | |||
| (O) See: evaluation assurance level. | (O) See: evaluation assurance level. | |||
| $ Easter egg | $ Easter egg | |||
| (D) "Hidden functionality within an application program, which | (D) "Hidden functionality within an application program, which | |||
| becomes activated when an undocumented, and often convoluted, set | becomes activated when an undocumented, and often convoluted, set | |||
| of commands and keystrokes is entered. Easter eggs are typically | of commands and keystrokes is entered. Easter eggs are typically | |||
| used to display the credits for the development team and [are] | used to display the credits for the development team and [are] | |||
| intended to be non-threatening" [SP28], but Easter eggs have the | intended to be non-threatening" [SP28], but Easter eggs have the | |||
| potential to contain malicious code. | potential to contain malicious code. | |||
| Deprecated Usage: It is likely that other cultures have different | Deprecated Usage: It is likely that other cultures use different | |||
| metaphors for this concept. Therefore, to ensure international | metaphors for this concept. Therefore, to avoid international | |||
| understanding, ISDs SHOULD NOT use this term. (See: (Deprecated | misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated | |||
| Usage under) Green Book.) | Usage under "Green Book".) | |||
| $ eavesdropping | $ eavesdropping | |||
| (I) Passive wiretapping done secretly, i.e., without the knowledge | (I) Passive wiretapping done secretly, i.e., without the knowledge | |||
| of the originator or the intended recipients of the communication. | of the originator or the intended recipients of the communication. | |||
| $ ECB | $ ECB | |||
| (N) See: electronic codebook. | (N) See: electronic codebook. | |||
| $ ECDSA | $ ECDSA | |||
| (N) See: Elliptic Curve Digital Signature Algorithm. | (N) See: Elliptic Curve Digital Signature Algorithm. | |||
| skipping to change at page 94, line 45 ¶ | skipping to change at page 100, line 4 ¶ | |||
| $ ECB | $ ECB | |||
| (N) See: electronic codebook. | (N) See: electronic codebook. | |||
| $ ECDSA | $ ECDSA | |||
| (N) See: Elliptic Curve Digital Signature Algorithm. | (N) See: Elliptic Curve Digital Signature Algorithm. | |||
| $ economy of alternatives | $ economy of alternatives | |||
| (I) The principle that a security mechanism should be designed to | (I) The principle that a security mechanism should be designed to | |||
| minimize the number of alternative ways of achieving a service. | minimize the number of alternative ways of achieving a service. | |||
| (Compare: economy of mechanism.) | (Compare: economy of mechanism.) | |||
| $ economy of mechanism | $ economy of mechanism | |||
| (I) The principle that a security mechanism should be designed to | (I) The principle that a security mechanism should be designed to | |||
| be as simple as possible, so that (a) the mechanism can be | be as simple as possible, so that (a) the mechanism can be | |||
| correctly implemented and (b) it can be verified that the | correctly implemented and (b) it can be verified that the | |||
| operation of the mechanism enforces the system's security policy. | operation of the mechanism enforces the system's security policy. | |||
| (Compare: economy of alternatives, least privilege.) | (Compare: economy of alternatives, least privilege.) | |||
| $ ECU | $ ECU | |||
| (N) See: end cryptographic unit. | (N) See: end cryptographic unit. | |||
| $ EDI | $ EDI | |||
| (I) See: electronic data interchange. | (I) See: electronic data interchange. | |||
| $ EDIFACT | $ EDIFACT | |||
| (N) See: (secondary definition under) electronic data interchange. | (N) See: secondary definition under "electronic data interchange". | |||
| $ EE | $ EE | |||
| Deprecated Term: ISDs SHOULD NOT use this abbreviation; there | (D) Abbreviation of "end entity" and other terms. | |||
| could be confusion among "end entity", "end-to-end encryption", | ||||
| "escrowed encryption standard", and other terms. | Deprecated Abbreviation: ISDs SHOULD NOT use this abbreviation; | |||
| there could be confusion among "end entity", "end-to-end | ||||
| encryption", "escrowed encryption standard", and other terms. | ||||
| $ EES | $ EES | |||
| (O) See: Escrowed Encryption Standard. | (O) See: Escrowed Encryption Standard. | |||
| $ effective key length | $ effective key length | |||
| (O) "A measure of strength of a cryptographic algorithm, | (O) "A measure of strength of a cryptographic algorithm, | |||
| regardless of actual key length." [IATF] | regardless of actual key length." [IATF] | |||
| $ effectiveness | $ effectiveness | |||
| (O) /ITSEC/ A property of a TOE representing how well it provides | (O) /ITSEC/ A property of a TOE representing how well it provides | |||
| skipping to change at page 95, line 36 ¶ | skipping to change at page 100, line 50 ¶ | |||
| $ El Gamal algorithm | $ El Gamal algorithm | |||
| (N) An algorithm for asymmetric cryptography, invented in 1985 by | (N) An algorithm for asymmetric cryptography, invented in 1985 by | |||
| Taher El Gamal, that is based on the difficulty of calculating | Taher El Gamal, that is based on the difficulty of calculating | |||
| discrete logarithms and can be used for both encryption and | discrete logarithms and can be used for both encryption and | |||
| digital signatures. | digital signatures. | |||
| $ electronic codebook (ECB) | $ electronic codebook (ECB) | |||
| (N) An block cipher mode in which a plaintext block is used | (N) An block cipher mode in which a plaintext block is used | |||
| directly as input to the encryption algorithm and the resultant | directly as input to the encryption algorithm and the resultant | |||
| output block is used directly as cipher text [FP081]. | output block is used directly as cipher text [FP081]. (See: block | |||
| cipher.) | ||||
| $ electronic commerce | $ electronic commerce | |||
| 1. (I) Business conducted through paperless exchanges of | 1. (I) Business conducted through paperless exchanges of | |||
| information, using electronic data interchange, electronic funds | information, using electronic data interchange, electronic funds | |||
| transfer (EFT), electronic mail, computer bulletin boards, | transfer (EFT), electronic mail, computer bulletin boards, | |||
| facsimile, and other paperless technologies. | facsimile, and other paperless technologies. | |||
| 2. (O) /SET/ "The exchange of goods and services for payment | 2. (O) /SET/ "The exchange of goods and services for payment | |||
| between the cardholder and merchant when some or all of the | between the cardholder and merchant when some or all of the | |||
| transaction is performed via electronic communication." [SET2] | transaction is performed via electronic communication." [SET2] | |||
| skipping to change at page 96, line 13 ¶ | skipping to change at page 101, line 28 ¶ | |||
| create a single, global EDI standard. | create a single, global EDI standard. | |||
| $ Electronic Key Management System (EKMS) | $ Electronic Key Management System (EKMS) | |||
| (O) "Interoperable collection of systems developed by ... the U.S. | (O) "Interoperable collection of systems developed by ... the U.S. | |||
| Government to automate the planning, ordering, generating, | Government to automate the planning, ordering, generating, | |||
| distributing, storing, filling, using, and destroying of | distributing, storing, filling, using, and destroying of | |||
| electronic keying material and the management of other types of | electronic keying material and the management of other types of | |||
| COMSEC material." [C4009] | COMSEC material." [C4009] | |||
| $ electronic signature | $ electronic signature | |||
| (D) Synonym for "digital signature" or "digitized signature". | ||||
| Deprecated Term: ISDs SHOULD NOT use this term; there is no | Deprecated Term: ISDs SHOULD NOT use this term; there is no | |||
| current consensus on its definition. Instead, use "digital | current consensus on its definition. Instead, use "digital | |||
| signature", if that is what was intended. (See: digitized | signature", if that is what was intended | |||
| signature.) | ||||
| $ electronic wallet | $ electronic wallet | |||
| Deprecated Term: ISDs SHOULD NOT use this term; there is no | (D) A secure container to hold, in digitized form, some sensitive | |||
| current consensus on its definition. Meanings range from "digital | data objects that belong to the owner, such as electronic money, | |||
| certificate" to "smartcard", and some uses and definitions may be | authentication material, and various types of personal | |||
| proprietary. (See: (Deprecated Usage under) Green Book.) | information. | |||
| Deprecated Term: ISDs SHOULD NOT use this term. There is no | ||||
| current consensus on its definition; and some uses and definitions | ||||
| may be proprietary. Meanings range from virtual wallets | ||||
| implemented by data structures to physical wallets implemented by | ||||
| cryptographic tokens. (See: Deprecated Usage under "Green Book".) | ||||
| $ elliptic curve cryptography (ECC) | $ elliptic curve cryptography (ECC) | |||
| (I) A type of asymmetric cryptography based on mathematics of | (I) A type of asymmetric cryptography based on mathematics of | |||
| groups that are defined by the points on a curve, where the curve | groups that are defined by the points on a curve, where the curve | |||
| is defined by a quadratic equation in a finite field. [Schn] | is defined by a quadratic equation in a finite field. [Schn] | |||
| Tutorial: The most efficient implementation of ECC is claimed to | Tutorial: The most efficient implementation of ECC is claimed to | |||
| be stronger per bit of key (against cryptanalysis that uses a | be stronger per bit of key (against cryptanalysis that uses a | |||
| brute force attack) than any other known form of asymmetric | brute force attack) than any other known form of asymmetric | |||
| cryptography. ECC is based on mathematics different than the kinds | cryptography. ECC is based on mathematics different than the kinds | |||
| skipping to change at page 96, line 52 ¶ | skipping to change at page 102, line 22 ¶ | |||
| $ emanation | $ emanation | |||
| (I) An signal (e.g., electromagnetic or acoustic) that is emitted | (I) An signal (e.g., electromagnetic or acoustic) that is emitted | |||
| by a system (e.g., through radiation or conductance) as a | by a system (e.g., through radiation or conductance) as a | |||
| consequence (i.e., byproduct) of the system's operation, and that | consequence (i.e., byproduct) of the system's operation, and that | |||
| may contain information. (See: emanations security.) | may contain information. (See: emanations security.) | |||
| $ emanations security (EMSEC) | $ emanations security (EMSEC) | |||
| (I) Physical security measures to protect against data compromise | (I) Physical security measures to protect against data compromise | |||
| that could occur because of emanations that might be received and | that could occur because of emanations that might be received and | |||
| read by an unauthorized party. (See: TEMPEST.) | read by an unauthorized party. (See: emanation, TEMPEST.) | |||
| Usage: Refers both to preventing or limiting emanations from a | Usage: Refers both to preventing or limiting emanations from a | |||
| system and to preventing or limiting the ability of unauthorized | system and to preventing or limiting the ability of unauthorized | |||
| parties to receive the emissions. | parties to receive the emissions. | |||
| $ embedded cryptography | $ embedded cryptography | |||
| (N) "Cryptography engineered into an equipment or system whose | (N) "Cryptography engineered into an equipment or system whose | |||
| basic function is not cryptographic." [C4009] | basic function is not cryptographic." [C4009] | |||
| $ emergency plan | $ emergency plan | |||
| (D) Synonym for "contingency plan". | (D) Synonym for "contingency plan". | |||
| Deprecated Term: ISDs SHOULD NOT use this term. Instead, for | Deprecated Term: ISDs SHOULD NOT use this term. Instead, for | |||
| neutrality and consistency of language, use "contingency plan". | neutrality and consistency of language, use "contingency plan". | |||
| $ emergency response | $ emergency response | |||
| (O) An urgent response to a fire, flood, civil commotion, natural | (O) An urgent response to a fire, flood, civil commotion, natural | |||
| disaster, bomb threat, or other serious situation, with the intent | disaster, bomb threat, or other serious situation, with the intent | |||
| of protecting lives, limiting damage to property, and minimizing | of protecting lives, limiting damage to property, and minimizing | |||
| disruption of system operations. [FP087] (See: availability, | disruption of system operations. [FP087] (See: availability, CERT, | |||
| CERT.) | emergency plan.) | |||
| $ EMSEC | $ EMSEC | |||
| (I) See: emanations security. | (I) See: emanations security. | |||
| $ EMV | $ EMV | |||
| (N) An abbreviation of "Europay, MasterCard, Visa". Refers to a | (N) Abbreviation of "Europay, MasterCard, Visa". Refers to a | |||
| specification for smart cards that are used as payment cards, and | specification for smart cards that are used as payment cards, and | |||
| for related terminals and applications. [EMV1, EMV2, EMV3] | for related terminals and applications. [EMV1, EMV2, EMV3] | |||
| $ Encapsulating Security Payload (ESP) | $ Encapsulating Security Payload (ESP) | |||
| (I) An Internet protocol [R2406] designed to provide data | (I) An Internet protocol [R2406] designed to provide data | |||
| confidentiality service and other security services for IP | confidentiality service and other security services for IP | |||
| datagrams. (See: IPsec. Compare: AH.) | datagrams. (See: IPsec. Compare: AH.) | |||
| Tutorial: ESP may be used alone, or in combination with AH, or in | Tutorial: ESP may be used alone, or in combination with AH, or in | |||
| a nested fashion with tunneling. Security services can be provided | a nested fashion with tunneling. Security services can be provided | |||
| skipping to change at page 97, line 53 ¶ | skipping to change at page 103, line 23 ¶ | |||
| data confidentiality service, data origin authentication service, | data confidentiality service, data origin authentication service, | |||
| connectionless data integrity service, an anti-replay service, and | connectionless data integrity service, an anti-replay service, and | |||
| limited traffic-flow confidentiality. The set of services depends | limited traffic-flow confidentiality. The set of services depends | |||
| on the placement of the implementation and on options selected | on the placement of the implementation and on options selected | |||
| when the security association is established. | when the security association is established. | |||
| $ encipher | $ encipher | |||
| (D) Synonym for "encrypt". | (D) Synonym for "encrypt". | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "encrypt". However, see usage note under "encryption". | for "encrypt". However, see Usage note under "encryption". | |||
| $ encipherment | $ encipherment | |||
| (D) Synonym for "encryption". | (D) Synonym for "encryption". | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "encryption". However, see usage note under "encryption". | for "encryption". However, see Usage note under "encryption". | |||
| $ enclave | $ enclave | |||
| 1. (I) A set of system resources that operate in the same security | 1. (I) A set of system resources that operate in the same security | |||
| domain and that share the protection of a common, continuous | domain and that share the protection of a common, continuous | |||
| security perimeter. (Compare: domain.) | security perimeter. (Compare: domain.) | |||
| 2. (O) /U.S. Government/ "Collection of computing environments | 2. (O) /U.S. Government/ "Collection of computing environments | |||
| connected by one or more internal networks under the control of a | connected by one or more internal networks under the control of a | |||
| single authority and security policy, including personnel and | single authority and security policy, including personnel and | |||
| physical security." [C4009] | physical security." [C4009] | |||
| skipping to change at page 98, line 37 ¶ | skipping to change at page 104, line 7 ¶ | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "encrypt"; encoding is not always meant to conceal meaning. | for "encrypt"; encoding is not always meant to conceal meaning. | |||
| $ encrypt | $ encrypt | |||
| (I) Cryptographically transform data to produce cipher text. (See: | (I) Cryptographically transform data to produce cipher text. (See: | |||
| encryption. Compare: seal.) | encryption. Compare: seal.) | |||
| $ encryption | $ encryption | |||
| 1. (I) Cryptographic transformation of data (called "plain text") | 1. (I) Cryptographic transformation of data (called "plain text") | |||
| into a form (called "cipher text") that conceals the data's | into a different form (called "cipher text") that conceals the | |||
| original meaning to prevent it from being known or used. If the | data's original meaning and prevents the original form from being | |||
| transformation is reversible, the corresponding reversal process | used. If the transformation is reversible, the corresponding | |||
| is called "decryption", which is a transformation that restores | reversal process is called "decryption", which is a transformation | |||
| encrypted data to its original state. (See: cryptography.) | that restores encrypted data to its original state. (See: | |||
| cryptography.) | ||||
| 2. (O) "The cryptographic transformation of data to produce | 2. (O) "The cryptographic transformation of data to produce | |||
| ciphertext." [I7498 Part 2] | ciphertext." [I7498 Part 2] | |||
| Usage: For this concept, ISDs SHOULD use the verb "to encrypt" | Usage: For this concept, ISDs SHOULD use the verb "to encrypt" | |||
| (and related variations: encryption, decrypt, and decryption). | (and related variations: encryption, decrypt, and decryption). | |||
| However, because of cultural biases involving human burial, some | However, because of cultural biases involving human burial, some | |||
| international documents (particularly ISO and CCITT standards) | international documents (particularly ISO and CCITT standards) | |||
| avoid "to encrypt" and instead use the verb "to encipher" (and | avoid "to encrypt" and instead use the verb "to encipher" (and | |||
| related variations: encipherment, decipher, decipherment). | related variations: encipherment, decipher, decipherment). | |||
| skipping to change at page 100, line 17 ¶ | skipping to change at page 105, line 40 ¶ | |||
| Tutorial: Whether a subject can play both CA and non-CA roles, | Tutorial: Whether a subject can play both CA and non-CA roles, | |||
| with either the same or different certificates, is a matter of | with either the same or different certificates, is a matter of | |||
| policy. (See: CPS.) A v3 X.509 public-key certificate may have a | policy. (See: CPS.) A v3 X.509 public-key certificate may have a | |||
| "basicConstraints" extension containing a "cA" value that | "basicConstraints" extension containing a "cA" value that | |||
| specifically "indicates whether or not the public key may be used | specifically "indicates whether or not the public key may be used | |||
| to verify certificate signatures". (See: certificate profile.) | to verify certificate signatures". (See: certificate profile.) | |||
| $ end system | $ end system | |||
| (N) /OSIRM/ A computer that implements all seven layers of the | (N) /OSIRM/ A computer that implements all seven layers of the | |||
| OSIRM and may attach to a subnetwork. Usage: In the IPS context, a | OSIRM and may attach to a subnetwork. Usage: In the IPS context, | |||
| end system is called a "host". | an end system is called a "host". | |||
| $ end-to-end encryption | $ end-to-end encryption | |||
| (I) Continuous protection of data that flows between two points in | (I) Continuous protection of data that flows between two points in | |||
| a network, effected by encrypting data when it leaves its source, | a network, effected by encrypting data when it leaves its source, | |||
| leaving it encrypted while it passes through any intermediate | keeping it encrypted while it passes through any intermediate | |||
| computers (such as routers), and decrypting only when the data | computers (such as routers), and decrypting it only when it | |||
| arrives at the intended final destination. (See: wiretapping. | arrives at the intended final destination. (See: wiretapping. | |||
| Compare: link encryption.) | Compare: link encryption.) | |||
| Examples: BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS, SILS. | Examples: BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS, SILS. | |||
| Tutorial: When two points are separated by multiple communication | Tutorial: When two points are separated by multiple communication | |||
| links that are connected by one or more intermediate relays, end- | links that are connected by one or more intermediate relays, end- | |||
| to-end encryption enables the source and destination systems to | to-end encryption enables the source and destination systems to | |||
| protect their communications without depending on the intermediate | protect their communications without depending on the intermediate | |||
| systems to provide the protection. | systems to provide the protection. | |||
| skipping to change at page 101, line 17 ¶ | skipping to change at page 106, line 39 ¶ | |||
| purpose of detecting attempted penetrations or confusing an | purpose of detecting attempted penetrations or confusing an | |||
| intruder about which flaws to exploit." [FP039] (See: honey pot.) | intruder about which flaws to exploit." [FP039] (See: honey pot.) | |||
| $ entropy | $ entropy | |||
| 1. (I) An information-theoretic measure (usually stated as a | 1. (I) An information-theoretic measure (usually stated as a | |||
| number of bits) of the amount of uncertainty that an attacker | number of bits) of the amount of uncertainty that an attacker | |||
| faces to determine the value of a secret. [SP63] (See: strength.) | faces to determine the value of a secret. [SP63] (See: strength.) | |||
| Example: If a password is said to contain at least 20 bits of | Example: If a password is said to contain at least 20 bits of | |||
| entropy, that means that it must be as hard to find the password | entropy, that means that it must be as hard to find the password | |||
| as to guess an 20-bit random number. | as to guess a 20-bit random number. | |||
| 2. (I) An information-theoretic measure (usually stated as a | 2. (I) An information-theoretic measure (usually stated as a | |||
| number of bits) of the amount of information in a message; i.e., | number of bits) of the amount of information in a message; i.e., | |||
| the minimum number of bits needed to encode all possible meanings | the minimum number of bits needed to encode all possible meanings | |||
| of that message. [Schn] (See: uncertainty.) | of that message. [Schn] (See: uncertainty.) | |||
| $ ephemeral | $ ephemeral | |||
| (I) /adjective/ Refers to a cryptographic key or other parameter | (I) /adjective/ Refers to a cryptographic key or other | |||
| that is short-lived, temporary, or used one time. (See: session | cryptographic parameter or data object that is short-lived, | |||
| key. Compare: static.) | temporary, or used one time. (See: session key. Compare: static.) | |||
| $ erase | $ erase | |||
| (I) Delete magnetically stored data in such a way that the data is | (I) Delete magnetically stored data in such a way that the data is | |||
| irretrievable by ordinary means, but might be recovered using | irretrievable by ordinary means, but might be recovered using | |||
| laboratory methods. [C4009] (Compare: purge.) | laboratory methods. [C4009] (Compare: purge.) | |||
| $ error detection code | $ error detection code | |||
| (I) A checksum designed to detect, but not correct, accidental | (I) A checksum designed to detect, but not correct, accidental | |||
| (i.e., unintentional) changes in data. | (i.e., unintentional) changes in data. | |||
| $ Escrowed Encryption Standard (EES) | $ Escrowed Encryption Standard (EES) | |||
| (N) A U.S. Government standard [FP185] that specifies use of a | (N) A U.S. Government standard [FP185] that specifies how to use a | |||
| symmetric encryption algorithm (SKIPJACK) and a Law Enforcement | symmetric encryption algorithm (SKIPJACK) and create a Law | |||
| Access Field (LEAF) creation method to implement part of a key | Enforcement Access Field (LEAF) for implementing part of a key | |||
| escrow system that provides for decryption of telecommunications | escrow system that enables decryption of telecommunications when | |||
| when interception is lawfully authorized. | interception is lawfully authorized. | |||
| Tutorial: Both SKIPJACK and the LEAF are intended for use in | Tutorial: Both SKIPJACK and the LEAF are intended for use in | |||
| equipment used to encrypt and decrypt unclassified, sensitive | equipment used to encrypt and decrypt sensitive, unclassified, | |||
| telecommunications data. | telecommunications data. | |||
| $ ESP | $ ESP | |||
| (I) See: Encapsulating Security Payload. | (I) See: Encapsulating Security Payload. | |||
| $ Estelle | $ Estelle | |||
| (N) A language (ISO 9074-1989) for formal specification of | (N) A language (ISO 9074-1989) for formal specification of | |||
| computer network protocols. | computer network protocols. | |||
| $ ETSI | $ ETSI | |||
| skipping to change at page 102, line 17 ¶ | skipping to change at page 107, line 39 ¶ | |||
| $ EUCI | $ EUCI | |||
| (O) See: endorsed-for-unclassified cryptographic item. | (O) See: endorsed-for-unclassified cryptographic item. | |||
| $ European Telecommunication Standards Institute (ETSI) | $ European Telecommunication Standards Institute (ETSI) | |||
| (N) An independent, non-profit organization, based in France, that | (N) An independent, non-profit organization, based in France, that | |||
| is officially recognized by the European Commission and | is officially recognized by the European Commission and | |||
| responsible for standardization of information and communication | responsible for standardization of information and communication | |||
| technologies within Europe. | technologies within Europe. | |||
| Tutorial: ETSI is the custodian of a number of security | Tutorial: ETSI maintains the standards for a number of security | |||
| algorithms, including encryption algorithms for mobile telephone | algorithms, including encryption algorithms for mobile telephone | |||
| systems in Europe. | systems in Europe. | |||
| $ evaluated products list, Evaluated Products List | $ evaluated products list, Evaluated Products List | |||
| 1. (I) /not capitalized/ A list of information system equipment | 1. (I) /not capitalized/ A list of information system equipment | |||
| items that have been evaluated against, and found to be compliant | items that have been evaluated against, and found to be compliant | |||
| with, a particular set of criteria. | with, a particular set of criteria. | |||
| 2. (N) /capitalized, U.S. Government/ The Evaluated Products List | 2. (N) /capitalized, U.S. Government/ The Evaluated Products List | |||
| (http://www.radium.ncsc.mil/tpep/epl/) contains items that have | (http://www.radium.ncsc.mil/tpep/epl/) contains items that have | |||
| skipping to change at page 102, line 50 ¶ | skipping to change at page 108, line 19 ¶ | |||
| certification.) | certification.) | |||
| $ evaluation assurance level (EAL) | $ evaluation assurance level (EAL) | |||
| (N) A predefined package of assurance components that represents a | (N) A predefined package of assurance components that represents a | |||
| point on the Common Criteria's scale for rating confidence in the | point on the Common Criteria's scale for rating confidence in the | |||
| security of information technology products and systems. | security of information technology products and systems. | |||
| Tutorial: The Common Criteria defines a scale of seven, | Tutorial: The Common Criteria defines a scale of seven, | |||
| hierarchically ordered EALs for rating a TOE. From highest to | hierarchically ordered EALs for rating a TOE. From highest to | |||
| lowest, they are as follows: | lowest, they are as follows: | |||
| - EAL7. Formally verified design and tested. | - EAL7. Formally verified design and tested. | |||
| - EAL6. Semiformally verified design and tested. | - EAL6. Semiformally verified design and tested. | |||
| - EAL5. Semiformally designed and tested. | - EAL5. Semiformally designed and tested. | |||
| - EAL4. Methodically designed, tested, and reviewed. | - EAL4. Methodically designed, tested, and reviewed. | |||
| - EAL3. Methodically tested and checked. | - EAL3. Methodically tested and checked. | |||
| - EAL2. Structurally tested. | - EAL2. Structurally tested. | |||
| - EAL1. Functionally tested. | - EAL1. Functionally tested. | |||
| An EAL is a consistent, baseline set of requirements. The increase | An EAL is a consistent, baseline set of requirements. The increase | |||
| in assurance from EAL to EAL is accomplished by substituting | in assurance from EAL to EAL is accomplished by substituting | |||
| higher assurance components (i.e. criteria of increasing rigor, | higher assurance components (i.e. criteria of increasing rigor, | |||
| scope, or depth) from seven assurance classes: (a) configuration | scope, or depth) from seven assurance classes: (a) configuration | |||
| management, (b) delivery and operation, (c) development, (d) | management, (b) delivery and operation, (c) development, (d) | |||
| guidance documents, (e) life cycle support, (f) tests, and (g) | guidance documents, (e) life cycle support, (f) tests, and (g) | |||
| vulnerability assessment. | vulnerability assessment. | |||
| The EALs were developed with the goal of preserving concepts of | The EALs were developed with the goal of preserving concepts of | |||
| skipping to change at page 103, line 30 ¶ | skipping to change at page 108, line 52 ¶ | |||
| $ expire | $ expire | |||
| (I) See: certificate expiration. | (I) See: certificate expiration. | |||
| $ exposure | $ exposure | |||
| (I) A type of threat action whereby sensitive data is directly | (I) A type of threat action whereby sensitive data is directly | |||
| released to an unauthorized entity. (See: unauthorized | released to an unauthorized entity. (See: unauthorized | |||
| disclosure.) | disclosure.) | |||
| Usage: This type includes the following subtypes: | Usage: This type includes the following subtypes: | |||
| - "Deliberate Exposure": Intentional release of sensitive data to | - "Deliberate Exposure": Intentional release of sensitive data to | |||
| an unauthorized entity. | an unauthorized entity. | |||
| - "Scavenging": Searching through data residue in a system to | - "Scavenging": Searching through data residue in a system to | |||
| gain unauthorized knowledge of sensitive data. | gain unauthorized knowledge of sensitive data. | |||
| - "Human error": In context of exposure, human action or inaction | ||||
| - "Human error": In context of exposure, human action or inaction | ||||
| that unintentionally results in an entity gaining unauthorized | that unintentionally results in an entity gaining unauthorized | |||
| knowledge of sensitive data. | knowledge of sensitive data. (Compare: corruption, | |||
| - "Hardware or software error": In context of exposure, system | incapacitation.) | |||
| - "Hardware or software error": In context of exposure, system | ||||
| failure that unintentionally results in an entity gaining | failure that unintentionally results in an entity gaining | |||
| unauthorized knowledge of sensitive data. | unauthorized knowledge of sensitive data. (Compare: corruption, | |||
| incapacitation.) | ||||
| $ Extended Security Option | $ Extended Security Option | |||
| (I) See: (secondary definition under) IPSO. | (I) See: secondary definition under "IPSO". | |||
| $ Extensible Authentication Protocol (EAP) | $ Extensible Authentication Protocol (EAP) | |||
| (I) A extension framework for PPP that supports multiple, optional | (I) A extension framework for PPP that supports multiple, optional | |||
| authentication mechanisms, including cleartext passwords, | authentication mechanisms, including cleartext passwords, | |||
| challenge-response, and arbitrary dialog sequences. [R3748] | challenge-response, and arbitrary dialog sequences. [R3748] | |||
| Tutorial: This protocol is intended for use primarily by a host or | Tutorial: This protocol is intended for use primarily by a host or | |||
| router that connects to a network server via switched circuits or | router that connects to a network server via switched circuits or | |||
| dial-up lines. EAP typically runs directly over IPS data link | dial-up lines. EAP typically runs directly over IPS data link | |||
| protocols or OSIRM layer 2 protocols, such as PPP or IEEE 802, | protocols or OSIRM Layer 2 protocols, such as PPP or IEEE 802, | |||
| without requiring IP. | without requiring IP. | |||
| $ Extensible Markup Language (XML) | $ Extensible Markup Language (XML) | |||
| (N) A version of Standard Generalized Markup Language (ISO 8879), | (N) A version of Standard Generalized Markup Language (ISO 8879), | |||
| which separately represents both a document's content and its | which separately represents both a document's content and its | |||
| structure. XML was designed by W3C for use on the World Wide Web. | structure. XML was designed by W3C for use on the World Wide Web. | |||
| $ extension | $ extension | |||
| (I) A data item defined for optional inclusion in a v3 X.509 | (I) A data item defined for optional inclusion in a v3 X.509 | |||
| public-key certificate or a v2 X.509 CRL. | public-key certificate or a v2 X.509 CRL. | |||
| Tutorial: The formats defined in X.509 can be extended to provide | Tutorial: The formats defined in X.509 can be extended to provide | |||
| methods for associating additional attributes with subjects and | methods for associating additional attributes with subjects and | |||
| public keys and for managing a certification hierarchy: | public keys and for managing a certification hierarchy: | |||
| - "Certificate extension": X.509 defines standard extensions that | - A "certificate extension": X.509 defines standard extensions | |||
| may be included in v3 certificates to provide additional key | that may be included in v3 certificates to provide additional | |||
| and security policy information, subject and issuer attributes, | key and security policy information, subject and issuer | |||
| and certification path constraints. | attributes, and certification path constraints. | |||
| - "CRL extension": X.509 defines extensions that may be included | - A "CRL extension": X.509 defines extensions that may be | |||
| in v2 CRLs to provide additional issuer key and name | included in v2 CRLs to provide additional issuer key and name | |||
| information, revocation reasons and constraints, and | information, revocation reasons and constraints, and | |||
| information about distribution points and delta CRLs. | information about distribution points and delta CRLs. | |||
| - "Private extension": Additional extensions, each named by an | - A "private extension": Additional extensions, each named by an | |||
| OID, can be locally defined as needed by applications or | OID, can be locally defined as needed by applications or | |||
| communities. (See: PKIX private extension, SET private | communities. (See: Authority Information Access extension, SET | |||
| extensions.) | private extensions.) | |||
| $ external controls | $ external controls | |||
| (I) /computer security/ Refers to administrative security, | (I) /computer security/ Refers to administrative security, | |||
| personnel security, and physical security. (Compare: internal | personnel security, and physical security. (Compare: internal | |||
| controls.) | controls.) | |||
| $ extranet | $ extranet | |||
| (I) A computer network that an organization uses for application | (I) A computer network that an organization uses for application | |||
| data traffic between the organization and its business partners. | data traffic between the organization and its business partners. | |||
| (Compare: intranet.) | (Compare: intranet.) | |||
| Tutorial: An extranet can be implemented securely, either on the | Tutorial: An extranet can be implemented securely, either on the | |||
| Internet or using Internet technology, by constructing the | Internet or using Internet technology, by constructing the | |||
| extranet as a VPN. | extranet as a VPN. | |||
| $ extraction resistance | $ extraction resistance | |||
| (O) Capability of cryptographic equipment to resist efforts to | (O) Ability of cryptographic equipment to resist efforts to | |||
| extract keying material directly from the equipment (as opposed to | extract keying material directly from the equipment (as opposed to | |||
| gaining knowledge of keying material by cryptanalysis). [C4009] | gaining knowledge of keying material by cryptanalysis). [C4009] | |||
| $ fail safe | $ fail safe | |||
| (I) A mode of system termination that automatically leaves system | (I) A mode of termination of system functions (when a failure | |||
| processes and components in a secure state when a failure occurs | occurs or is detected in the system) that automatically leaves | |||
| or is detected in the system. | system processes and components in a secure state. | |||
| $ fail soft | $ fail soft | |||
| (I) Selective termination of affected non-essential system | (I) Selective termination of affected, non-essential system | |||
| functions and processes when a failure occurs or is detected in | functions when a failure occurs or is detected in the system. | |||
| the system. | ||||
| $ failure control | $ failure control | |||
| (I) A methodology used to provide fail-safe or fail-soft | (I) A methodology used to provide fail-safe or fail-soft | |||
| termination and recovery of functions and processes when failures | termination and recovery of system functions. [FP039] | |||
| occur or are detected in a system. [FP039] | ||||
| $ fairness | $ fairness | |||
| (I) A property of an access protocol for a system resource whereby | (I) A property of an access protocol for a system resource whereby | |||
| the resource is made equitably or impartially available to all | the resource is made equitably or impartially available to all | |||
| eligible users. [R3753] | eligible users. (RFC 3753) | |||
| Tutorial: Fairness can prevent flooding, but not jamming. | Tutorial: Fairness can be used to defend against some types of | |||
| denial-of-service attacks on a system connected to a network. | ||||
| However, this technique assumes that the system can properly | ||||
| receive and process inputs from the network. Therefore, the | ||||
| technique can mitigate flooding but is ineffective against | ||||
| jamming. | ||||
| $ falsification | $ falsification | |||
| (I) A type of threat action whereby false data deceives an | (I) A type of threat action whereby false data deceives an | |||
| authorized entity. (See: active wiretapping, deception.) | authorized entity. (See: active wiretapping, deception.) | |||
| Usage: This type includes the following subtypes: | Usage: This type includes the following subtypes: | |||
| - "Substitution": Altering or replacing valid data with false | - "Substitution": Altering or replacing valid data with false | |||
| data that serves to deceive an authorized entity. | data that serves to deceive an authorized entity. | |||
| - "Insertion": Introducing false data that serves to deceive an | - "Insertion": Introducing false data that serves to deceive an | |||
| authorized entity. | authorized entity. | |||
| $ fault tree | $ fault tree | |||
| (I) A branching, hierarchical data structure that is used to | (I) A branching, hierarchical data structure that is used to | |||
| represent events and to determine the various combinations of | represent events and to determine the various combinations of | |||
| component failures and human acts that could result in a specified | component failures and human acts that could result in a specified | |||
| undesirable system event. (See: attack tree, flaw hypothesis | undesirable system event. (See: attack tree, flaw hypothesis | |||
| methodology.) | methodology.) | |||
| Tutorial: "Fault-tree analysis" is a technique in which an | Tutorial: "Fault-tree analysis" is a technique in which an | |||
| skipping to change at page 106, line 28 ¶ | skipping to change at page 111, line 53 ¶ | |||
| (O) A PKI being planned to establish facilities, specifications, | (O) A PKI being planned to establish facilities, specifications, | |||
| and policies needed by the U.S. Government to use public-key | and policies needed by the U.S. Government to use public-key | |||
| certificates in systems involving unclassified but sensitive | certificates in systems involving unclassified but sensitive | |||
| applications and interactions between Federal agencies as well as | applications and interactions between Federal agencies as well as | |||
| with entities of other branches of the Federal Government, state, | with entities of other branches of the Federal Government, state, | |||
| and local governments, business, and the public. [FPKI] | and local governments, business, and the public. [FPKI] | |||
| $ Federal Standard 1027 | $ Federal Standard 1027 | |||
| (N) An U.S. Government document defining emanation, anti-tamper, | (N) An U.S. Government document defining emanation, anti-tamper, | |||
| security fault analysis, and manual key management criteria for | security fault analysis, and manual key management criteria for | |||
| DES encryption devices, primary for OSIRM layer 2. Was renamed | DES encryption devices, primary for OSIRM Layer 2. Was renamed | |||
| "FIPS PUB 140" when responsibility for protecting unclassified, | "FIPS PUB 140" when responsibility for protecting unclassified, | |||
| sensitive information was transferred from NSA to NIST, and has | sensitive information was transferred from NSA to NIST, and has | |||
| since been superseded by newer versions of that standard [FP140]. | since been superseded by newer versions of that standard [FP140]. | |||
| $ File Transfer Protocol (FTP) | $ File Transfer Protocol (FTP) | |||
| (I) A TCP-based, application-level, Internet Standard protocol | (I) A TCP-based, Application-Layer, Internet Standard protocol | |||
| (RFC 959) for moving data files from one computer to another. | (RFC 959) for moving data files from one computer to another. | |||
| $ fill device | $ fill device | |||
| (N) /COMSEC/ A device used to transfer or store keying material in | (N) /COMSEC/ A device used to transfer or store keying material in | |||
| electronic form or to insert keying material into cryptographic | electronic form or to insert keying material into cryptographic | |||
| equipment. | equipment. | |||
| $ filter | $ filter | |||
| (I) Synonym for "guard". (Compare: content filter, filtering | 1. (I) /noun/ Synonym for "guard". (Compare: content filter, | |||
| router.) | filtering router.) | |||
| 2. (I) /verb/ To process a flow of data and selectively block | ||||
| passage or permit passage of individual data items in accordance | ||||
| with a security policy. | ||||
| $ filtering router | $ filtering router | |||
| (I) An internetwork router that selectively prevents the passage | (I) An internetwork router that selectively prevents the passage | |||
| of data packets according to a security policy. (See: guard.) | of data packets according to a security policy. (See: guard.) | |||
| Tutorial: A router usually receives a packet from a network and | Tutorial: A router usually has two or more physical connections to | |||
| decides where to forward it on a second network. A filtering | networks or other systems; and when the router receives a packet | |||
| router does the same, but first decides whether the packet should | on one of those connections, it forwards the packet on a second | |||
| be forwarded at all, according to some security policy. The policy | connection. A filtering router does the same; but it first | |||
| is implemented by rules (packet filters) loaded into the router. | decides, according to some security policy, whether the packet | |||
| The rules mostly involve values of data packet control fields | should be forwarded at all. The policy is implemented by rules | |||
| (especially IP source and destination addresses and TCP port | (packet filters) loaded into the router. The rules mostly involve | |||
| numbers) [R2179]. A filtering router may be used as a firewall or | values of data packet control fields (especially IP source and | |||
| part of a firewall. | destination addresses and TCP port numbers) [R2179]. A filtering | |||
| router may be used alone as a simple firewall or be used as a | ||||
| component of a more complex firewall. | ||||
| $ financial institution | $ financial institution | |||
| (N) "An establishment responsible for facilitating customer- | (N) "An establishment responsible for facilitating customer- | |||
| initiated transactions or transmission of funds for the extension | initiated transactions or transmission of funds for the extension | |||
| of credit or the custody, loan, exchange, or issuance of money." | of credit or the custody, loan, exchange, or issuance of money." | |||
| [SET2] | [SET2] | |||
| $ fingerprint | $ fingerprint | |||
| 1. (I) A pattern of curves formed by the ridges on a fingertip. | 1. (I) A pattern of curves formed by the ridges on a fingertip. | |||
| (See: biometric authentication, thumbprint.) | (See: biometric authentication. Compare: thumbprint.) | |||
| 2. (O) PGP usage: A hash result used to authenticate a public key | 2. (D) /PGP/ A hash result ("key fingerprint") used to | |||
| (key fingerprint) or other data. [PGP] | authenticate a public key or other data. [PGP] | |||
| Deprecated Definition: ISDs SHOULD NOT use this term with the | Deprecated Definition: ISDs SHOULD NOT use this term with the | |||
| specific PGP definition, and SHOULD NOT use this term as a synonym | specific PGP definition, and SHOULD NOT use this term as a synonym | |||
| for "hash result" of *any* kind, because either use would mix | for "hash result" of *any* kind. Either use would mix concepts in | |||
| concepts in a potentially misleading way. | a potentially misleading way. | |||
| $ FIPS | $ FIPS | |||
| (N) See: Federal Information Processing Standards. | (N) See: Federal Information Processing Standards. | |||
| $ FIPS PUB 140-1 | $ FIPS PUB 140-1 | |||
| (N) The U.S. Government standard [FP140] for security requirements | (N) The U.S. Government standard [FP140] for security requirements | |||
| to be met by a cryptographic module used to protect unclassified | to be met by a cryptographic module when the module is used to | |||
| information in computer and communication systems. (See: Common | protect unclassified information in computer and communication | |||
| Criteria, FIPS, Federal Standard 1027.) | systems. (See: Common Criteria, FIPS, Federal Standard 1027.) | |||
| Tutorial: The standard specifies four increasing levels (from | Tutorial: The standard specifies four increasing levels (from | |||
| "Level 1" to "Level 4") of requirements to cover a wide range of | "Level 1" to "Level 4") of requirements to cover a wide range of | |||
| potential applications and environments. The requirements address | potential applications and environments. The requirements address | |||
| basic design and documentation, module interfaces, authorized | basic design and documentation, module interfaces, authorized | |||
| roles and services, physical security, software security, | roles and services, physical security, software security, | |||
| operating system security, key management, cryptographic | operating system security, key management, cryptographic | |||
| algorithms, electromagnetic interference and electromagnetic | algorithms, electromagnetic interference and electromagnetic | |||
| compatibility (EMI/EMC), and self-testing. NIST and the Canadian | compatibility (EMI/EMC), and self-testing. NIST and the Canadian | |||
| Communication Security Establishment jointly certify modules. | Communication Security Establishment jointly certify modules. | |||
| skipping to change at page 108, line 4 ¶ | skipping to change at page 113, line 35 ¶ | |||
| (O) /U.S. Government/ "Key management protocol based on public-key | (O) /U.S. Government/ "Key management protocol based on public-key | |||
| cryptography." [C4009] | cryptography." [C4009] | |||
| $ firewall | $ firewall | |||
| 1. (I) An internetwork gateway that restricts data communication | 1. (I) An internetwork gateway that restricts data communication | |||
| traffic to and from one of the connected networks (the one said to | traffic to and from one of the connected networks (the one said to | |||
| be "inside" the firewall) and thus protects that network's system | be "inside" the firewall) and thus protects that network's system | |||
| resources against threats from the other network (the one that is | resources against threats from the other network (the one that is | |||
| said to be "outside" the firewall). (See: guard, security | said to be "outside" the firewall). (See: guard, security | |||
| gateway.) | gateway.) | |||
| 2. (O) A device or system that controls the flow of traffic | 2. (O) A device or system that controls the flow of traffic | |||
| between networks using differing security postures. [SP41] | between networks using differing security postures. [SP41] | |||
| Tutorial: A firewall typically protects a smaller, secure network | Tutorial: A firewall typically protects a smaller, secure network | |||
| (such as a corporate LAN, or even just one host) from a larger | (such as a corporate LAN, or even just one host) from a larger | |||
| network (such as the Internet). The firewall is installed at the | network (such as the Internet). The firewall is installed at the | |||
| point where the networks connect, and the firewall applies | point where the networks connect, and the firewall applies policy | |||
| security policy rules to control traffic that flows in and out of | rules to control traffic that flows in and out of the protected | |||
| the protected network. | network. | |||
| A firewall is not always a single computer. For example, a | A firewall is not always a single computer. For example, a | |||
| firewall may consist of a pair of filtering routers and one or | firewall may consist of a pair of filtering routers and one or | |||
| more proxy servers running on one or more bastion hosts, all | more proxy servers running on one or more bastion hosts, all | |||
| connected to a small, dedicated LAN (see: DMZ) between the two | connected to a small, dedicated LAN (see: buffer zone) between the | |||
| routers. The external router blocks attacks that use IP to break | two routers. The external router blocks attacks that use IP to | |||
| security (IP address spoofing, source routing, packet fragments), | break security (IP address spoofing, source routing, packet | |||
| while proxy servers block attacks that would exploit a | fragments), while proxy servers block attacks that would exploit a | |||
| vulnerability in a higher layer protocol or service. The internal | vulnerability in a higher layer protocol or service. The internal | |||
| router blocks traffic from leaving the protected network except | router blocks traffic from leaving the protected network except | |||
| through the proxy servers. The difficult part is defining criteria | through the proxy servers. The difficult part is defining criteria | |||
| by which packets are denied passage through the firewall, because | by which packets are denied passage through the firewall, because | |||
| a firewall not only needs to keep intruders out, but usually also | a firewall not only needs to keep unauthorized traffic (i.e., | |||
| needs to let authorized users in and out. | intruders) out, but usually also needs to let authorized traffic | |||
| pass both in and out. | ||||
| $ firmware | $ firmware | |||
| (I) Computer programs and data stored in hardware -- typically in | (I) Computer programs and data stored in hardware -- typically in | |||
| read-only memory (ROM) or programmable read-only memory (PROM) -- | read-only memory (ROM) or programmable read-only memory (PROM) -- | |||
| such that the programs and data cannot be dynamically written or | such that the programs and data cannot be dynamically written or | |||
| modified during execution of the programs. (See: hardware, | modified during execution of the programs. (See: hardware, | |||
| software.) | software.) | |||
| $ FIRST | $ FIRST | |||
| (N) See: Forum of Incident Response and Security Teams. | (N) See: Forum of Incident Response and Security Teams. | |||
| skipping to change at page 108, line 51 ¶ | skipping to change at page 114, line 32 ¶ | |||
| result in a vulnerability. (Compare: vulnerability.) | result in a vulnerability. (Compare: vulnerability.) | |||
| $ flaw hypothesis methodology | $ flaw hypothesis methodology | |||
| (I) An evaluation or attack technique in which specifications and | (I) An evaluation or attack technique in which specifications and | |||
| documentation for a system are analyzed to hypothesize flaws in | documentation for a system are analyzed to hypothesize flaws in | |||
| the system. The list of hypothetical flaws is prioritized on the | the system. The list of hypothetical flaws is prioritized on the | |||
| basis of the estimated probability that a flaw exists and, | basis of the estimated probability that a flaw exists and, | |||
| assuming it does, on the ease of exploiting it and the extent of | assuming it does, on the ease of exploiting it and the extent of | |||
| control or compromise it would provide. The prioritized list is | control or compromise it would provide. The prioritized list is | |||
| used to direct a penetration test or attack against the system. | used to direct a penetration test or attack against the system. | |||
| [NCS04] (See: fault tree.) | [NCS04] (See: fault tree, flaw.) | |||
| $ flooding | $ flooding | |||
| 1. (I) An attack that attempts to cause a failure in a system by | 1. (I) An attack that attempts to cause a failure in a system by | |||
| providing more input than the system can process properly. (See: | providing more input than the system can process properly. (See: | |||
| denial of service, fairness. Compare: jamming.) | denial of service, fairness. Compare: jamming.) | |||
| Tutorial: Flooding uses "overload" as a type of "obstruction" | Tutorial: Flooding uses "overload" as a type of "obstruction" | |||
| intended to cause "disruption". | intended to cause "disruption". | |||
| 2. (I) The process of delivering data or control messages to every | 2. (I) The process of delivering data or control messages to every | |||
| node of a network. [R3753] | node of a network. (RFC 3753) | |||
| $ flow analysis | $ flow analysis | |||
| (I) An analysis performed on a nonprocedural formal system | (I) An analysis performed on a nonprocedural, formal, system | |||
| specification that locates potential flows of information between | specification that locates potential flows of information between | |||
| system variables. By assigning security levels to the variables, | system variables. By assigning security levels to the variables, | |||
| the analysis can find some types of covert channels. [Huff] | the analysis can find some types of covert channels. [Huff] | |||
| $ flow control | $ flow control | |||
| (I) A procedure or technique to ensure that information transfers | (I) A procedure or technique to ensure that information transfers | |||
| within a system are not made from one security level to another | within a system are not made from one security level to another | |||
| security level, and especially not from a higher level to a lower | security level, and especially not from a higher level to a lower | |||
| level. [Denns] (See: covert channel, confinement property, | level. [Denns] (See: covert channel, confinement property, | |||
| information flow policy, simple security property.) | information flow policy, simple security property.) | |||
| skipping to change at page 109, line 41 ¶ | skipping to change at page 115, line 21 ¶ | |||
| cause a foreseeable harm to an interest protected by one of the | cause a foreseeable harm to an interest protected by one of the | |||
| exemptions stated in the Freedom of Information Act (Section 552 | exemptions stated in the Freedom of Information Act (Section 552 | |||
| of title 5, United States Code). (See: security label, security | of title 5, United States Code). (See: security label, security | |||
| marking. Compare: classified.) | marking. Compare: classified.) | |||
| $ formal | $ formal | |||
| (I) Expressed in a restricted syntax language with defined | (I) Expressed in a restricted syntax language with defined | |||
| semantics based on well-established mathematical concepts. [CCIB] | semantics based on well-established mathematical concepts. [CCIB] | |||
| (Compare: informal, semiformal.) | (Compare: informal, semiformal.) | |||
| $ formal access approval | ||||
| (O) /U.S. Government/ Documented approval by a data owner to allow | ||||
| access to a particular category of information in a system. (See: | ||||
| category.) | ||||
| $ Formal Development Methodology | $ Formal Development Methodology | |||
| See: Ina Jo. | (O) See: Ina Jo. | |||
| $ formal model | $ formal model | |||
| (I) A security model that is formal. Example: Bell-LaPadula model. | (I) A security model that is formal. Example: Bell-LaPadula model. | |||
| (See: formal, security model.) [Land] | [Land] (See: formal, security model.) | |||
| $ formal proof | $ formal proof | |||
| (I) A complete and convincing mathematical argument presenting the | (I) A complete and convincing mathematical argument presenting the | |||
| full logical justification for each step in the proof of the truth | full logical justification for each step in the proof of the truth | |||
| of a theorem or set of theorems. | of a theorem or set of theorems. | |||
| $ formal specification | $ formal specification | |||
| (I) A specification of hardware or software functionality in a | (I) A specification of hardware or software functionality in a | |||
| computer-readable language; usually a precise mathematical | computer-readable language; usually a precise mathematical | |||
| description of the behavior of the system with the aim of | description of the behavior of the system with the aim of | |||
| providing a correctness proof. [Huff] (See: Affirm, Gypsy, HDM, | providing a correctness proof. [Huff] (See: Affirm, Gypsy, HDM, | |||
| Ina Jo.) | Ina Jo.) | |||
| $ formulary | $ formulary | |||
| (I) A technique for enabling a decision to grant or deny access to | (I) A technique for enabling a decision to grant or deny access to | |||
| be made dynamically at the time the access is attempted, rather | be made dynamically at the time the access is attempted, rather | |||
| than earlier when an access control list or ticket is created. | than earlier when an access control list or ticket is created. | |||
| $ FORTEZZA(trademark) | $ FORTEZZA(trademark) | |||
| (N) A registered trademark of NSA, used for a family of | (O) A registered trademark of NSA, used for a family of | |||
| interoperable security products that implement a NIST/NSA-approved | interoperable security products that implement a NIST/NSA-approved | |||
| suite of cryptographic algorithms for digital signature, hash, | suite of cryptographic algorithms for digital signature, hash, | |||
| encryption, and key exchange. The products include a PC card (that | encryption, and key exchange. The products include a PC card (that | |||
| contains a CAPSTONE chip), and compatible serial port modems, | contains a CAPSTONE chip), and compatible serial port modems, | |||
| server boards, and software implementations. | server boards, and software implementations. | |||
| $ Forum of Incident Response and Security Teams (FIRST) | $ Forum of Incident Response and Security Teams (FIRST) | |||
| (N) An international consortium of CSIRTs (e.g., CIAC) that work | (N) An international consortium of CSIRTs (e.g., CIAC) that work | |||
| together to handle computer security incidents and promote | together to handle computer security incidents and promote | |||
| preventive activities. (See: CSIRT, security incident.) | preventive activities. (See: CSIRT, security incident.) | |||
| Tutorial: FIRST was founded in 1990 and, as of July 2004, had more | Tutorial: FIRST was founded in 1990 and, as of July 2004, had more | |||
| than 100 members spanning the globe. Its mission includes: | than 100 members spanning the globe. Its mission includes: | |||
| - Provide members with technical information, tools, methods, | - Provide members with technical information, tools, methods, | |||
| assistance, and guidance. | assistance, and guidance. | |||
| - Coordinate proactive liaison activities and analytical support. | - Coordinate proactive liaison activities and analytical support. | |||
| - Encourage development of quality products and services. | - Encourage development of quality products and services. | |||
| - Improve national and international information security for | - Improve national and international information security for | |||
| government, private industry, academia, and the individual. | government, private industry, academia, and the individual. | |||
| - Enhance the image and status of the CSIRT community. | - Enhance the image and status of the CSIRT community. | |||
| $ forward secrecy | $ forward secrecy | |||
| See: public-key forward secrecy. | See: public-key forward secrecy. | |||
| $ FOUO | $ FOUO | |||
| (O) See: For Official Use Only. | (O) See: For Official Use Only. | |||
| $ FPKI | $ FPKI | |||
| (O) See: Federal Public-Key Infrastructure. | (O) See: Federal Public-Key Infrastructure. | |||
| skipping to change at page 111, line 8 ¶ | skipping to change at page 116, line 44 ¶ | |||
| Tutorial: Frequency hopping is a TRANSEC technique to minimize the | Tutorial: Frequency hopping is a TRANSEC technique to minimize the | |||
| potential for unauthorized interception or jamming. | potential for unauthorized interception or jamming. | |||
| $ FTP | $ FTP | |||
| (I) See: File Transfer Protocol. | (I) See: File Transfer Protocol. | |||
| $ gateway | $ gateway | |||
| (I) An intermediate system (interface, relay) that attaches to two | (I) An intermediate system (interface, relay) that attaches to two | |||
| (or more) computer networks that have similar functions but | (or more) computer networks that have similar functions but | |||
| dissimilar implementations and that enables inter-network | dissimilar implementations and that enables either one-way or two- | |||
| communication. (See: bridge, firewall, guard, internetwork, proxy | way communication between the networks. (See: bridge, firewall, | |||
| server, router, and subnetwork.) | guard, internetwork, proxy server, router, and subnetwork.) | |||
| Tutorial: The networks may differ in any of several aspects, | Tutorial: The networks may differ in any of several aspects, | |||
| including protocols and security mechanisms. When two computer | including protocols and security mechanisms. When two computer | |||
| networks differ in the protocol by which they offer service to | networks differ in the protocol by which they offer service to | |||
| hosts, a gateway may translate one protocol into the other or | hosts, a gateway may translate one protocol into the other or | |||
| otherwise facilitate interoperation of hosts (see: Internet | otherwise facilitate interoperation of hosts (see: Internet | |||
| Protocol). In theory, gateways between computer networks are | Protocol). In theory, gateways between computer networks are | |||
| conceivable at any OSIRM layer. In practice, they usually operate | conceivable at any OSIRM layer. In practice, they usually operate | |||
| at OSIRM layer 2 (see: bridge), 3 (see: router), or 7 (see: proxy | at OSIRM Layer 2 (see: bridge), 3 (see: router), or 7 (see: proxy | |||
| server). | server). | |||
| $ GCA | $ GCA | |||
| (O) See: geopolitical certificate authority. | (O) See: geopolitical certificate authority. | |||
| $ GDOI | $ GDOI | |||
| (O) See: Group Domain of Interpretation. | (O) See: Group Domain of Interpretation. | |||
| $ GeldKarte | $ GeldKarte | |||
| (O) A smartcard-based electronic money system that is maintained | (O) A smartcard-based, electronic money system that is maintained | |||
| by the German banking industry, incorporates cryptography, and can | by the German banking industry, incorporates cryptography, and can | |||
| be used to make payments via the Internet. (See: IOTP.) | be used to make payments via the Internet. (See: IOTP.) | |||
| $ GeneralizedTime | $ GeneralizedTime | |||
| (N) The ASN.1 data type "GeneralizedTime" (ISO 8601) contains a | (N) The ASN.1 data type "GeneralizedTime" (ISO 8601) contains a | |||
| calendar date (YYYYMMDD) and a time of day, which is either (a) | calendar date (YYYYMMDD) and a time of day, which is either (a) | |||
| the local time, (b) the Coordinated Universal Time, or (c) both | the local time, (b) the Coordinated Universal Time, or (c) both | |||
| the local time and an offset allowing Coordinated Universal Time | the local time and an offset that enables Coordinated Universal | |||
| to be calculated. (See: Coordinated Universal Time, UTCTime.) | Time to be calculated. (See: Coordinated Universal Time, UTCTime.) | |||
| $ Generic Security Service Application Program Interface (GSS-API) | $ Generic Security Service Application Program Interface (GSS-API) | |||
| (I) An Internet Standard protocol [R2078] that specifies calling | (I) An Internet Standard protocol [R2078] that specifies calling | |||
| conventions by which an application (typically another | conventions by which an application (typically another | |||
| communication protocol) can obtain authentication, integrity, and | communication protocol) can obtain authentication, integrity, and | |||
| confidentiality security services independently of the underlying | confidentiality security services independently of the underlying | |||
| security mechanisms and technologies, thus allowing the | security mechanisms and technologies, thus enabling the | |||
| application source code to be ported to different environments. | application source code to be ported to different environments. | |||
| Tutorial: "A GSS-API caller accepts tokens provided to it by its | Tutorial: "A GSS-API caller accepts tokens provided to it by its | |||
| local GSS-API implementation and transfers the tokens to a peer on | local GSS-API implementation and transfers the tokens to a peer on | |||
| a remote system; that peer passes the received tokens to its local | a remote system; that peer passes the received tokens to its local | |||
| GSS-API implementation for processing. The security services | GSS-API implementation for processing. The security services | |||
| available through GSS-API in this fashion are implementable (and | available through GSS-API in this fashion are implementable (and | |||
| have been implemented) over a range of underlying mechanisms based | have been implemented) over a range of underlying mechanisms based | |||
| on [symmetric] and [asymmetric cryptography]." [R2078] | on [symmetric] and [asymmetric cryptography]." [R2078] | |||
| skipping to change at page 112, line 21 ¶ | skipping to change at page 118, line 4 ¶ | |||
| between regions as needed. | between regions as needed. | |||
| $ GIG | $ GIG | |||
| (O) See: Global Information Grid. | (O) See: Global Information Grid. | |||
| $ Global Information Grid. | $ Global Information Grid. | |||
| (O) /U.S. DoD/ "A globally interconnected, end-to-end set of | (O) /U.S. DoD/ "A globally interconnected, end-to-end set of | |||
| information capabilities, associated processes and personnel for | information capabilities, associated processes and personnel for | |||
| collecting, processing, storing, disseminating, and managing | collecting, processing, storing, disseminating, and managing | |||
| information on demand to warfighters, policy makers, and support | information on demand to warfighters, policy makers, and support | |||
| personnel." [IATF] | personnel." [IATF] Usage: Formerly called the DII. | |||
| $ good engineering practice(s) | ||||
| (N) A term used to specify or characterize design, implementation, | ||||
| installation, or operating practices for an information system, | ||||
| when a more explicit specification is not possible. Generally | ||||
| understood to refer to the state of the engineering art for | ||||
| commercial systems that have problems and solutions equivalent to | ||||
| the system in question. | ||||
| $ granularity | $ granularity | |||
| 1. (N) "Relative fineness to which an access control mechanism can | 1. (N) "Relative fineness to which an access control mechanism can | |||
| be adjusted." [C4009] | be adjusted." [C4009] | |||
| 2. (O) "The size of the smallest protectable unit of information" | 2. (O) "The size of the smallest protectable unit of information" | |||
| in a trusted computer system. [Huff] | in a trusted computer system. [Huff] | |||
| $ Green Book | $ Green Book | |||
| (D) Synonym for "Defense Password Management Guideline" [CSC2]. | (D) /slang/ Synonym for "Defense Password Management Guideline" | |||
| [CSC2]. | ||||
| Deprecated Term: Except as an explanatory appositive, ISDs SHOULD | Deprecated Term: Except as an explanatory appositive, ISDs SHOULD | |||
| NOT use this term, regardless of the associated definition. | NOT use this term, regardless of the associated definition. | |||
| Instead, use the full proper name of the document or, in | Instead, use the full proper name of the document or, in | |||
| subsequent references, a conventional abbreviation. (See: Rainbow | subsequent references, a conventional abbreviation. (See: Rainbow | |||
| Series.) | Series.) | |||
| Deprecated Usage: To improve international comprehensibility of | Deprecated Usage: To improve international comprehensibility of | |||
| Internet Standards and the Internet Standards Process, ISDs SHOULD | Internet Standards and the Internet Standards Process, ISDs SHOULD | |||
| NOT use "cute" synonyms. No matter how clearly understood or | NOT use "cute" synonyms. No matter how clearly understood or | |||
| popular a nickname may be in one community, it is likely to cause | popular a nickname may be in one community, it is likely to cause | |||
| confusion or offense in others. For example, several other | confusion or offense in others. For example, several other | |||
| information system standards also are called "the Green Book". The | information system standards also are called "the Green Book"; the | |||
| following are examples: | following are some examples: | |||
| - Each volume of 1992 ITU-T (known at that time as CCITT) | - Each volume of 1992 ITU-T (known at that time as CCITT) | |||
| standards. | standards. | |||
| - "PostScript Language Program Design", Adobe Systems, Addison- | - "PostScript Language Program Design", Adobe Systems, Addison- | |||
| Wesley, 1988. | Wesley, 1988. | |||
| - IEEE 1003.1 POSIX Operating Systems Interface. | - IEEE 1003.1 POSIX Operating Systems Interface. | |||
| - "Smalltalk-80: Bits of History, Words of Advice", Glenn | - "Smalltalk-80: Bits of History, Words of Advice", Glenn | |||
| Krasner, Addison-Wesley, 1983. | Krasner, Addison-Wesley, 1983. | |||
| - "X/Open Compatibility Guide". | - "X/Open Compatibility Guide". | |||
| - A particular CD-ROM format developed by Phillips. | - A particular CD-ROM format developed by Phillips. | |||
| $ GRIP | $ GRIP | |||
| (I) A contraction of "Guidelines and Recommendations for Security | (I) A contraction of "Guidelines and Recommendations for Security | |||
| Incident Processing", the name of the IETF working group that | Incident Processing", the name of the IETF working group that | |||
| seeks to facilitate consistent handling of security incidents in | seeks to facilitate consistent handling of security incidents in | |||
| the Internet community. (See: security incident.) | the Internet community. (See: security incident.) | |||
| Tutorial: Guidelines to be produced by the WG will address | Tutorial: Guidelines to be produced by the WG will address | |||
| technology vendors, network service providers, and response teams | technology vendors, network service providers, and response teams | |||
| in their roles assisting organizations in resolving security | in their roles assisting organizations in resolving security | |||
| skipping to change at page 113, line 34 ¶ | skipping to change at page 119, line 25 ¶ | |||
| "group controller/key server", which establishes security | "group controller/key server", which establishes security | |||
| associations [R2401] among authorized group members. The GDOI | associations [R2401] among authorized group members. The GDOI | |||
| protocol is itself protected by an ISAKMP phase 1 association. | protocol is itself protected by an ISAKMP phase 1 association. | |||
| For example, multicast applications may use ESP to protect their | For example, multicast applications may use ESP to protect their | |||
| data traffic. GDOI carries the needed security association | data traffic. GDOI carries the needed security association | |||
| parameters for ESP. In this way, GDOI supports multicast ESP with | parameters for ESP. In this way, GDOI supports multicast ESP with | |||
| group authentication of ESP packets using a shared, group key. | group authentication of ESP packets using a shared, group key. | |||
| $ group identity | $ group identity | |||
| (I) See: (secondary definition under) identity. | (I) See: secondary definition under "identity". | |||
| $ group security association | $ group security association | |||
| (I) "A bundling of [security associations] (SAs) that together | (I) "A bundling of [security associations] (SAs) that together | |||
| define how a group communicates securely. The [group SA] may | define how a group communicates securely. The [group SA] may | |||
| include a registration protocol SA, a rekey protocol SA, and one | include a registration protocol SA, a rekey protocol SA, and one | |||
| or more data security protocol SAs." [R3740] | or more data security protocol SAs." [R3740] | |||
| $ GSS-API | $ GSS-API | |||
| (I) See: Generic Security Service Application Program Interface. | (I) See: Generic Security Service Application Program Interface. | |||
| $ guard | $ guard | |||
| (I) A computer system that acts as gateway between two information | (I) A computer system that (a) acts as gateway between two | |||
| systems operating under different security policies and is trusted | information systems operating under different security policies | |||
| to mediate information data transfers between the two systems. | and (b) is trusted to mediate information data transfers between | |||
| (See: controlled interface, domain.) | the two. (See: controlled interface, domain, filter. Compare: | |||
| firewall.) | ||||
| Usage: Frequently understood to mean that one system is operating | Usage: Frequently understood to mean that one system is operating | |||
| at a higher security level than the other, and that the gateway's | at a higher security level than the other, and that the gateway's | |||
| purpose is to prevent unauthorized disclosure of data from the | purpose is to prevent unauthorized disclosure of data from the | |||
| higher system to the lower. However, the purpose might also be to | higher system to the lower. However, the purpose might also be to | |||
| protect the data integrity, availability, or general system | protect the data integrity, availability, or general system | |||
| integrity of one system from threats posed by connecting to the | integrity of one system from threats posed by connecting to the | |||
| other system. The mediation may be entirely automated or may | other system. The mediation may be entirely automated or may | |||
| involve reliable human review. (See: filter, firewall.) | involve reliable human review. | |||
| $ guest login | $ guest login | |||
| (I) See: anonymous login. | (I) See: anonymous login. | |||
| $ GULS | $ GULS | |||
| (I) Generic Upper Layer Security service element (ISO 11586), a | (I) Generic Upper Layer Security service element (ISO 11586), a | |||
| five-part standard for the exchange of security information and | five-part standard for the exchange of security information and | |||
| security-transformation functions that protect confidentiality and | security-transformation functions that protect confidentiality and | |||
| integrity of application data. | integrity of application data. | |||
| $ Gypsy verification environment | $ Gypsy verification environment | |||
| (O) A methodology, language, and integrated set of software tools | (O) A methodology, language, and integrated set of software tools | |||
| developed at the University of Texas for specifying, coding, and | developed at the University of Texas for specifying, coding, and | |||
| verifying software to produce correct and reliable programs. | verifying software to produce correct and reliable programs. | |||
| [Cheh] | [Cheh] | |||
| $ H field | $ H field | |||
| (D) See: Handling Restrictions field. | (D) See: "Deprecated Usage" under "Handling Restrictions field". | |||
| $ hack | ||||
| 1a. (I) /verb/ To work on something, especially to program a | ||||
| computer. (See: hacker.) | ||||
| 1b. (I) /verb/ To do some kind of mischief, especially to play a | ||||
| prank on, or penetrate, a system. (See: hacker, cracker.) | ||||
| 2. (I) /noun/ An item of completed work or an instance of dealing | ||||
| with a problem, especially when that involves computer programming | ||||
| or other use of a computer. | ||||
| $ hacker | $ hacker | |||
| (I) Someone with a strong interest in computers, who enjoys | 1. (I) Someone with a strong interest in computers, who enjoys | |||
| learning about them and experimenting with them. (See: cracker.) | learning about them, programming them, and experimenting and | |||
| otherwise working with them. (See: hack. Compare: cracker.) | ||||
| Usage: The recommended definition is the original meaning of the | Usage: This first definition is the original meaning of the term | |||
| term (circa 1960), which then had a neutral or positive | (circa 1960); it then had a neutral or positive connotation of | |||
| connotation of "someone who figures things out and makes something | "someone who figures things out and makes something cool happen". | |||
| cool happen". Today, the term is frequently misused, especially by | ||||
| journalists, to have the pejorative meaning of "cracker". | 2. (D) Synonym for "cracker". | |||
| Deprecated Usage: Today, the term is frequently misused | ||||
| (especially by journalists) with this second meaning. | ||||
| $ handle | $ handle | |||
| 1. (I) /verb/ Perform processing operations on data, such as | 1. (I) /verb/ Perform processing operations on data, such as | |||
| receive and transmit, collect and disseminate, create and delete, | receive and transmit, collect and disseminate, create and delete, | |||
| store and retrieve, read and write, and compare. (See: access.) | store and retrieve, read and write, and compare. (See: access.) | |||
| 2. (I) /noun/ An on-line pseudonym, particularly one used by a | 2. (I) /noun/ An on-line pseudonym, particularly one used by a | |||
| cracker; derived from citizens band radio culture. | cracker; derived from citizens band radio culture. | |||
| $ handling restriction | $ handling restriction | |||
| (I) A type of access control other than (a) the rule-based | (I) A type of access control other than (a) the rule-based | |||
| protections of mandatory access control and (b) the identity-based | protections of mandatory access control and (b) the identity-based | |||
| protections of discretionary access control; usually procedural in | protections of discretionary access control; usually involves | |||
| nature. | administrative security. | |||
| $ Handling Restrictions field | $ Handling Restrictions field | |||
| (I) A 16-bit field (the "H field") that specifies a control and | (I) A 16-bit field that specifies a control and release marking in | |||
| release marking in the security option (option type 130) of IP's | the security option (option type 130) of IP's datagram header | |||
| datagram header format. The valid field values are alphanumeric | format. The valid field values are alphanumeric digraphs assigned | |||
| digraphs assigned by the U.S. Government, as specified in RFC 791. | by the U.S. Government, as specified in RFC 791. | |||
| Deprecated Abbreviation: ISDs SHOULD NOT use the abbreviation "H | Deprecated Abbreviation: ISDs SHOULD NOT use the abbreviation "H | |||
| field" because it is potentially ambiguous. Instead, use "Handling | field" because it is potentially ambiguous. Instead, use "Handling | |||
| Restrictions field". | Restrictions field". | |||
| $ handshake | $ handshake | |||
| (I) Protocol dialogue between two systems for identifying and | (I) Protocol dialogue between two systems for identifying and | |||
| authenticating themselves to each other, or for synchronizing | authenticating themselves to each other, or for synchronizing | |||
| their operations with each other. | their operations with each other. | |||
| $ Handshake Protocol | $ Handshake Protocol | |||
| (I) /TLS/ The TLS Handshake Protocol consists of three sub- | (I) /TLS/ The TLS Handshake Protocol consists of three parts | |||
| protocols that enable peer entities to agree upon security | (i.e., subprotocols) that enable peer entities to agree upon | |||
| parameters for the record layer, authenticate themselves to each | security parameters for the record layer, authenticate themselves | |||
| other, instantiate negotiated security parameters, and report | to each other, instantiate negotiated security parameters, and | |||
| error conditions to each other. [R2246] | report error conditions to each other. [R2246] | |||
| $ harden | $ harden | |||
| (I) To protect a system by configuring it to operate in a way that | (I) To protect a system by configuring it to operate in a way that | |||
| eliminates or mitigates known vulnerabilities. | eliminates or mitigates known vulnerabilities. Example: [RSCG]. | |||
| (See: default account.) | ||||
| $ hardware | $ hardware | |||
| (I) The material physical components of an information system. | (I) The material physical components of an information system. | |||
| (See: firmware, software.) | (See: firmware, software.) | |||
| $ hardware token | $ hardware token | |||
| See: token. | See: token. | |||
| $ hash code | $ hash code | |||
| Deprecated Term: ISDs SHOULD NOT use this term (especially not as | (D) Synonym for "hash result" or "hash function". | |||
| a synonym for "hash result" or "hash function"); the term mixes | ||||
| concepts in a potentially misleading way. A hash result is not a | Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | |||
| "code", and a hash function does not "encode" in any sense defined | in a potentially misleading way. A hash result is not a "code", | |||
| by this glossary. (See: hash value, message digest.) | and a hash function does not "encode" in any sense defined by this | |||
| glossary. (See: hash value, message digest.) | ||||
| $ hash function | $ hash function | |||
| 1. (I) A function H that maps an arbitrary, variable-length bit | 1. (I) A function H that maps an arbitrary, variable-length bit | |||
| string, s, into a fixed-length string, h = H(s) (called the "hash | string, s, into a fixed-length string, h = H(s) (called the "hash | |||
| result"). For most computing applications, it is desirable that | result"). For most computing applications, it is desirable that | |||
| given a string s with H(s) = h, any change to s that creates a | given a string s with H(s) = h, any change to s that creates a | |||
| different string s' will result in an unpredictable hash result | different string s' will result in an unpredictable hash result | |||
| H(s') that is, with high probability, not equal to H(s). | H(s') that is, with high probability, not equal to H(s). | |||
| 2. (O) "A (mathematical) function which maps values from a large | 2. (O) "A (mathematical) function which maps values from a large | |||
| (possibly very large) domain into a smaller range. A 'good' hash | (possibly very large) domain into a smaller range. A 'good' hash | |||
| function is such that the results of applying the function to a | function is such that the results of applying the function to a | |||
| (large) set of values in the domain will be evenly distributed | (large) set of values in the domain will be evenly distributed | |||
| (and apparently at random) over the range." [X509] | (and apparently at random) over the range." [X509] | |||
| Tutorial: A hash function operates on variable-length input (e.g., | Tutorial: A hash function operates on variable-length input (e.g., | |||
| a message or a file) and outputs a fixed-length output, which | a message or a file) and outputs a fixed-length output, which | |||
| typically is shorter than most input values. If the algorithm is | typically is much shorter than most input values. If the algorithm | |||
| "good" as described in the "O" definition, then the hash function | is "good" as described in the "O" definition, then the hash | |||
| may be a candidate for use in a security mechanism to detect | function may be a candidate for use in a security mechanism to | |||
| accidental changes in data, but not necessarily for a mechanism to | detect accidental changes in data, but not necessarily for a | |||
| detect changes made by active wiretapping (See: (discussion under) | mechanism to detect changes made by active wiretapping (See: | |||
| checksum). | Tutorial under "checksum".) | |||
| Security mechanisms require a "cryptographic hash function" (e.g., | Security mechanisms require a "cryptographic hash function" (e.g., | |||
| MD2, MD4, MD5, SHA-1, Snefru), i.e., a good hash function that | MD2, MD4, MD5, SHA-1, Snefru), i.e., a good hash function that | |||
| also has the one-way property and one of the two collision-free | also has the one-way property and one of the two collision-free | |||
| properties: | properties: | |||
| - "One-way property": Given H and a hash result h = H(s), it is | - "One-way property": Given H and a hash result h = H(s), it is | |||
| hard (i.e., computationally infeasible) to find s. (Of course, | hard (i.e., computationally infeasible) to find s. (Of course, | |||
| given H and an input s, it must be relatively easy to compute | given H and an input s, it must be relatively easy to compute | |||
| the hash result H(s).) | the hash result H(s).) | |||
| - "Weakly collision-free property": Given H and an input s, it is | - "Weakly collision-free property": Given H and an input s, it is | |||
| hard to find a different input, s', such that H(s) = H(s'). | hard to find a different input, s', such that H(s) = H(s'). | |||
| - "Strongly collision-free property": Given H, it is hard to find | - "Strongly collision-free property": Given H, it is hard to find | |||
| any pair of inputs s and s' such that H(s) = H(s'). | any pair of inputs s and s' such that H(s) = H(s'). | |||
| If H produces a hash result N bits long, then to find an s' where | If H produces a hash result N bits long, then to find an s' where | |||
| H(s') = H(s) for a specific given s, the amount of computation | H(s') = H(s) for a specific given s, the amount of computation | |||
| required is O(2**n); i.e., it is necessary to try on the order of | required is O(2**n); i.e., it is necessary to try on the order of | |||
| 2 to the power n values of s' before finding a collision. However, | 2 to the power n values of s' before finding a collision. However, | |||
| to simply find any pair of values s and s' that collide, the | to simply find any pair of values s and s' that collide, the | |||
| amount of computation required is only O(2**(n/2)); i.e., after | amount of computation required is only O(2**(n/2)); i.e., after | |||
| computing H(s) for 2 to the power n/2 randomly chosen values of s, | computing H(s) for 2 to the power n/2 randomly chosen values of s, | |||
| the probability is greater than 1/2 that two of those values have | the probability is greater than 1/2 that two of those values have | |||
| the same hash result. (See: birthday attack.) | the same hash result. (See: birthday attack.) | |||
| $ hash result | $ hash result | |||
| 1. (I) The output of a hash function. (See: hash code, hash | 1. (I) The output of a hash function. (See: hash code, hash value. | |||
| value.) | Compare: hash value.) | |||
| Usage: The "I" definition is recommended to avoid the unusual | ||||
| usage of "message" that is seen in the following "O" definition. | ||||
| 2. (O) "The output produced by a hash function upon processing a | 2. (O) "The output produced by a hash function upon processing a | |||
| message" (where "message" is broadly defined as "a digital | message" (where "message" is broadly defined as "a digital | |||
| representation of data"). [ABA] | representation of data"). [ABA] | |||
| Usage: ISDs SHOULD avoid the unusual usage of "message" that is | ||||
| seen in the "O" definition. | ||||
| $ hash value | $ hash value | |||
| (D) Synonym for "hash result". | (D) Synonym for "hash result". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it could be | Deprecated Term: ISDs SHOULD NOT use this term for the output of a | |||
| confused with "hashed value", which is the input to a hash | hash function; the term could easily be confused with "hashed | |||
| function. (See: hash code, hash result, message digest.) | value", which means the input to a hash function. (See: hash code, | |||
| hash result, message digest.) | ||||
| $ HDM | $ HDM | |||
| (O) See: Hierarchical Development Methodology. | (O) See: Hierarchical Development Methodology. | |||
| $ Hierarchical Development Methodology (HDM) | $ Hierarchical Development Methodology (HDM) | |||
| (O) A methodology, language, and integrated set of software tools | (O) A methodology, language, and integrated set of software tools | |||
| developed at SRI International for specifying, coding, and | developed at SRI International for specifying, coding, and | |||
| verifying software to produce correct and reliable programs. | verifying software to produce correct and reliable programs. | |||
| [Cheh] | [Cheh] | |||
| $ hierarchical PKI | $ hierarchical PKI | |||
| (I) A PKI architecture based on a certification hierarchy. | (I) A PKI architecture based on a certification hierarchy. | |||
| (Compare: mesh PKI, trust-file PKI.) | (Compare: mesh PKI, trust-file PKI.) | |||
| $ hierarchy management | $ hierarchy management | |||
| (I) The process of generating configuration data and issuing | (I) The process of generating configuration data and issuing | |||
| public-key certificates to build and operate a certification | public-key certificates to build and operate a certification | |||
| hierarchy. (See: certificate management.) | hierarchy. (See: certificate management.) | |||
| $ hierarchy of trust | $ hierarchy of trust | |||
| (D) Synonym for "certification hierarchy". | (D) Synonym for "certification hierarchy". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | |||
| in a potentially misleading way. (See: certification hierarchy, | in a potentially misleading way. (See: certification hierarchy, | |||
| trust, web of trust.) | trust, web of trust.) | |||
| $ high-assurance guard | $ high-assurance guard | |||
| (N) "An oxymoron," said Lt. Gen. William H. Campbell, former U.S. | (O) "An oxymoron," said Lt. Gen. William H. Campbell, former U.S. | |||
| Army chief information officer, speaking at an Armed Forces | Army chief information officer, speaking at an Armed Forces | |||
| Communications and Electronics Association conference. | Communications and Electronics Association conference. | |||
| Deprecated Usage: This term mixes concepts and could easily be | Usage: ISDs that use this term SHOULD state a definition for it | |||
| misunderstood; therefore, ISDs that use this term SHOULD state a | because the term mixes concepts and could easily be misunderstood. | |||
| definition for it. | ||||
| $ hijack attack | $ hijack attack | |||
| (I) A form of active wiretapping in which the attacker seizes | (I) A form of active wiretapping in which the attacker seizes | |||
| control of a previously established communication association. | control of a previously established communication association. | |||
| (See: man-in-the-middle attack, pagejacking, piggyback attack.) | (See: man-in-the-middle attack, pagejacking, piggyback attack.) | |||
| $ HIPAA | $ HIPAA | |||
| (N) Health Information Portability and Accountability Act of 1996, | (N) Health Information Portability and Accountability Act of 1996, | |||
| a U.S. law (Public Law 104-191) that protects the privacy of | a U.S. law (Public Law 104-191) that protects the privacy of | |||
| patients' medical records and other health information in all | patients' medical records and other health information in all | |||
| skipping to change at page 117, line 55 ¶ | skipping to change at page 124, line 13 ¶ | |||
| (I) A keyed hash [R2104] that can be based on any iterated | (I) A keyed hash [R2104] that can be based on any iterated | |||
| cryptographic hash (e.g., MD5 or SHA-1), so that the cryptographic | cryptographic hash (e.g., MD5 or SHA-1), so that the cryptographic | |||
| strength of HMAC depends on the properties of the selected | strength of HMAC depends on the properties of the selected | |||
| cryptographic hash. (See: [R2202, R2403, R2404].) | cryptographic hash. (See: [R2202, R2403, R2404].) | |||
| Tutorial: Assume that H is a generic cryptographic hash in which a | Tutorial: Assume that H is a generic cryptographic hash in which a | |||
| function is iterated on data blocks of length B bytes. L is the | function is iterated on data blocks of length B bytes. L is the | |||
| length of the of hash result of H. K is a secret key of length L | length of the of hash result of H. K is a secret key of length L | |||
| <= K <= B. The values IPAD and OPAD are fixed strings used as | <= K <= B. The values IPAD and OPAD are fixed strings used as | |||
| inner and outer padding and defined as follows: IPAD = the byte | inner and outer padding and defined as follows: IPAD = the byte | |||
| 0x36 repeated B times, OPAD = the byte 0x5C repeated B times. HMAC | 0x36 repeated B times, and OPAD = the byte 0x5C repeated B times. | |||
| is computed by H(K XOR OPAD, H(K XOR IPAD, inputdata)). | HMAC is computed by H(K XOR OPAD, H(K XOR IPAD, inputdata)). | |||
| HMAC has the following goals: | HMAC has the following goals: | |||
| - To use available cryptographic hash functions without | - To use available cryptographic hash functions without | |||
| modification, particularly functions that perform well in | modification, particularly functions that perform well in | |||
| software and for which software is freely and widely available. | software and for which software is freely and widely available. | |||
| - To preserve the original performance of the selected hash | - To preserve the original performance of the selected hash | |||
| without significant degradation. | without significant degradation. | |||
| - To use and handle keys in a simple way. | - To use and handle keys in a simple way. | |||
| - To have a well-understood cryptographic analysis of the | - To have a well-understood cryptographic analysis of the | |||
| strength of the mechanism based on reasonable assumptions about | strength of the mechanism based on reasonable assumptions about | |||
| the underlying hash function. | the underlying hash function. | |||
| - To enable easy replacement of the hash function in case a | - To enable easy replacement of the hash function in case a | |||
| faster or stronger hash is found or required. | faster or stronger hash is found or required. | |||
| $ honey pot | $ honey pot | |||
| (D) A system (e.g., a web server) or a system resource (e.g., a | (D) A system (e.g., a web server) or system resource (e.g., a file | |||
| file on a server), that is designed to be attractive to potential | on a server) that is designed to be attractive to potential | |||
| crackers and intruders, like honey is attractive to bears. (See: | crackers and intruders, like honey is attractive to bears. (See: | |||
| entrapment.) | entrapment.) | |||
| Deprecated Term: It is likely that other cultures have different | Deprecated Term: It is likely that other cultures use different | |||
| metaphors for this concept. Therefore, to ensure international | metaphors for this concept. Therefore, to avoid international | |||
| understanding, ISDs SHOULD NOT use this term. (See: (Deprecated | misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated | |||
| Usage under) Green Book.) | Usage under "Green Book.") | |||
| $ host | $ host | |||
| 1. (I) /general/ A computer that is attached to a communication | 1. (I) /general/ A computer that is attached to a communication | |||
| subnetwork or internetwork and can use services provided by the | subnetwork or internetwork and can use services provided by the | |||
| network to exchange data with other attached systems. (See: end | network to exchange data with other attached systems. (See: end | |||
| system. Compare: server.) | system. Compare: server.) | |||
| 2. (I) /IPS/ A networked computer that does not forward IP packets | 2. (I) /IPS/ A networked computer that does not forward IP packets | |||
| that are not addressed to the computer itself. (Compare: router.) | that are not addressed to the computer itself. (Compare: router.) | |||
| Derivation: As viewed by its users, a host "entertains" them, | Derivation: As viewed by its users, a host "entertains" them, | |||
| providing application layer services or access to other computers | providing Application-Layer services or access to other computers | |||
| attached to the network. However, even though some traditional | attached to the network. However, even though some traditional | |||
| peripheral service devices, such as printers, can now be | peripheral service devices, such as printers, can now be | |||
| independently connected to networks, they are not usually called | independently connected to networks, they are not usually called | |||
| hosts. | hosts. | |||
| $ HTML | $ HTML | |||
| (I) See: Hypertext Markup Language. | (I) See: Hypertext Markup Language. | |||
| $ HTTP | $ HTTP | |||
| (I) See: Hypertext Transfer Protocol. | (I) See: Hypertext Transfer Protocol. | |||
| skipping to change at page 119, line 14 ¶ | skipping to change at page 125, line 26 ¶ | |||
| $ hybrid encryption | $ hybrid encryption | |||
| (I) An application of cryptography that combines two or more | (I) An application of cryptography that combines two or more | |||
| encryption algorithms, particularly a combination of symmetric and | encryption algorithms, particularly a combination of symmetric and | |||
| asymmetric encryption. Examples: digital envelope, MSP, PEM, PGP. | asymmetric encryption. Examples: digital envelope, MSP, PEM, PGP. | |||
| (Compare: superencryption.) | (Compare: superencryption.) | |||
| Tutorial: Asymmetric algorithms require more computation than | Tutorial: Asymmetric algorithms require more computation than | |||
| equivalently strong symmetric ones. Thus, asymmetric encryption is | equivalently strong symmetric ones. Thus, asymmetric encryption is | |||
| not normally used for data confidentiality except to distribute a | not normally used for data confidentiality except to distribute a | |||
| symmetric keys in a hybrid encryption scheme, where the symmetric | symmetric key in a hybrid encryption scheme, where the symmetric | |||
| key is usually very short (in terms of bits) compared to the data | key is usually very short (in terms of bits) compared to the data | |||
| file it protects. (See: bulk key.) | file it protects. (See: bulk key.) | |||
| $ hyperlink | $ hyperlink | |||
| (I) In hypertext or hypermedia, an information object (such as a | (I) In hypertext or hypermedia, an information object (such as a | |||
| word, a phrase, or an image; usually highlighted by color or | word, a phrase, or an image, which usually is highlighted by color | |||
| underscoring) that points (indicates how to connect) to related | or underscoring) that points (i.e., indicates how to connect) to | |||
| information that is located elsewhere and can be retrieved by | related information that is located elsewhere and can be retrieved | |||
| activating the link (e.g., by selecting the object with a mouse | by activating the link (e.g., by selecting the object with a mouse | |||
| pointer and then clicking). | pointer and then clicking). | |||
| $ hypermedia | $ hypermedia | |||
| (I) A generalization of hypertext; any media that contain | (I) A generalization of hypertext; any media that contain | |||
| hyperlinks that point to material in the same or another data | hyperlinks that point to material in the same or another data | |||
| object. | object. | |||
| $ hypertext | $ hypertext | |||
| (I) A computer document, or part of a document, that contains | (I) A computer document, or part of a document, that contains | |||
| hyperlinks to other documents; i.e., text that contains active | hyperlinks to other documents; i.e., text that contains active | |||
| skipping to change at page 119, line 45 ¶ | skipping to change at page 126, line 6 ¶ | |||
| a web browser. (See: hypermedia.) | a web browser. (See: hypermedia.) | |||
| $ Hypertext Markup Language (HTML) | $ Hypertext Markup Language (HTML) | |||
| (I) A platform-independent system of syntax and semantics (RFC | (I) A platform-independent system of syntax and semantics (RFC | |||
| 1866) for adding characters to data files (particularly text | 1866) for adding characters to data files (particularly text | |||
| files) to represent the data's structure and to point to related | files) to represent the data's structure and to point to related | |||
| data, thus creating hypertext for use in the World Wide Web and | data, thus creating hypertext for use in the World Wide Web and | |||
| other applications. (Compare: XML.) | other applications. (Compare: XML.) | |||
| $ Hypertext Transfer Protocol (HTTP) | $ Hypertext Transfer Protocol (HTTP) | |||
| (I) An TCP-based, application-level, client-server, Internet | (I) An TCP-based, Application-Layer, client-server, Internet | |||
| protocol (RFC 2616) that is used to carry data requests and | protocol (RFC 2616) that is used to carry data requests and | |||
| responses in the World Wide Web. (See: hypertext.) | responses in the World Wide Web. (See: hypertext.) | |||
| $ IAB | $ IAB | |||
| (I) See: Internet Architecture Board. | (I) See: Internet Architecture Board. | |||
| $ IANA | $ IANA | |||
| (I) See: Internet Assigned Numbers Authority. | (I) See: Internet Assigned Numbers Authority. | |||
| $ IATF | $ IATF | |||
| skipping to change at page 120, line 31 ¶ | skipping to change at page 126, line 42 ¶ | |||
| $ IDEA | $ IDEA | |||
| (N) See: International Data Encryption Algorithm. | (N) See: International Data Encryption Algorithm. | |||
| $ identification | $ identification | |||
| (I) An act or process that presents an identifier to a system so | (I) An act or process that presents an identifier to a system so | |||
| that the system can recognize a system entity and distinguish it | that the system can recognize a system entity and distinguish it | |||
| from other entities. (See: authentication.) | from other entities. (See: authentication.) | |||
| $ identification information | $ identification information | |||
| (D) Synonym for "identifier" or "authentication information". | (D) Synonym for either "identifier" or "authentication | |||
| (See: authentication.) | information". (See: authentication.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it duplicates the | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| meaning of standardized terms and mixes concepts in a potentially | for either of those terms; that would be duplicative and would mix | |||
| misleading way. Instead, use "identifier" or "authentication | concepts in a potentially misleading way. Instead, use | |||
| information ", depending on what is meant. | "identifier" or "authentication information ", depending on what | |||
| is meant. | ||||
| $ Identification Protocol | $ Identification Protocol | |||
| (I) An client-server Internet protocol [R1413] for learning the | (I) An client-server Internet protocol [R1413] for learning the | |||
| identity of a user of a particular TCP connection. | identity of a user of a particular TCP connection. | |||
| Tutorial: Given a TCP port number pair, the server returns a | Tutorial: Given a TCP port number pair, the server returns a | |||
| character string that identifies the owner of that connection on | character string that identifies the owner of that connection on | |||
| the server's system. The protocol is not intended for | the server's system. The protocol does not provide an | |||
| authorization or access control; at best, it provides additional | authentication service and is not intended for authorization or | |||
| auditing information with respect to TCP. | access control. At best, it provides additional auditing | |||
| information with respect to TCP. | ||||
| $ identifier | $ identifier | |||
| (I) A data object -- often, a printable, non-blank character | (I) A data object -- often, a printable, non-blank character | |||
| string -- that definitively represents a specific identity of a | string -- that definitively represents a specific identity of a | |||
| system entity, distinguishing that identity from all others. | system entity, distinguishing that identity from all others. | |||
| (Compare: identity.) | (Compare: identity.) | |||
| $ identifier credential | ||||
| 1. (I) See: /authentication/ under "credential". | ||||
| 2. (D) Synonym for "signature certificate". | ||||
| Usage: ISDs that use this term SHOULD state a definition for it | ||||
| because the term is used in many ways and could easily be | ||||
| misunderstood. | ||||
| $ identity | $ identity | |||
| (I) The collective aspect of a set of attribute values (i.e., | (I) The collective aspect of a set of attribute values (i.e., | |||
| characteristics) by which a system entity is recognizable or | characteristics) by which a system entity is recognizable or | |||
| known, and which is sufficient to distinguish the entity from all | known, and which is sufficient to (1) distinguish the entity from | |||
| other entities in the system, and also sufficient to distinguish | all other entities in the system and (2) distinguish the identity | |||
| the identity from any other identities of the same entity. (See: | from any other identities of the same entity. (See: authenticate, | |||
| authenticate. Compare: identifier.) | registration. Compare: identifier.) | |||
| Tutorial: When a user's identity is registered in a system, the | ||||
| system may require presentation of evidence that proves both the | ||||
| user's eligibility to register and the identity's authenticity | ||||
| (i.e., that the user has the right to claim the identity). | ||||
| The set of attributes used for identities must, of course, be | ||||
| sufficient to uniquely represent each entity, i.e., to distinguish | ||||
| each entity from all others in the system. However, a PKI or other | ||||
| system may permit a subscriber to have two or more concurrent | ||||
| identities. (This is different from concurrently associating two | ||||
| different identifiers with the same identity, and also different | ||||
| from a single identity concurrently accessing the system in two | ||||
| different roles. (See: role-based access control.)) Having two or | ||||
| more identities registered in a system for the same entity implies | ||||
| that the entity has two separate justifications for registration | ||||
| eligibility. In that case, the set of attributes used for | ||||
| identities must be able to uniquely represent multiple identities | ||||
| for a single entity. | ||||
| Tutorial: This term relates to some other basic security terms as | Tutorial: At the time when a user's identity is being registered | |||
| shown in the following diagram: | in a system, the system may require presentation of evidence that | |||
| proves both the user's eligibility to register and the identity's | ||||
| authenticity (i.e., that the user has the right to claim the | ||||
| identity). | ||||
| Relationships: === One-To-One, ==> One-To-Many, <=> Many-to-Many. | The set of attributes used to recognize identities must, of | |||
| +- - - - - - - - - - - - - - - - - - - - - - - - - - + | course, be sufficient to uniquely represent each entity, i.e., to | |||
| | PKI System | | distinguish each entity from all others in the system. However, a | |||
| + - - - - + | +------------------+ +-------------------------+ | | PKI or other system may permit a subscriber to have two or more | |||
| | User | | | Subscriber, i.e. | | Subscriber Identity | | | concurrent identities. (This is different from concurrently | |||
| | +-----+ | | | Registered User | | | | | associating two different identifiers with the same identity, and | |||
| | |Human| | | |(Is System-Unique)| | (Is System-Unique) | | | also different from a single identity concurrently accessing the | |||
| | |Being| | | | +--------------+ | | +---------------------+ | | | system in two different roles. (See: principal, role-based access | |||
| | +-----+ | | | | User's Core | | | | Subscriber | | | | control.)) Having two or more identities registered in a system | |||
| | ^ |===| | Registration | |==>| | Identity's | | | | for the same entity implies that the entity has two separate | |||
| | | | | | | Data, i.e., | | | | Registration Data | | | | justifications for registration eligibility. In that case, the set | |||
| | | | | | | An Entity's | | | |+-------------------+| | | | of attributes used for identities must be able to uniquely | |||
| | v | | | |Distinguishing|========| Same Core Data || | | | represent multiple identities for a single entity. | |||
| | +-----+ | | | | Attribute | | | ||For All Identities || | | | ||||
| | | Set | | | | | Values | | +===|| Of The Same User || | | | ||||
| | +-----+ | | | +--------------+ | | | |+-------------------+| | | | ||||
| | ^ | | +------------------+ | | +---------------------+ | | | ||||
| | | | | | +=======+ +------------|------------+ | | ||||
| | | | | +-------v----|----------------------|------------+ | | ||||
| | v | | | +----------v-----+ +------------v----------+ | | | ||||
| | +-----+ | | | | Authentication |<=>| Subscriber Identifier | | | | ||||
| | |Auto-| | | | | Information | | (Is System Unique) | | | | ||||
| | |mated| | | | +----------------+ +-----------------------+ | | | ||||
| | |Pro- | | | | Identity Credential | | | ||||
| | |cess | | | |(Associates Authentication Info. and Identifier)| | | ||||
| | +-----+ | | +------------------------------------------------+ | | ||||
| + - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - -+ | ||||
| An ISD may apply this term to a user that is an individual entity | An ISD may apply this term to a user that is an individual entity | |||
| or one that is a set. If an ISD involves both meanings, the ISD | or one that is a set. If an ISD involves both meanings, the ISD | |||
| SHOULD use the following definitions to avoid ambiguity: | SHOULD use the following definitions to avoid ambiguity: | |||
| - "Singular identity": An identity that is registered for a user | - "Singular identity": An identity that is registered for a user | |||
| that is exactly one person or one process. | that is exactly one person or one process. | |||
| - "Shared identity": An identity that is registered for a user | - "Shared identity": An identity that is registered for a user | |||
| that is a set of entities of which each member is authorized to | that is a set of entities of which each member is authorized to | |||
| assume the identity individually and for which the registering | assume the identity individually and for which the registering | |||
| system maintains a record of the singular entities that | system maintains a record of the singular entities that | |||
| comprise the set. In this case, we would expect each member | comprise the set. In this case, we would expect each member | |||
| entity to be registered with a singular identity. | entity to be registered with a singular identity. | |||
| - "Group identity": An identity that is registered for a user | - "Group identity": An identity that is registered for a user | |||
| that is a set of entities for which the registering system does | that is a set of entities for which the registering system does | |||
| not maintain a record of the singular entities that comprise | not maintain a record of the singular entities that comprise | |||
| the set. | the set. | |||
| The following diagram illustrates how this term relates to some | ||||
| other terms in a PKI system: authentication information, | ||||
| identifier, identifier credential, registration, registered user, | ||||
| subscriber, and user. | ||||
| Relationships: === one-to-one, ==> one-to-many, <=> many-to-many. | ||||
| +- - - - - - - - - - - - - - - - - - - - - - - - - - + | ||||
| | PKI System | | ||||
| + - - - - + | +------------------+ +-------------------------+ | | ||||
| | User, | | |Subscriber, i.e., | | Identity of Subscriber | | | ||||
| |i.e., one| | | Registered User, | | is system-unique | | | ||||
| | of the | | | is system-unique | | +---------------------+ | | | ||||
| |following| | | +--------------+ | | | Subscriber | | | | ||||
| | | | | | User's core | | | | Identity's | | | | ||||
| | +-----+ |===| | Registration | |==>| | Registration data | | | | ||||
| | |human| | | | | data, i.e., | | | |+-------------------+| | | | ||||
| | |being| | | | | an entity's | | | || same core data || | | | ||||
| | +-----+ | | | |distinguishing|========|for all Identities || | | | ||||
| | or | | | | attribute | | | || of the same User || | | | ||||
| | +-----+ | | | | values | | +===|+-------------------+| | | | ||||
| | |auto-| | | | +--------------+ | | | +---------------------+ | | | ||||
| | |mated| | | +------------------+ | +------------|------------+ | | ||||
| | |pro- | | | | +=======+ | | | ||||
| | |cess | | | +-------v----|----------------------|------------+ | | ||||
| | +-----+ | | | +----------v---+ +------------v----------+ | | | ||||
| | or | | | |Authentication|<===>|Identifier of Identity | | | | ||||
| |+-------+| | | | Information | | is system-unique | | | | ||||
| || a set || | | +--------------+ +-----------------------+ | | | ||||
| || of || | | Identifier Credential that associates unit of | | | ||||
| || either|| | | Authentication Information with the Identifier | | | ||||
| |+-------+| | +------------------------------------------------+ | | ||||
| + - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - -+ | ||||
| $ identity-based security policy | $ identity-based security policy | |||
| (I) "A security policy based on the identities and/or attributes | (I) "A security policy based on the identities and/or attributes | |||
| of users, a group of users, or entities acting on behalf of the | of users, a group of users, or entities acting on behalf of the | |||
| users and the resources/objects being accessed." [I7498 Part 2] | users and the resources/objects being accessed." [I7498 Part 2] | |||
| (See: rule-based security policy.) | (See: rule-based security policy.) | |||
| $ identity credential | ||||
| 1. (I) See: ("authentication" context under) "credential". | ||||
| 2. (I) Synonym for "signature certificate. | ||||
| Usage: The term is used in many ways and could easily be | ||||
| misunderstood; therefore, ISDs that use this term SHOULD state a | ||||
| definition for it. | ||||
| $ identity proofing | $ identity proofing | |||
| (I) A process that vets and verifies the information that is used | (I) A process that vets and verifies the information that is used | |||
| to establish the identity of a system entity. | to establish the identity of a system entity. (See: registration.) | |||
| $ IDS | $ IDS | |||
| (I) See: intrusion detection system. | (I) See: intrusion detection system. | |||
| $ IEEE | $ IEEE | |||
| (N) See: Institute of Electrical and Electronics Engineers, Inc. | (N) See: Institute of Electrical and Electronics Engineers, Inc. | |||
| $ IEEE 802.10 | $ IEEE 802.10 | |||
| (N) An IEEE committee developing security standards for local area | (N) An IEEE committee developing security standards for local area | |||
| networks. (See: SILS.) | networks. (See: SILS.) | |||
| skipping to change at page 123, line 45 ¶ | skipping to change at page 129, line 39 ¶ | |||
| $ IETF | $ IETF | |||
| (I) See: Internet Engineering Task Force. | (I) See: Internet Engineering Task Force. | |||
| $ IKE | $ IKE | |||
| (I) See: IPsec Key Exchange. | (I) See: IPsec Key Exchange. | |||
| $ IMAP4 | $ IMAP4 | |||
| (I) See: Internet Message Access Protocol, version 4. | (I) See: Internet Message Access Protocol, version 4. | |||
| $ IMAP4 AUTHENTICATE | $ IMAP4 AUTHENTICATE | |||
| (I) A IMAP4 "command" (better described as a transaction type, or | (I) A IMAP4 command (better described as a transaction type, or | |||
| a protocol-within-a-protocol) by which an IMAP4 client optionally | subprotocol) by which an IMAP4 client optionally proposes a | |||
| proposes a mechanism to an IMAP4 server to authenticate the client | mechanism to an IMAP4 server to authenticate the client to the | |||
| to the server and provide other security services. (See: POP3.) | server and provide other security services. (See: POP3.) | |||
| Tutorial: If the server accepts the proposal, the command is | Tutorial: If the server accepts the proposal, the command is | |||
| followed by performing a challenge-response authentication | followed by performing a challenge-response authentication | |||
| protocol and, optionally, negotiating a protection mechanism for | protocol and, optionally, negotiating a protection mechanism for | |||
| subsequent POP3 interactions. The security mechanisms that are | subsequent POP3 interactions. The security mechanisms that are | |||
| used by IMAP4 AUTHENTICATE -- including Kerberos, GSSAPI, and | used by IMAP4 AUTHENTICATE -- including Kerberos, GSSAPI, and | |||
| S/Key -- are described in [R1731]. | S/Key -- are described in [R1731]. | |||
| $ in the clear | $ in the clear | |||
| (I) Not encrypted. (See: clear text.) | (I) Not encrypted. (See: clear text.) | |||
| $ Ina Jo | $ Ina Jo | |||
| (O) A methodology, language, and integrated set of software tools | (O) A methodology, language, and integrated set of software tools | |||
| developed at the System Development Corporation for specifying, | developed at the System Development Corporation for specifying, | |||
| coding, and verifying software to produce correct and reliable | coding, and verifying software to produce correct and reliable | |||
| programs. Also known as the Formal Development Methodology. [Cheh] | programs. Usage: a.k.a. the Formal Development Methodology. [Cheh] | |||
| $ incapacitation | $ incapacitation | |||
| (I) A type of threat action that prevents or interrupts system | (I) A type of threat action that prevents or interrupts system | |||
| operation by disabling a system component. (See: disruption.) | operation by disabling a system component. (See: disruption.) | |||
| Usage: This type includes the following subtypes: | Usage: This type includes the following subtypes: | |||
| - "Malicious logic": In context of incapacitation, any hardware, | - "Malicious logic": In context of incapacitation, any hardware, | |||
| firmware, or software (e.g., logic bomb) intentionally | firmware, or software (e.g., logic bomb) intentionally | |||
| introduced into a system to destroy system functions or | introduced into a system to destroy system functions or | |||
| resources. (See: (main entry for) malicious logic.) | resources. (See: corruption, main entry for "malicious logic", | |||
| - "Physical destruction": Deliberate destruction of a system | masquerade, misuse.) | |||
| - "Physical destruction": Deliberate destruction of a system | ||||
| component to interrupt or prevent system operation. | component to interrupt or prevent system operation. | |||
| - "Human error": In context of incapacitation, action or inaction | - "Human error": In context of incapacitation, action or inaction | |||
| that unintentionally disables a system component. | that unintentionally disables a system component. (See: | |||
| - "Hardware or software error": In context of incapacitation, | corruption, exposure.) | |||
| - "Hardware or software error": In context of incapacitation, | ||||
| error that unintentionally causes failure of a system component | error that unintentionally causes failure of a system component | |||
| and leads to disruption of system operation. | and leads to disruption of system operation. (See: corruption, | |||
| - "Natural disaster": In context of incapacitation, any "act of | exposure.) | |||
| - "Natural disaster": In context of incapacitation, any "act of | ||||
| God" (e.g., fire, flood, earthquake, lightning, or wind) that | God" (e.g., fire, flood, earthquake, lightning, or wind) that | |||
| disables a system component. [FP031 section 2] | disables a system component. [FP031 section 2] | |||
| $ incident | $ incident | |||
| See: security incident. | See: security incident. | |||
| $ INCITS | $ INCITS | |||
| See: (International Committee for Information Technology | (N) See: "International Committee for Information Technology | |||
| Standardization under) ANSI. | Standardization" under "ANSI". | |||
| $ indicator | $ indicator | |||
| (N) An action -- either specific, generalized, or theoretical -- | (N) An action -- either specific, generalized, or theoretical -- | |||
| that an adversary might be expected to take in preparation for an | that an adversary might be expected to take in preparation for an | |||
| attack. [C4009] (See: attack sensing, warning, and response.) | attack. [C4009] (See: attack sensing, warning, and response.) | |||
| $ indirect certificate revocation list (ICRL) | $ indirect certificate revocation list (ICRL) | |||
| (N) In X.509, a CRL that may contain certificate revocation | (N) In X.509, a CRL that may contain certificate revocation | |||
| notifications for certificates issued by CAs other than the issuer | notifications for certificates issued by CAs other than the issuer | |||
| (i.e., signer) of the ICRL. | (i.e., signer) of the ICRL. | |||
| skipping to change at page 126, line 17 ¶ | skipping to change at page 132, line 13 ¶ | |||
| (O) A publicly available document [IATF], developed through a | (O) A publicly available document [IATF], developed through a | |||
| collaborative effort by organizations in the U.S. Government and | collaborative effort by organizations in the U.S. Government and | |||
| industry, and issued by NSA. Intended for security managers and | industry, and issued by NSA. Intended for security managers and | |||
| system security engineers as a tutorial and reference document | system security engineers as a tutorial and reference document | |||
| about security problems in information systems and networks, to | about security problems in information systems and networks, to | |||
| improve awareness of tradeoffs among available technology | improve awareness of tradeoffs among available technology | |||
| solutions and of desired characteristics of security approaches | solutions and of desired characteristics of security approaches | |||
| for particular problems. (See: ISO 17799, [SP14].) | for particular problems. (See: ISO 17799, [SP14].) | |||
| $ information domain | $ information domain | |||
| (O) See: (secondary definition under) domain. | (O) See: secondary definition under "domain". | |||
| $ information domain security policy | $ information domain security policy | |||
| (O) See: (secondary definition under) domain. | (O) See: secondary definition under "domain". | |||
| $ information flow policy | $ information flow policy | |||
| (N) /formal model/ A triple consisting of a set of security | (N) /formal model/ A triple consisting of a set of security | |||
| levels (or their equivalent security labels), a binary operator | levels (or their equivalent security labels), a binary operator | |||
| that maps each pair of security levels into a security level, and | that maps each pair of security levels into a security level, and | |||
| a binary relation on the set that selects a set of pairs of levels | a binary relation on the set that selects a set of pairs of levels | |||
| such that information is permitted to flow from an object of the | such that information is permitted to flow from an object of the | |||
| first level to an object of the second level. (See: flow control, | first level to an object of the second level. (See: flow control, | |||
| lattice model.) | lattice model.) | |||
| $ information operations condition (INFOCON) | $ information operations condition (INFOCON) | |||
| (O) /U.S. DoD/ A comprehensive defense posture and response based | (O) /U.S. DoD/ A comprehensive defense posture and response based | |||
| on the status of information systems, military operations, and | on the status of information systems, military operations, and | |||
| intelligence assessments of adversary capabilities and intent. | intelligence assessments of adversary capabilities and intent. | |||
| (See: threat) | (See: threat) | |||
| Derivation: From DEFCON, i.e., defense condition. | Derivation: From DEFCON, i.e., defense condition. | |||
| Tutorial: The U.S. DoD INFOCON levels are: NORMAL (normal | Tutorial: The U.S. DoD defines five INFOCON levels: NORMAL (normal | |||
| activity), ALPHA (increased risk of attack), BRAVO (specific risk | activity), ALPHA (increased risk of attack), BRAVO (specific risk | |||
| of attack), CHARLIE (limited attack), and DELTA (general attack). | of attack), CHARLIE (limited attack), and DELTA (general attack). | |||
| $ information security (INFOSEC) | $ information security (INFOSEC) | |||
| (N) Measures that implement and assure security services in | (N) Measures that implement and assure security services in | |||
| information systems, including in computer systems (see: COMPUSEC) | information systems, including in computer systems (see: COMPUSEC) | |||
| and in communication systems (see: COMSEC). | and in communication systems (see: COMSEC). | |||
| $ information system | $ information system | |||
| (I) An organized assembly of computing and communication resources | (I) An organized assembly of computing and communication resources | |||
| skipping to change at page 127, line 15 ¶ | skipping to change at page 133, line 10 ¶ | |||
| $ Information Technology Security Evaluation Criteria (ITSEC) | $ Information Technology Security Evaluation Criteria (ITSEC) | |||
| (N) A Standard [ITSEC] jointly developed by France, Germany, the | (N) A Standard [ITSEC] jointly developed by France, Germany, the | |||
| Netherlands, and the United Kingdom for use in the European Union; | Netherlands, and the United Kingdom for use in the European Union; | |||
| accommodates a wider range of security assurance and functionality | accommodates a wider range of security assurance and functionality | |||
| combinations than the TCSEC. Superseded by the Common Criteria. | combinations than the TCSEC. Superseded by the Common Criteria. | |||
| $ INFOSEC | $ INFOSEC | |||
| (I) See: information security. | (I) See: information security. | |||
| $ ingress filtering | $ ingress filtering | |||
| (I) A method [R2267] for countering attacks that use packets with | (I) A method [R2827] for countering attacks that use packets with | |||
| false IP source addresses, by blocking such packets at the | false IP source addresses, by blocking such packets at the | |||
| boundary between connected networks. | boundary between connected networks. | |||
| Tutorial: Suppose network A of an internet service provider (ISP) | Tutorial: Suppose network A of an internet service provider (ISP) | |||
| includes a filtering router that is connected to customer network | includes a filtering router that is connected to customer network | |||
| B, and an attacker in B at IP source address "foo" attempts to | B, and an attacker in B at IP source address "foo" attempts to | |||
| send packets with false source address "bar" into A. The false | send packets with false source address "bar" into A. The false | |||
| address may be either fixed or randomly changing, and it may | address may be either fixed or randomly changing, and it may | |||
| either be unreachable or be a forged address that legitimately | either be unreachable or be a forged address that legitimately | |||
| exists within either B or some other network C. In ingress | exists within either B or some other network C. In ingress | |||
| filtering, the ISP's router blocks all inbound packet that arrive | filtering, the ISP's router blocks all inbound packet that arrive | |||
| from B with a source address that is not within the range of | from B with a source address that is not within the range of | |||
| legitimately advertised addresses for B. This method does not | legitimately advertised addresses for B. This method does not | |||
| prevent all attacks that can originate from B, but the actual | prevent all attacks that can originate from B, but the actual | |||
| source of such attacks can be more easily traced because the | source of such attacks can be more easily traced because the | |||
| originating network is known. | originating network is known. | |||
| $ initialization value (IV) | $ initialization value (IV) | |||
| (I) An input parameter that sets the starting state of a | (I) /cryptography/ An input parameter that sets the starting state | |||
| cryptographic algorithm or mode. | of a cryptographic algorithm or mode. | |||
| Usage: Sometimes called "initialization vector" or "message | Usage: Sometimes called "initialization vector" or "message | |||
| indicator", but ISDs SHOULD NOT use these synonyms because they | indicator", but ISDs SHOULD NOT use these synonyms because they | |||
| mix concepts in potentially confusing ways. | mix concepts in potentially confusing ways. | |||
| Tutorial: An IV can be used to synchronize one cryptographic | Tutorial: An IV can be used to synchronize one cryptographic | |||
| process with another; e.g., CBC, CFB, and OFB use IVs. An IV also | process with another; e.g., CBC, CFB, and OFB use IVs. An IV also | |||
| can be used to introduce cryptographic variance (see: salt) in | can be used to introduce cryptographic variance (see: salt) in | |||
| addition to that provided by a key. | addition to that provided by a key. | |||
| $ initialization vector | $ initialization vector | |||
| (D) /cryptographic function/ Synonym for "initialization value". | (D) /cryptographic function/ Synonym for "initialization value". | |||
| Deprecated Term: For consistency, ISDs SHOULD NOT use this term in | Deprecated Term: For consistency, ISDs SHOULD NOT use this term in | |||
| the context of cryptographic functions. | the context of cryptographic functions. | |||
| $ insertion | ||||
| (I) /packet/ See: secondary definition under "stream integrity | ||||
| service". | ||||
| $ inside attack | $ inside attack | |||
| (I) See: (secondary definition under) attack. Compare: insider.) | (I) See: secondary definition under "attack". Compare: insider. | |||
| $ insider | $ insider | |||
| 1. (I) A user (usually a person) that accesses a system from a | 1. (I) A user (usually a person) that accesses a system from a | |||
| position that is inside the system's security perimeter. (Compare: | position that is inside the system's security perimeter. (Compare: | |||
| authorized user, outsider, unauthorized user.) | authorized user, outsider, unauthorized user.) | |||
| Tutorial: An insider has been assigned a role that has more | Tutorial: An insider has been assigned a role that has more | |||
| privileges to access system resources than do some other types of | privileges to access system resources than do some other types of | |||
| users, or can access those resources without being constrained by | users, or can access those resources without being constrained by | |||
| some access controls that are applied to outside users. For | some access controls that are applied to outside users. For | |||
| skipping to change at page 128, line 43 ¶ | skipping to change at page 134, line 43 ¶ | |||
| $ Institute of Electrical and Electronics Engineers, Inc. (IEEE) | $ Institute of Electrical and Electronics Engineers, Inc. (IEEE) | |||
| (N) The IEEE is a not-for-profit association of approximately | (N) The IEEE is a not-for-profit association of approximately | |||
| 300,000 individual members in 150 countries. The IEEE produces | 300,000 individual members in 150 countries. The IEEE produces | |||
| nearly one third of the world's published literature in electrical | nearly one third of the world's published literature in electrical | |||
| engineering, computers, and control technology; holds hundreds of | engineering, computers, and control technology; holds hundreds of | |||
| major, annual conferences; and maintains more than 800 active | major, annual conferences; and maintains more than 800 active | |||
| standards, with many more under development. (See: SILS.) | standards, with many more under development. (See: SILS.) | |||
| $ integrity | $ integrity | |||
| See: data integrity, correctness integrity, source integrity, | See: data integrity, datagram integrity service, correctness | |||
| system integrity. | integrity, source integrity, stream integrity service, system | |||
| integrity. | ||||
| $ integrity check | $ integrity check | |||
| (D) A computation that is part of a mechanism to provide data | (D) A computation that is part of a mechanism to provide data | |||
| integrity service or data origin authentication service. (Compare: | integrity service or data origin authentication service. (Compare: | |||
| checksum.) | checksum.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | |||
| "cryptographic hash" or "protected checksum. This term | "cryptographic hash" or "protected checksum. This term | |||
| unnecessarily duplicates the meaning of other, well-established | unnecessarily duplicates the meaning of other, well-established | |||
| terms; this term only mentions integrity, even though the intended | terms; this term only mentions integrity, even though the intended | |||
| skipping to change at page 129, line 14 ¶ | skipping to change at page 135, line 15 ¶ | |||
| is cryptographically protected. | is cryptographically protected. | |||
| $ integrity label | $ integrity label | |||
| (I) A security label that tells the degree of confidence that may | (I) A security label that tells the degree of confidence that may | |||
| be placed in the data, and may also tell what countermeasures are | be placed in the data, and may also tell what countermeasures are | |||
| required to be applied to protect the data against from alteration | required to be applied to protect the data against from alteration | |||
| and destruction. (See: integrity. Compare: classification label.) | and destruction. (See: integrity. Compare: classification label.) | |||
| $ intelligent threat | $ intelligent threat | |||
| (I) A circumstance in which an adversary has the technical and | (I) A circumstance in which an adversary has the technical and | |||
| operational capability to detect and exploit a vulnerability and | operational ability to detect and exploit a vulnerability and also | |||
| also has the demonstrated, presumed, or inferred intent to do so. | has the demonstrated, presumed, or inferred intent to do so. (See: | |||
| (See: threat.) | threat.) | |||
| $ interception | $ interception | |||
| (I) A type of threat action whereby an unauthorized entity | (I) A type of threat action whereby an unauthorized entity | |||
| directly accesses sensitive data while the data is traveling | directly accesses sensitive data while the data is traveling | |||
| between authorized sources and destinations. (See: unauthorized | between authorized sources and destinations. (See: unauthorized | |||
| disclosure.) | disclosure.) | |||
| Usage: This type includes the following subtypes: | Usage: This type includes the following subtypes: | |||
| - "Theft": Gaining access to sensitive data by stealing a | - "Theft": Gaining access to sensitive data by stealing a | |||
| shipment of a physical medium, such as a magnetic tape or disk, | shipment of a physical medium, such as a magnetic tape or disk, | |||
| that holds the data. | that holds the data. | |||
| - "Wiretapping (passive)": Monitoring and recording data that is | - "Wiretapping (passive)": Monitoring and recording data that is | |||
| flowing between two points in a communication system. (See: | flowing between two points in a communication system. (See: | |||
| wiretapping.) | wiretapping.) | |||
| - "Emanations analysis": Gaining direct knowledge of communicated | - "Emanations analysis": Gaining direct knowledge of communicated | |||
| data by monitoring and resolving a signal that is emitted by a | data by monitoring and resolving a signal that is emitted by a | |||
| system and that contains the data but is not intended to | system and that contains the data but was not intended to | |||
| communicate the data. (See: emanation.) | communicate the data. (See: emanation.) | |||
| $ interference | $ interference | |||
| See: (secondary definition under) obstruction. | (I) /threat action/ See: secondary definition under "obstruction". | |||
| $ intermediate CA | $ intermediate CA | |||
| (D) The CA that issues a cross-certificate to another CA. [X509] | (D) The CA that issues a cross-certificate to another CA. [X509] | |||
| (See: cross-certification.) | (See: cross-certification.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term because it is not | Deprecated Term: ISDs SHOULD NOT use this term because it is not | |||
| widely known and mixes concepts in a potentially misleading way. | widely known and mixes concepts in a potentially misleading way. | |||
| For example, suppose that end entity 1 ("EE1) is in one PKI | For example, suppose that end entity 1 ("EE1) is in one PKI | |||
| ("PKI1"), end entity 2 ("EE2) is in another PKI ("PKI2"), and the | ("PKI1"), end entity 2 ("EE2) is in another PKI ("PKI2"), and the | |||
| root in PKI1 ("CA1") cross-certifies the root CA in PKI2 ("CA2"). | root in PKI1 ("CA1") cross-certifies the root CA in PKI2 ("CA2"). | |||
| skipping to change at page 130, line 13 ¶ | skipping to change at page 136, line 14 ¶ | |||
| characteristics of computer hardware and software, especially of | characteristics of computer hardware and software, especially of | |||
| operating systems. Includes mechanisms to regulate the operation | operating systems. Includes mechanisms to regulate the operation | |||
| of a computer system with regard to access control, flow control, | of a computer system with regard to access control, flow control, | |||
| and inference control. (Compare: external controls.) | and inference control. (Compare: external controls.) | |||
| $ International Data Encryption Algorithm (IDEA) | $ International Data Encryption Algorithm (IDEA) | |||
| (N) A patented, symmetric block cipher that uses a 128-bit key and | (N) A patented, symmetric block cipher that uses a 128-bit key and | |||
| operates on 64-bit blocks. [Schn] (See: symmetric cryptography.) | operates on 64-bit blocks. [Schn] (See: symmetric cryptography.) | |||
| $ International Standard | $ International Standard | |||
| (N) See: (secondary definition under) ISO. | (N) See: secondary definition under "ISO". | |||
| $ International Traffic in Arms Regulations (ITAR) | $ International Traffic in Arms Regulations (ITAR) | |||
| (O) Rules issued by the U.S. State Department, by authority of the | (O) Rules issued by the U.S. State Department, by authority of the | |||
| Arms Export Control Act (22 U.S.C. 2778), to control export and | Arms Export Control Act (22 U.S.C. 2778), to control export and | |||
| import of defense articles and defense services, including | import of defense articles and defense services, including | |||
| information security systems, such as cryptographic systems, and | information security systems, such as cryptographic systems, and | |||
| TEMPEST suppression technology. (See: type 1 product, Wassenaar | TEMPEST suppression technology. (See: type 1 product, Wassenaar | |||
| Arrangement.) | Arrangement.) | |||
| $ internet, Internet | $ internet, Internet | |||
| 1. (I) /not capitalized/ The term "internet" is a popular short | 1. (I) /not capitalized/ Abbreviation of "internetwork". | |||
| synonym for "internetwork". | ||||
| 2. (I) /capitalized/ "The Internet" is the single, interconnected, | 2. (I) /capitalized/ The Internet is the single, interconnected, | |||
| worldwide system of commercial, government, educational, and other | worldwide system of commercial, government, educational, and other | |||
| computer networks that share the protocol suite specified by the | computer networks that share (a) the protocol suite specified by | |||
| IAB [R2026] and the name and address spaces managed by the ICANN. | the IAB (RFC 2026) and (b) the name and address spaces managed by | |||
| the ICANN. (See: Internet Layer, Internet Protocol Suite.) | ||||
| Tutorial: The set of protocols is called the "Internet Protocol | ||||
| Suite" (IPS). It also is popularly known as "TCP/IP", because TCP | ||||
| and IP are two of its most important protocols. The IPS makes it | ||||
| possible for users of any one of the networks in the Internet to | ||||
| communicate with, or use services located on, any of the other | ||||
| networks. | ||||
| Although the Internet does have architectural principles | ||||
| (described in RFC 1958), no Internet Standard defines a layered | ||||
| reference model for the IPS that is similar to the OSIRM. However, | ||||
| Internet community documents do refer (inconsistently) to layers: | ||||
| application, socket, transport, internetwork, network, data link, | ||||
| and physical. | ||||
| Usage: In this Glossary, Internet protocol layers are referred to | Usage: Use with definite article "the" when using as a noun. E.g., | |||
| by name to avoid confusing them with OSIRM layers, which are | say "My LAN is small, but the Internet is large." Don't say "My | |||
| referred to by number. (See: OSI.) | LAN is small, but Internet is large." | |||
| $ Internet Architecture Board (IAB) | $ Internet Architecture Board (IAB) | |||
| (I) A technical advisory group of the ISOC, chartered by the ISOC | (I) A technical advisory group of the ISOC, chartered by the ISOC | |||
| Trustees to provide oversight of Internet architecture and | Trustees to provide oversight of Internet architecture and | |||
| protocols and, in the context of Internet Standards, a body to | protocols and, in the context of Internet Standards, a body to | |||
| which decisions of the IESG may be appealed. Responsible for | which decisions of the IESG may be appealed. Responsible for | |||
| approving appointments to the IESG from among nominees submitted | approving appointments to the IESG from among nominees submitted | |||
| by the IETF nominating committee. [R2026] | by the IETF nominating committee. (RFC 2026) | |||
| $ Internet Assigned Numbers Authority (IANA) | $ Internet Assigned Numbers Authority (IANA) | |||
| (I) From the early days of the Internet, the IANA was chartered by | (I) From the early days of the Internet, the IANA was chartered by | |||
| the ISOC and the U.S. Government's Federal Network Council to be | the ISOC and the U.S. Government's Federal Network Council to be | |||
| the central coordination, allocation, and registration body for | the central coordination, allocation, and registration body for | |||
| parameters for Internet protocols. Superseded by ICANN. | parameters for Internet protocols. Superseded by ICANN. | |||
| $ Internet Control Message Protocol (ICMP) | $ Internet Control Message Protocol (ICMP) | |||
| (I) An Internet Standard protocol (RFC 792) that is used to report | (I) An Internet Standard protocol (RFC 792) that is used to report | |||
| error conditions during IP datagram processing and to exchange | error conditions during IP datagram processing and to exchange | |||
| skipping to change at page 131, line 37 ¶ | skipping to change at page 137, line 25 ¶ | |||
| management information base OIDs, including private enterprise | management information base OIDs, including private enterprise | |||
| numbers, and many others. The Internet community requires that the | numbers, and many others. The Internet community requires that the | |||
| values used in these parameter fields be assigned uniquely. ICANN | values used in these parameter fields be assigned uniquely. ICANN | |||
| makes those assignments as requested and maintains a registry of | makes those assignments as requested and maintains a registry of | |||
| the current values. | the current values. | |||
| ICANN was formed in October 1998, by a coalition of the Internet's | ICANN was formed in October 1998, by a coalition of the Internet's | |||
| business, technical, and academic communities. The U.S. Government | business, technical, and academic communities. The U.S. Government | |||
| designated ICANN to serve as the global consensus entity with | designated ICANN to serve as the global consensus entity with | |||
| responsibility for coordinating four key functions for the | responsibility for coordinating four key functions for the | |||
| Internet: the allocation of IP address space, the assignment of | Internet: allocation of IP address space, assignment of protocol | |||
| protocol parameters, and the management of the DNS and the DNS | parameters, management of the DNS, and management of the DNS root | |||
| root server system. | server system. | |||
| $ Internet Draft | $ Internet-Draft | |||
| (I) A working document of the IETF, its areas, and its working | (I) A working document of the IETF, its areas, and its working | |||
| groups. (Other groups may also distribute working documents as | groups. (RFC 2026) | |||
| Internet Drafts.) An Internet Draft is not an archival document | ||||
| like an RFC is. Instead, an Internet Draft is a preliminary or | Usage: The term is customarily hyphenated when used either as a | |||
| working document that is valid for a maximum of six months and may | adjective or a noun, even though the latter is not standard | |||
| be updated, replaced, or made obsolete by other documents at any | English punctuation. | |||
| Tutorial: An Internet-Draft is not an archival document like an | ||||
| RFC is. Instead, an Internet-Draft is a preliminary or working | ||||
| document that is valid for a maximum of six months and may be | ||||
| updated, replaced, or made obsolete by other documents at any | ||||
| time. It is inappropriate to use an Internet Draft as reference | time. It is inappropriate to use an Internet Draft as reference | |||
| material or to cite it other than as "work in progress". | material or to cite it other than as "work in progress". Although | |||
| most of the Internet-Drafts are produced by the IETF, any | ||||
| interested organization may request to have its working documents | ||||
| published as Internet-Drafts. | ||||
| $ Internet Engineering Steering Group (IESG) | $ Internet Engineering Steering Group (IESG) | |||
| (I) The part of the ISOC responsible for technical management of | (I) The part of the ISOC responsible for technical management of | |||
| IETF activities and administration of the Internet Standards | IETF activities and administration of the Internet Standards | |||
| Process according to procedures approved by the ISOC Trustees. | Process according to procedures approved by the ISOC Trustees. | |||
| Directly responsible for actions along the "standards track", | Directly responsible for actions along the "standards track", | |||
| including final approval of specifications as Internet Standards. | including final approval of specifications as Internet Standards. | |||
| Composed of IETF Area Directors and the IETF chairperson, who also | Composed of IETF Area Directors and the IETF chairperson, who also | |||
| chairs the IESG. [R2026] | chairs the IESG. (RFC 2026) | |||
| $ Internet Engineering Task Force (IETF) | $ Internet Engineering Task Force (IETF) | |||
| (I) A self-organized group of people who make contributions to the | (I) A self-organized group of people who make contributions to the | |||
| development of Internet technology. The principal body engaged in | development of Internet technology. The principal body engaged in | |||
| developing Internet Standards, although not itself a part of the | developing Internet Standards, although not itself a part of the | |||
| ISOC. Composed of Working Groups, which are arranged into Areas | ISOC. Composed of Working Groups, which are arranged into Areas | |||
| (such as the Security Area), each coordinated by one or more Area | (such as the Security Area), each coordinated by one or more Area | |||
| Directors. Nominations to the IAB and the IESG are made by a | Directors. Nominations to the IAB and the IESG are made by a | |||
| committee selected at random from regular IETF meeting attendees | committee selected at random from regular IETF meeting attendees | |||
| who have volunteered. [R2026, R2323] | who have volunteered. (RFC 2026) [RFC 2323] | |||
| $ Internet Layer | ||||
| (I) See: Internet Protocol Suite. | ||||
| $ Internet Message Access Protocol, version 4 (IMAP4) | $ Internet Message Access Protocol, version 4 (IMAP4) | |||
| (I) An Internet protocol (RFC 2060) by which a client workstation | (I) An Internet protocol (RFC 2060) by which a client workstation | |||
| can dynamically access a mailbox on a server host to manipulate | can dynamically access a mailbox on a server host to manipulate | |||
| and retrieve mail messages that the server has received and is | and retrieve mail messages that the server has received and is | |||
| holding for the client. (See: POP3.) | holding for the client. (See: POP3.) | |||
| Tutorial: IMAP4 has mechanisms for optionally authenticating a | Tutorial: IMAP4 has mechanisms for optionally authenticating a | |||
| client to a server and providing other security services. (See: | client to a server and providing other security services. (See: | |||
| IMAP4 AUTHENTICATE.) | IMAP4 AUTHENTICATE.) | |||
| skipping to change at page 132, line 39 ¶ | skipping to change at page 138, line 39 ¶ | |||
| (I) An Internet protocol (RFC 2801) proposed as a general | (I) An Internet protocol (RFC 2801) proposed as a general | |||
| framework for Internet commerce, able to encapsulate transactions | framework for Internet commerce, able to encapsulate transactions | |||
| of various proprietary payment systems (e.g., GeldKarte, Mondex, | of various proprietary payment systems (e.g., GeldKarte, Mondex, | |||
| SET, VisaCash). Provides optional security services by | SET, VisaCash). Provides optional security services by | |||
| incorporating various Internet security mechanisms (e.g., MD5) and | incorporating various Internet security mechanisms (e.g., MD5) and | |||
| protocols (e.g., TLS). | protocols (e.g., TLS). | |||
| $ Internet Policy Registration Authority (IPRA) | $ Internet Policy Registration Authority (IPRA) | |||
| (I) An X.509-compliant CA that is the top CA of the Internet | (I) An X.509-compliant CA that is the top CA of the Internet | |||
| certification hierarchy operated under the auspices of the ISOC | certification hierarchy operated under the auspices of the ISOC | |||
| [R1422]. (See: (PEM usage under) certification hierarchy.) | [R1422]. (See: /PEM/ under "certification hierarchy".) | |||
| $ Internet Private Line Interface (IPLI) | $ Internet Private Line Interface (IPLI) | |||
| (I) A successor to the PLI, updated to use TCP/IP and newer | (O) A successor to the PLI, updated to use TCP/IP and newer | |||
| military-grade COMSEC equipment (TSEC/KG-84). The IPLI was a | military-grade COMSEC equipment (TSEC/KG-84). The IPLI was a | |||
| portable, modular system that was developed for use in tactical, | portable, modular system that was developed for use in tactical, | |||
| packet-radio networks. | packet-radio networks. | |||
| $ Internet Protocol (IP) | $ Internet Protocol (IP) | |||
| (I) A Internet Standard protocol (version 4 is specified in RFC | (I) A Internet Standard, Internet-Layer protocol that moves | |||
| 791, and version 6 in RFC 2460) that moves datagrams (discrete | datagrams (discrete sets of bits) from one computer to another | |||
| sets of bits) from one computer to another across an internetwork | across an internetwork but does not provide reliable delivery, | |||
| but does not provide reliable delivery, flow control, sequencing, | flow control, sequencing, or other end-to-end services that TCP | |||
| or other end-to-end services that TCP provides. (See: IP address, | provides. IP version 4 (IPv4) is specified in RFC 791, and IP | |||
| version 6 (IPv6) is specified in RFC 2460. (See: IP address, | ||||
| TCP/IP.) | TCP/IP.) | |||
| Tutorial: In the OSIRM, IP would be located at the top of layer 3. | Tutorial: If IP were used in an OSIRM stack, IP would be placed at | |||
| the top of Layer 3, above other Layer 3 protocols in the stack. | ||||
| In any IPS stack, IP is always present in the Internet Layer and | ||||
| is always placed at the top of that layer, on top of any other | ||||
| protocols that are used in that layer. In some sense, IP is the | ||||
| only protocol specified for the IPS Internet Layer; other | ||||
| protocols used there, such as AH and ESP, are just IP variations. | ||||
| $ Internet Protocol security | $ Internet Protocol security | |||
| See: IPsec. | See: IPsec. | |||
| $ Internet Protocol Security Option (IPSO) | $ Internet Protocol Security Option (IPSO) | |||
| (I) Refers to one of three types of IP security options, which are | (I) Refers to one of three types of IP security options, which are | |||
| fields that may be added to an IP datagram for the purpose of | fields that may be added to an IP datagram for the purpose of | |||
| carrying security information about the datagram. (Compare: | carrying security information about the datagram. (Compare: | |||
| IPsec.) | IPsec.) | |||
| Deprecated Usage: ISDs SHOULD NOT use this term without a modifier | Deprecated Usage: ISDs SHOULD NOT use this term without a modifier | |||
| to indicate which of the following three types is meant. | to indicate which of the following three types is meant. | |||
| - "DoD Basic Security Option" (IP option type 130): Defined for | - "DoD Basic Security Option" (IP option type 130): Defined for | |||
| use on U.S. DoD common-use data networks. Identifies the DoD | use on U.S. DoD common-use data networks. Identifies the DoD | |||
| classification level at which the datagram is to be protected | classification level at which the datagram is to be protected | |||
| and the protection authorities whose rules apply to the | and the protection authorities whose rules apply to the | |||
| datagram. (A "protection authority" is a National Access | datagram. (A "protection authority" is a National Access | |||
| Program (e.g., GENSER, SIOP-ESI, SCI, NSA, Department of | Program (e.g., GENSER, SIOP-ESI, SCI, NSA, Department of | |||
| Energy) or Special Access Program that specifies protection | Energy) or Special Access Program that specifies protection | |||
| rules for transmission and processing of the information | rules for transmission and processing of the information | |||
| contained in the datagram.) [R1108] | contained in the datagram.) [R1108] | |||
| - "DoD Extended Security Option" (IP option type 133): Permits | - "DoD Extended Security Option" (IP option type 133): Permits | |||
| additional security labeling information, beyond that present | additional security labeling information, beyond that present | |||
| in the Basic Security Option, to be supplied in the datagram to | in the Basic Security Option, to be supplied in the datagram to | |||
| meet the needs of registered authorities. [R1108] | meet the needs of registered authorities. [R1108] | |||
| - "Common IP Security Option" (CIPSO) (IP option type 134): | - "Common IP Security Option" (CIPSO) (IP option type 134): | |||
| Designed by TSIG to carry hierarchic and non-hierarchic | Designed by TSIG to carry hierarchic and non-hierarchic | |||
| security labels. (Formerly called "Commercial IP Security | security labels. (Formerly called "Commercial IP Security | |||
| Option"; a version 2.3 draft was published 9 Mar 1993 as an | Option"; a version 2.3 draft was published 9 March 1993 as an | |||
| Internet-Draft but did not advance to RFC form.) [CIPSO] | Internet-Draft but did not advance to RFC form.) [CIPSO] | |||
| $ Internet Protocol Suite (IPS) | $ Internet Protocol Suite (IPS) | |||
| (I) See: (secondary definition under) Internet. | (I) The set of network communication protocols that are specified | |||
| by the IETF, and approved as Internet Standards by the IESG, | ||||
| within the oversight of the IAB. (See: OSIRM Security | ||||
| Architecture. Compare: OSIRM.) | ||||
| Usage: This set of protocols is popularly known as "TCP/IP" | ||||
| because TCP and IP are its most basic and important components. | ||||
| For clarity, this Glossary refers to IPS protocol layers by name | ||||
| and capitalizes those names, and refers to OSIRM protocol layers | ||||
| by number. | ||||
| Tutorial: The IPS does have architectural principles [R1958], but | ||||
| there is no Internet Standard that defines a layered IPS reference | ||||
| model like the OSIRM. Still, Internet community literature has | ||||
| referred (inconsistently) to IPS layers since early in the | ||||
| Internet's development [Padl]. | ||||
| This Glossary treats the IPS as having five protocol layers -- | ||||
| Application, Transport, Internet, Network Interface, and Network | ||||
| Hardware (or Network Substrate) -- which are illustrated in the | ||||
| following diagram: | ||||
| OSIRM Layers Examples IPS Layers Examples | ||||
| ------------------ --------------- --------------- -------------- | ||||
| Message Format: P2 [X420] Message Format: ARPA (RFC 822) | ||||
| +----------------+ +-------------+ | ||||
| |7.Application | P1 [X419] | Application | SMTP (RFC 821) | ||||
| +----------------+ - - - - - - | | | ||||
| |6.Presentatation| [I8823] | | | ||||
| +----------------+ - - - - - - | | | ||||
| |5.Session | [I8327] +-------------+ | ||||
| +----------------+ - - - - - - | Transport | TCP (RFC 793) | ||||
| |4.Transport | TP4 [I8073] | | | ||||
| +----------------+ - - - - - - +-------------+ | ||||
| |3.Network | CLNP [I8473] | Internet | IP (RFC 791) | ||||
| | | +-------------+ | ||||
| | | | Network | IP over IEEE | ||||
| +----------------+ - - - - - - | Interface | 802 (RFC 1042) | ||||
| |2.Data Link | +-------------+ | ||||
| | | LLC [I8802-2] - Network - The IPS does | ||||
| | | MAC [I8802-3] - Hardware - not include | ||||
| +----------------+ - (or Network - standards for | ||||
| |1.Physical | Baseband - Substrate) - this layer. | ||||
| +----------------+ Signaling [Stal] + - - - - - - + | ||||
| The diagram approximates how the five IPS layers align with the | ||||
| seven OSIRM layers, and it offers examples of protocol stacks that | ||||
| provide roughly equivalent electronic mail service over a private | ||||
| local area network that uses baseband signaling. | ||||
| - IPS Application Layer: The user runs an application program. | ||||
| The program selects the data transport service it needs -- | ||||
| either a sequence of data messages or a continuous stream of | ||||
| data -- and hands application data to the Transport Layer for | ||||
| delivery. | ||||
| - IPS Transport Layer: This layer divides application data into | ||||
| packets, adds a destination address to each, and communicates | ||||
| them end-to-end -- from one application program to another -- | ||||
| optionally regulating the flow and ensuring reliable (error- | ||||
| free and sequenced) delivery. | ||||
| - IPS Internet Layer: This layer carries transport packets in IP | ||||
| datagrams. It moves each datagram independently, from its | ||||
| source computer to its addressed destination computer, routing | ||||
| the datagram through a sequence of networks and relays and | ||||
| selecting appropriate network interfaces en route. | ||||
| - IPS Network Interface Layer: This layer accepts datagrams for | ||||
| transmission over a specific network. This layer specifies | ||||
| interface conventions for carrying IP over OSIRM Layer 3 | ||||
| protocols and over Media Access Control sublayer protocols of | ||||
| OSIRM Layer 2. An example is IP over IEEE 802 (RFD 1042). | ||||
| - IPS Network Hardware Layer: This layer consists of specific, | ||||
| physical communication media. However, the IPS does not specify | ||||
| its own peer-to-peer protocols in this layer. Instead, the | ||||
| layering conventions specified by the Network Interface Layer | ||||
| use Layer 2 and Layer 3 protocols that are specified by bodies | ||||
| other than the IETF. That it, the IPS addresses *inter*-network | ||||
| functions and does not address *intra*-network functions. | ||||
| The two models are most dissimilar in the upper layers, where the | ||||
| IPS model does not include Session and Presentation layers. | ||||
| However, this omission causes fewer functional differences between | ||||
| the models than might be imagined, and the differences have | ||||
| relatively few security implications: | ||||
| - Formal separation of OSIRM Layers 5, 6, and 7 is not needed in | ||||
| implementations; the functions of these layers sometimes are | ||||
| mixed in a single software unit, even in protocols in the OSI | ||||
| suite. | ||||
| - Some OSIRM Layer 5 services -- for example, connection | ||||
| termination -- are built into TCP, and the remaining Layer 5 | ||||
| and 6 functions are built into IPS Application-Layer protocols | ||||
| where needed. | ||||
| - The OSIRM does not place any security services in Layer 5 (see: | ||||
| OSIRM Security Architecture). | ||||
| - The lack of an explicit Presentation Layer in the IPS sometimes | ||||
| makes it simpler to implement security in IPS applications. For | ||||
| example, a primary function of Layer 6 is to convert data | ||||
| between internal and external forms, using a transfer syntax to | ||||
| unambiguously encode data for transmission. If an OSIRM | ||||
| application encrypts data to protect against disclosure during | ||||
| transmission, the transfer encoding must be done before the | ||||
| encryption. If an application does encryption, as is done in | ||||
| OSI message handling and directory service protocols, then | ||||
| Layer 6 functions must be replicated in Layer 7. [X400, X500]. | ||||
| The two models are most alike at the top of OSIRM Layer 3, where | ||||
| the OSI Connectionless Network Layer Protocol (CLNP) and the IPS | ||||
| IP are quite similar. Connection-oriented security services | ||||
| offered in OSIRM Layer 3 are inapplicable in the IPS, because the | ||||
| IPS Internet Layer lacks the explicit, connection-oriented service | ||||
| offered in the OSIRM. | ||||
| $ Internet Security Association and Key Management Protocol (ISAKMP) | $ Internet Security Association and Key Management Protocol (ISAKMP) | |||
| (I) An Internet IPsec protocol [R2408] to negotiate, establish, | (I) An Internet IPsec protocol [R2408] to negotiate, establish, | |||
| modify, and delete security associations, and to exchange key | modify, and delete security associations, and to exchange key | |||
| generation and authentication data, independent of the details of | generation and authentication data, independent of the details of | |||
| any specific key generation technique, key establishment protocol, | any specific key generation technique, key establishment protocol, | |||
| encryption algorithm, or authentication mechanism. | encryption algorithm, or authentication mechanism. | |||
| Tutorial: ISAKMP supports negotiation of security associations for | Tutorial: ISAKMP supports negotiation of security associations for | |||
| protocols at all TCP/IP layers. By centralizing management of | protocols at all IPS layers. By centralizing management of | |||
| security associations, ISAKMP reduces duplicated functionality | security associations, ISAKMP reduces duplicated functionality | |||
| within each protocol. ISAKMP can also reduce connection setup | within each protocol. ISAKMP can also reduce connection setup | |||
| time, by negotiating a whole stack of services at once. Strong | time, by negotiating a whole stack of services at once. Strong | |||
| authentication is required on ISAKMP exchanges, and a digital | authentication is required on ISAKMP exchanges, and a digital | |||
| signature algorithm based on asymmetric cryptography is used | signature algorithm based on asymmetric cryptography is used | |||
| within ISAKMP's authentication component. | within ISAKMP's authentication component. | |||
| ISAKMP includes two "phases" of negotiation: the phase 1 | ISAKMP negotiations are conducted in two "phases": | |||
| negotiation establishes a basic security association to be used | - "Phase 1 negotiation". A phase 1 negotiation establishes a | |||
| for ISAKMP operations. Then, protected by the phase 1 association, | security association to be used by ISAKMP to protect its own | |||
| phase 2 negotiations are used to establish security associations | protocol operations. | |||
| for other protocols, such as ESP. | - "Phase 2 negotiation". A phase 2 negotiation (which is | |||
| protected by a security association that was established by a | ||||
| phase 1 negotiation) establishes a security association to be | ||||
| used to protect the operations of a protocol other than ISAKMP, | ||||
| such as ESP. | ||||
| $ Internet Society (ISOC) | $ Internet Society (ISOC) | |||
| (I) A professional society concerned with Internet development | (I) A professional society concerned with Internet development | |||
| (including technical Internet Standards); with how the Internet is | (including technical Internet Standards); with how the Internet is | |||
| and can be used; and with social, political, and technical issues | and can be used; and with social, political, and technical issues | |||
| that result. The ISOC Board of Trustees approves appointments to | that result. The ISOC Board of Trustees approves appointments to | |||
| the IAB from among nominees submitted by the IETF nominating | the IAB from among nominees submitted by the IETF nominating | |||
| committee. [R2026] | committee. (RFC 2026) | |||
| $ Internet Standard | $ Internet Standard | |||
| (I) A specification, approved by the IESG and published as an RFC, | (I) A specification, approved by the IESG and published as an RFC, | |||
| that is stable and well-understood, is technically competent, has | that is stable and well-understood, is technically competent, has | |||
| multiple, independent, and interoperable implementations with | multiple, independent, and interoperable implementations with | |||
| substantial operational experience, enjoys significant public | substantial operational experience, enjoys significant public | |||
| support, and is recognizably useful in some or all parts of the | support, and is recognizably useful in some or all parts of the | |||
| Internet. [R2026] (See: RFC.) | Internet. (RFC 2026) (Compare: RFC.) | |||
| Tutorial: The "Internet Standards Process" is an activity of the | Tutorial: The "Internet Standards Process" is an activity of the | |||
| ISOC and is organized and managed by the IAB and the IESG. The | ISOC and is organized and managed by the IAB and the IESG. The | |||
| process is concerned with all protocols, procedures, and | process is concerned with all protocols, procedures, and | |||
| conventions used in or by the Internet, whether or not they are | conventions used in or by the Internet, whether or not they are | |||
| part of the IPS. The "Internet Standards Track" has three levels | part of the IPS. The "Internet Standards Track" has three levels | |||
| of increasing maturity: Proposed Standard, Draft Standard, and | of increasing maturity: Proposed Standard, Draft Standard, and | |||
| Standard. (Compare: ISO, W3C.) | Standard. (Compare: ISO, W3C.) | |||
| $ Internet Standards document (ISD) | $ Internet Standards document (ISD) | |||
| (I) An RFC or an Internet-Draft that is produced as part of the | (I) An RFC or an Internet-Draft that is produced as part of the | |||
| Internet Standards Process [R2026]. (See: Internet Standard.) | Internet Standards Process (RFC 2026). (See: Internet Standard.) | |||
| Deprecated Usage: Neither the term nor the abbreviation is widely | Deprecated Usage: ISDs that use this term SHOULD state a | |||
| accepted; therefore, ISDs that use this term SHOULD state a | definition for it because neither the term nor the abbreviation is | |||
| definition for it. | widely accepted. | |||
| $ internetwork | $ internetwork | |||
| (I) A system of interconnected networks; a network of networks. | (I) A system of interconnected networks; a network of networks. | |||
| Usually shortened to "internet". (See: internet.) | Usually shortened to "internet". (See: internet, Internet.) | |||
| Tutorial: An internet is usually built using OSIRM layer 3 | Tutorial: An internet can be built using OSIRM Layer 3 gateways to | |||
| gateways to connect a set of subnetworks. When the subnetworks | implement connections between a set of similar subnetworks. With | |||
| differ in the layer 3 protocol service they provide, the gateways | dissimilar subnetworks, i.e., subnetworks that differ in the Layer | |||
| sometimes implement a uniform internetwork protocol (e.g., IP) | 3 protocol service they offer, an internet can be built by | |||
| that operates at the top of layer 3 and hides the underlying | implementing a uniform internetwork protocol (e.g., IP) that | |||
| heterogeneity from hosts that use communication services provided | operates at the top of Layer 3 and hides the underlying | |||
| by the internet. (See: router.) | subnetworks' heterogeneity from hosts that use communication | |||
| services provided by the internet. (See: router.) | ||||
| $ intranet | $ intranet | |||
| (I) A computer network, especially one based on Internet | (I) A computer network, especially one based on Internet | |||
| technology, that an organization uses for its own internal, and | technology, that an organization uses for its own internal (and | |||
| usually private, purposes and that is closed to outsiders. (See: | usually private) purposes and that is closed to outsiders. (See: | |||
| extranet, virtual private network.) | extranet, virtual private network.) | |||
| $ intruder | $ intruder | |||
| (I) An entity that gains or attempts to gain access to a system or | (I) An entity that gains or attempts to gain access to a system or | |||
| system resource without having authorization to do so. (See: | system resource without having authorization to do so. (See: | |||
| intrusion. Compare: adversary, cracker.) | intrusion. Compare: adversary, cracker.) | |||
| $ intrusion | $ intrusion | |||
| 1. (I) A security event, or a combination of multiple security | 1. (I) A security event, or a combination of multiple security | |||
| events, that constitutes a security incident in which an intruder | events, that constitutes a security incident in which an intruder | |||
| gains, or attempts to gain, access to a system or system resource | gains, or attempts to gain, access to a system or system resource | |||
| without having authorization to do so. (See: IDS.) | without having authorization to do so. (See: IDS.) | |||
| 2. (I) A type of threat action whereby an unauthorized entity | 2. (I) A type of threat action whereby an unauthorized entity | |||
| gains access to sensitive data by circumventing a system's | gains access to sensitive data by circumventing a system's | |||
| security protections. (See: unauthorized disclosure.) | security protections. (See: unauthorized disclosure.) | |||
| Usage: This type includes the following subtypes: | Usage: This type includes the following subtypes: | |||
| - "Trespass": Gaining physical access to sensitive data by | - "Trespass": Gaining physical access to sensitive data by | |||
| circumventing a system's protections. | circumventing a system's protections. | |||
| - "Penetration": Gaining logical access to sensitive data by | - "Penetration": Gaining logical access to sensitive data by | |||
| circumventing a system's protections. | circumventing a system's protections. | |||
| - "Reverse engineering": Acquiring sensitive data by | - "Reverse engineering": Acquiring sensitive data by | |||
| disassembling and analyzing the design of a system component. | disassembling and analyzing the design of a system component. | |||
| - "Cryptanalysis": Transforming encrypted data into plain text | - "Cryptanalysis": Transforming encrypted data into plain text | |||
| without having prior knowledge of encryption parameters or | without having prior knowledge of encryption parameters or | |||
| processes. (See: (main Glossary entry for) cryptanalysis.) | processes. (See: main entry for "cryptanalysis".) | |||
| $ intrusion detection | $ intrusion detection | |||
| (I) Sensing and analyzing system events for the purpose of | (I) Sensing and analyzing system events for the purpose of | |||
| noticing (i.e., becoming aware of) attempts to access system | noticing (i.e., becoming aware of) attempts to access system | |||
| resources in an unauthorized manner. (See: anomaly detection, IDS, | resources in an unauthorized manner. (See: anomaly detection, IDS, | |||
| misuse detection.) [IDSAN, IDSSC, IDSSE, IDSSY] | misuse detection.) [IDSAN, IDSSC, IDSSE, IDSSY] | |||
| Usage: This includes the following subtypes: | Usage: This includes the following subtypes: | |||
| - "Active detection": Real-time or near-real-time analysis of | - "Active detection": Real-time or near-real-time analysis of | |||
| system event data to detect current intrusions, which result in | system event data to detect current intrusions, which result in | |||
| an immediate protective response. | an immediate protective response. | |||
| - "Passive detection": Off-line analysis of audit data to detect | - "Passive detection": Off-line analysis of audit data to detect | |||
| past intrusions, which are reported to the system security | past intrusions, which are reported to the system security | |||
| officer for corrective action. (Compare: security audit.) | officer for corrective action. (Compare: security audit.) | |||
| $ intrusion detection system (IDS) | $ intrusion detection system (IDS) | |||
| 1. (N) A process or subsystem, implemented in software or | 1. (N) A process or subsystem, implemented in software or | |||
| hardware, that automates the tasks of (a) monitoring events that | hardware, that automates the tasks of (a) monitoring events that | |||
| occur in a computer network and (b) analyzing them for signs of | occur in a computer network and (b) analyzing them for signs of | |||
| security problems. [SP31] (See: intrusion detection.) | security problems. [SP31] (See: intrusion detection.) | |||
| 2. (N) A security alarm system to detect unauthorized entry. | 2. (N) A security alarm system to detect unauthorized entry. | |||
| [DC6/9]. | [DC6/9]. | |||
| Tutorial: Active intrusion detection processes can be either host- | Tutorial: Active intrusion detection processes can be either host- | |||
| based or network-based: | based or network-based: | |||
| - "Host-based": Intrusion detection components -- traffic sensors | - "Host-based": Intrusion detection components -- traffic sensors | |||
| and analyzers -- run directly on the hosts that they are | and analyzers -- run directly on the hosts that they are | |||
| intended to protect. | intended to protect. | |||
| - "Network-based": Sensors are placed on subnetwork components, | - "Network-based": Sensors are placed on subnetwork components, | |||
| and analysis components run either on subnetwork components or | and analysis components run either on subnetwork components or | |||
| hosts. | hosts. | |||
| $ invalidity date | $ invalidity date | |||
| (N) An X.509 CRL entry extension that "indicates the date at which | (N) An X.509 CRL entry extension that "indicates the date at which | |||
| it is known or suspected that the [revoked certificate's private | it is known or suspected that the [revoked certificate's private | |||
| key] was compromised or that the certificate should otherwise be | key] was compromised or that the certificate should otherwise be | |||
| considered invalid." [X509]. | considered invalid." [X509]. | |||
| Tutorial: This date may be earlier than the revocation date in the | Tutorial: This date may be earlier than the revocation date in the | |||
| CRL entry, and may even be earlier than the date of issue of | CRL entry, and may even be earlier than the date of issue of | |||
| earlier CRLs. However, the invalidity date is not, by itself, | earlier CRLs. However, the invalidity date is not, by itself, | |||
| sufficient for purposes of non-repudiation service. For example, | sufficient for purposes of non-repudiation service. For example, | |||
| to fraudulently repudiate a validly-generated signature, a private | to fraudulently repudiate a validly generated signature, a private | |||
| key holder may falsely claim that the key was compromised at some | key holder may falsely claim that the key was compromised at some | |||
| time in the past. | time in the past. | |||
| $ IOTP | $ IOTP | |||
| (I) See: Internet Open Trading Protocol. | (I) See: Internet Open Trading Protocol. | |||
| $ IP | $ IP | |||
| (I) See: Internet Protocol. | (I) See: Internet Protocol. | |||
| $ IP address | $ IP address | |||
| (I) A computer's internetwork address that is assigned for use by | (I) A computer's internetwork address that is assigned for use by | |||
| IP and other protocols. | IP and other protocols. | |||
| Tutorial: An IP version 4 address (RFC 791) is written as a series | Tutorial: An IP version 4 address (RFC 791) has four 8-bit parts | |||
| of four 8-bit numbers separated by periods. For example, the | and is written as a series of four decimal numbers separated by | |||
| address of the host named "rosslyn.bbn.com" is 192.1.7.10. | periods. Example: The address of the host named "rosslyn.bbn.com" | |||
| is 192.1.7.10. | ||||
| An IP version 6 address (RFC 2373) is written as x:x:x:x:x:x:x:x, | An IP version 6 address (RFC 2373) has eight 16-bit parts and is | |||
| where each "x" is the hexadecimal value of one of the eight 16-bit | written as eight hexadecimal numbers separated by colons. | |||
| parts of the address. For example, 1080:0:0:0:8:800:200C:417A and | Examples: 1080:0:0:0:8:800:200C:417A and | |||
| FEDC:BA98:7654:3210:FEDC:BA98:7654:3210. | FEDC:BA98:7654:3210:FEDC:BA98:7654:3210. | |||
| $ IP Security Option | $ IP Security Option | |||
| (I) See: Internet Protocol Security Option. | (I) See: Internet Protocol Security Option. | |||
| $ IPLI | $ IP Security Protocol (IPsec) | |||
| (I) See: Internet Private Line Interface. | 1a. (I) The name of the IETF working group that is specifying an | |||
| architecture [R2401] and set of protocols to provide security | ||||
| $ IPRA | services for IP traffic. (See: AH, ESP, IKE, SAD, SPD. Compare: | |||
| (I) See: Internet Policy Registration Authority. | IPSO.) | |||
| $ IPS | ||||
| (I) See: Internet Protocol Suite. | ||||
| $ IPsec | ||||
| 1a. (I) A contraction of "Internet Protocol security", the name of | ||||
| the IETF working group that is specifying an architecture [R2401] | ||||
| and set of protocols to provide security services for IP traffic. | ||||
| (See: AH, ESP, IKE, SAD, SPD. Compare: IPSO.) | ||||
| 1b. (I) A collective name for that IP security architecture and | 1b. (I) A collective name for the IP security architecture and | |||
| associated set of protocols. | associated set of protocols (primarily AH, ESP, and IKE). | |||
| Usage: Note that the letters "sec" are in lower case in "IPsec". | Usage: Note that the letters "sec" are in lower case in "IPsec". | |||
| Tutorial: The security services provided by IPsec include access | Tutorial: The security services provided by IPsec include access | |||
| control service, connectionless data integrity service, data | control service, connectionless data integrity service, data | |||
| origin authentication service, protection against replays | origin authentication service, protection against replays | |||
| (detection of the arrival of duplicate datagrams, within a | (detection of the arrival of duplicate datagrams, within a | |||
| constrained window), data confidentiality service, and limited | constrained window), data confidentiality service, and limited | |||
| traffic-flow confidentiality. IPsec specifies (a) security | traffic-flow confidentiality. IPsec specifies (a) security | |||
| protocols (AH and ESP), (b) security associations (what they are, | protocols (AH and ESP), (b) security associations (what they are, | |||
| how they work, how they are managed, and associated processing), | how they work, how they are managed, and associated processing), | |||
| (c) key management (IKE), and (d) algorithms for authentication | (c) key management (IKE), and (d) algorithms for authentication | |||
| and encryption. Implementation of IPsec is optional for IP version | and encryption. Implementation of IPsec is optional for IP version | |||
| 4, but mandatory for IP version 6. | 4, but mandatory for IP version 6. | |||
| $ IPLI | ||||
| (I) See: Internet Private Line Interface. | ||||
| $ IPRA | ||||
| (I) See: Internet Policy Registration Authority. | ||||
| $ IPS | ||||
| (I) See: Internet Protocol Suite. | ||||
| $ IPsec | ||||
| (I) See: IP Security Protocol. | ||||
| $ IPsec Key Exchange (IKE) | $ IPsec Key Exchange (IKE) | |||
| (I) An Internet, IPsec, key-establishment protocol [R2409] for | (I) An Internet, IPsec, key-establishment protocol [R2409] for | |||
| putting in place authenticated keying material (a) for use with | putting in place authenticated keying material (a) for use with | |||
| ISAKMP and (b) for other security associations, such as in AH and | ISAKMP and (b) for other security associations, such as in AH and | |||
| ESP. | ESP. | |||
| Tutorial: IKE is based on three earlier protocol designs: ISAKMP, | Tutorial: IKE is based on three earlier protocol designs: ISAKMP, | |||
| OAKLEY, and SKEME. | OAKLEY, and SKEME. | |||
| $ IPSO | $ IPSO | |||
| skipping to change at page 138, line 16 ¶ | skipping to change at page 146, line 48 ¶ | |||
| participate in developing international standards through ISO and | participate in developing international standards through ISO and | |||
| IEC technical committees that deal with particular fields of | IEC technical committees that deal with particular fields of | |||
| activity. Other international governmental and non-governmental | activity. Other international governmental and non-governmental | |||
| organizations, in liaison with ISO and IEC, also take part. (ANSI | organizations, in liaison with ISO and IEC, also take part. (ANSI | |||
| is the U.S. voting member of ISO. ISO is a class D member of | is the U.S. voting member of ISO. ISO is a class D member of | |||
| ITU-T.) | ITU-T.) | |||
| The ISO standards development process has four levels of | The ISO standards development process has four levels of | |||
| increasing maturity: Working Draft (WD), Committee Draft (CD), | increasing maturity: Working Draft (WD), Committee Draft (CD), | |||
| Draft International Standard (DIS), and International Standard | Draft International Standard (DIS), and International Standard | |||
| (IS). (Compare: (standards track levels under) Internet Standard.) | (IS). (Compare: "Internet Standards Track" under "Internet | |||
| In information technology, ISO and IEC have a joint technical | Standard".) In information technology, ISO and IEC have a joint | |||
| committee, ISO/IEC JTC 1. DISs adopted by JTC 1 are circulated to | technical committee, ISO/IEC JTC 1. DISs adopted by JTC 1 are | |||
| national bodies for voting, and publication as an IS requires | circulated to national bodies for voting, and publication as an IS | |||
| approval by at least 75% of the national bodies casting a vote. | requires approval by at least 75% of the national bodies casting a | |||
| vote. | ||||
| $ ISO 17799 | $ ISO 17799 | |||
| (N) An International Standard that is a code of practice, derived | (N) An International Standard that is a code of practice, derived | |||
| from Part 1 of British Standard 7799, for managing the security of | from Part 1 of British Standard 7799, for managing the security of | |||
| information systems in an organization. This standard does not | information systems in an organization. This standard does not | |||
| provide definitive or specific material on any security topic. It | provide definitive or specific material on any security topic. It | |||
| provides general guidance on a wide variety of topics, but | provides general guidance on a wide variety of topics, but | |||
| typically does not go into depth. (See: IATF, [SP14].) | typically does not go into depth. (See: IATF, [SP14].) | |||
| $ ISOC | $ ISOC | |||
| skipping to change at page 140, line 13 ¶ | skipping to change at page 148, line 44 ¶ | |||
| (I) See: key-encrypting key. (Compare: KAK.) | (I) See: key-encrypting key. (Compare: KAK.) | |||
| $ Kerberos | $ Kerberos | |||
| (N) A system developed at the Massachusetts Institute of | (N) A system developed at the Massachusetts Institute of | |||
| Technology that depends on passwords and symmetric cryptography | Technology that depends on passwords and symmetric cryptography | |||
| (DES) to implement ticket-based, peer entity authentication | (DES) to implement ticket-based, peer entity authentication | |||
| service and access control service distributed in a client-server | service and access control service distributed in a client-server | |||
| network environment. [R1510, Stei] | network environment. [R1510, Stei] | |||
| Tutorial: Kerberos was developed by Project Athena and is named | Tutorial: Kerberos was developed by Project Athena and is named | |||
| for the three-headed dog guarding Hades. The system architecture | for the mythical three-headed dog that guards Hades. The system | |||
| includes servers that function as an ACC and a KDC. | architecture includes servers that function as an ACC and a KDC. | |||
| $ kernel | $ kernel | |||
| (I) A small, trusted part of a system that provides services on | (I) A small, trusted part of a system that provides services on | |||
| which the other parts of the system depend. (See: security | which the other parts of the system depend. (See: security | |||
| kernel.) | kernel.) | |||
| $ Kernelized Secure Operating System (KSOS) | $ Kernelized Secure Operating System (KSOS) | |||
| (O) An MLS computer operating system, designed to be a provably | (O) An MLS computer operating system, designed to be a provably | |||
| secure replacement for UNIX Version 6, and consisting of a | secure replacement for UNIX Version 6, and consisting of a | |||
| security kernel, non-kernel security-related utility programs, and | security kernel, non-kernel security-related utility programs, and | |||
| optional UNIX application development and support environments. | optional UNIX application development and support environments. | |||
| [Perr] | [Perr] | |||
| Tutorial: KSOS-6 was the implementation on a SCOMP. KSOS-11 was | Tutorial: KSOS-6 was the implementation on a SCOMP. KSOS-11 was | |||
| the implementation by Ford Aerospace and Communications | the implementation by Ford Aerospace and Communications | |||
| Corporation on the DEC PDP-11/45 and PDP-111/70 computers. | Corporation on the DEC PDP-11/45 and PDP-111/70 computers. | |||
| $ key | $ key | |||
| 1. (I) /cryptography/ An input parameter used to vary a | 1. (I) /cryptography/ An input parameter used to vary a | |||
| transformation function performed by a cryptographic algorithm. | transformation function performed by a cryptographic algorithm. | |||
| (Compare: initialization value.) | (See: private key, public key, storage key, symmetric key, traffic | |||
| key. Compare: initialization value.) | ||||
| 2. (I) /anti-jam/ An input parameter used to vary a process that | 2. (I) /anti-jam/ An input parameter used to vary a process that | |||
| determines patterns for an anti-jam measure. (See: frequency | determines patterns for an anti-jam measure. (See: frequency | |||
| hopping, spread spectrum.) | hopping, spread spectrum.) | |||
| Tutorial: A key is usually specified as a sequence of bits or | Tutorial: A key is usually specified as a sequence of bits or | |||
| other symbols. If a key value needs to be kept secret, the | other symbols. If a key value needs to be kept secret, the | |||
| sequence of symbols that comprise it should be random, or at least | sequence of symbols that comprise it should be random, or at least | |||
| pseudorandom, because that makes the key hard for an adversary to | pseudorandom, because that makes the key harder for an adversary | |||
| guess. (See: cryptanalysis, brute force attack.) | to guess. (See: brute force attack, cryptanalysis, strength.) | |||
| $ key agreement (algorithm or protocol) | $ key agreement (algorithm or protocol) | |||
| 1. (I) A key establishment method (especially one involving | 1. (I) A key establishment method (especially one involving | |||
| asymmetric cryptography) by which two or more entities, without | asymmetric cryptography) by which two or more entities, without | |||
| prior arrangement except a public exchange of data (such as public | prior arrangement except a public exchange of data (such as public | |||
| keys), each can generate the same key value. That is, the method | keys), each can generate the same key value. That is, the method | |||
| does not send a secret from one entity to the other (compare: key | does not send a secret from one entity to the other; instead, both | |||
| transport); instead, both entities, without prior arrangement | entities, without prior arrangement except a public exchange of | |||
| except a public exchange of data, can compute the same secret | data, can compute the same secret value, but that value cannot be | |||
| value, but that value cannot be computed by other, unauthorized | computed by other, unauthorized entities. (See: Diffie-Hellman, | |||
| entities. (See: Diffie-Hellman, key establishment, KEA, MQV.) | key establishment, KEA, MQV. Compare: key transport.) | |||
| 2. (O) "A method for negotiating a key value on line without | 2. (O) "A method for negotiating a key value on line without | |||
| transferring the key, even in an encrypted form, e.g., the Diffie- | transferring the key, even in an encrypted form, e.g., the Diffie- | |||
| Hellman technique." [X509] | Hellman technique." [X509] | |||
| 3. (O) "The procedure whereby two different parties generate | 3. (O) "The procedure whereby two different parties generate | |||
| shared symmetric keys such that any of the shared symmetric keys | shared symmetric keys such that any of the shared symmetric keys | |||
| is a function of the information contributed by all legitimate | is a function of the information contributed by all legitimate | |||
| participants, so that no party [alone] can predetermine the value | participants, so that no party [alone] can predetermine the value | |||
| of the key." [A9042] | of the key." [A9042] | |||
| Example: A message originator and the intended recipient can each | Example: A message originator and the intended recipient can each | |||
| use their own private key and the other's public key with the | use their own private key and the other's public key with the | |||
| Diffie-Hellman algorithm to first compute a shared secret value | Diffie-Hellman algorithm to first compute a shared secret value | |||
| and, from that value, derive a session key to encrypt the message. | and, from that value, derive a session key to encrypt the message. | |||
| $ key authentication | $ key authentication | |||
| (N) "The assurance of the legitimate participants in a key | (N) "The assurance of the legitimate participants in a key | |||
| agreement that no non-legitimate party possesses the shared | agreement [i.e., in a key-agreement protocol] that no non- | |||
| symmetric key." [A9042] | legitimate party possesses the shared symmetric key." [A9042] | |||
| $ key-auto-key (KAK) | $ key-auto-key (KAK) | |||
| (D) "Cryptographic logic using previous key to produce key." | (D) "Cryptographic logic [i.e., a mode of operation] using | |||
| [C4009, A1523] (See: CTAK.) | previous key to produce key." [C4009, A1523] (See: CTAK, | |||
| /cryptographic operation/ under "mode".) | ||||
| Deprecated Term: IDS should not use this term; it is neither well- | Deprecated Term: IDS SHOULD NOT use this term; it is neither well- | |||
| known nor precisely defined. Instead, use terms associated with | known nor precisely defined. Instead, use terms associated with | |||
| modes that are defined in standards, such as CBC, CFB, and OFB. | modes that are defined in standards, such as CBC, CFB, and OFB. | |||
| $ key center | $ key center | |||
| (I) A centralized key distribution process (used in symmetric | (I) A centralized, key-distribution process (used in symmetric | |||
| cryptography), usually a separate computer system, that uses | cryptography), usually a separate computer system, that uses | |||
| master keys (i.e., KEKs) to encrypt and distribute session keys | master keys (i.e., KEKs) to encrypt and distribute session keys | |||
| needed in a community of users. | needed by a community of users. | |||
| Tutorial: An ANSI standard [A9017] defines two types of key | Tutorial: An ANSI standard [A9017] defines two types of key | |||
| center: key distribution center and key translation center. | center: "key distribution center" and "key translation center". | |||
| $ key confirmation | $ key confirmation | |||
| (N) "The assurance [provided to] the legitimate participants in a | (N) "The assurance [provided to] the legitimate participants in a | |||
| key establishment protocol that the [parties that are intended to | key establishment protocol that the [parties that are intended to | |||
| share] the symmetric key actually possess the shared symmetric | share] the symmetric key actually possess the shared symmetric | |||
| key." [A9042] | key." [A9042] | |||
| $ key distribution | $ key distribution | |||
| (I) A process that delivers a cryptographic key from the location | (I) A process that delivers a cryptographic key from the location | |||
| where it is generated to the locations where it is used in a | where it is generated to the locations where it is used in a | |||
| cryptographic algorithm. (See: key management.) | cryptographic algorithm. (See: key establishment, key management.) | |||
| $ key distribution center (KDC) | $ key distribution center (KDC) | |||
| 1. (I) A type of key center (used in symmetric cryptography) that | 1. (I) A type of key center (used in symmetric cryptography) that | |||
| implements a key distribution protocol to provide keys (usually, | implements a key-distribution protocol to provide keys (usually, | |||
| session keys) to two (or more) entities that wish to communicate | session keys) to two (or more) entities that wish to communicate | |||
| securely. (Compare: key translation center.) | securely. (Compare: key translation center.) | |||
| 2. (N) "COMSEC facility generating and distributing key in | 2. (N) "COMSEC facility generating and distributing key in | |||
| electrical form." [C4009] | electrical form." [C4009] | |||
| Tutorial: A KDC distributes keys to Alice and Bob, who (a) wish to | Tutorial: A KDC distributes keys to Alice and Bob, who (a) wish to | |||
| communicate with each other but do not currently share keys, (b) | communicate with each other but do not currently share keys, (b) | |||
| each share a KEK with the KDC, and (c) may not be able to generate | each share a KEK with the KDC, and (c) may not be able to generate | |||
| or acquire keys by themselves. Alice requests the keys from the | or acquire keys by themselves. Alice requests the keys from the | |||
| skipping to change at page 142, line 54 ¶ | skipping to change at page 151, line 37 ¶ | |||
| techniques. For example, the Escrowed Encryption Standard [FP185] | techniques. For example, the Escrowed Encryption Standard [FP185] | |||
| entrusts two components of a device-unique split key to separate | entrusts two components of a device-unique split key to separate | |||
| escrow agents. The agents provide the components only to someone | escrow agents. The agents provide the components only to someone | |||
| legally authorized to conduct electronic surveillance of | legally authorized to conduct electronic surveillance of | |||
| telecommunications encrypted by that specific device. The | telecommunications encrypted by that specific device. The | |||
| components are used to reconstruct the device-unique key, and it | components are used to reconstruct the device-unique key, and it | |||
| is used to obtain the session key needed to decrypt | is used to obtain the session key needed to decrypt | |||
| communications. | communications. | |||
| $ key establishment (algorithm or protocol) | $ key establishment (algorithm or protocol) | |||
| 1. (I) A procedure that combines the key generation and key | 1. (I) A procedure that combines the key generation and key- | |||
| distribution steps needed to set up or install a secure | distribution steps needed to set up or install a secure | |||
| communication association. | communication association. | |||
| 2. (I) A procedure that results in keying material being shared | 2. (I) A procedure that results in keying material being shared | |||
| among two or more system entities. [A9042, SP56] | among two or more system entities. [A9042, SP56] | |||
| Tutorial: The two basic techniques for key establishment are "key | Tutorial: The two basic techniques for key establishment are "key | |||
| agreement" and "key transport". | agreement" and "key transport". | |||
| $ Key Exchange Algorithm (KEA) | $ Key Exchange Algorithm (KEA) | |||
| (N) A key-agreement method [SKIP, R2773] based on the Diffie- | (N) A key-agreement method [SKIP, R2773] that is based on the | |||
| Hellman algorithm and uses 1024-bit asymmetric keys. (See: | Diffie-Hellman algorithm and uses 1024-bit asymmetric keys. (See: | |||
| CAPSTONE, CLIPPER, FORTEZZA, SKIPJACK.) | CAPSTONE, CLIPPER, FORTEZZA, SKIPJACK.) | |||
| Tutorial: KEA was developed by NSA and formerly classified at the | Tutorial: KEA was developed by NSA and formerly classified at the | |||
| U.S. DoD "Secret" level. On 23 June 1998, the NSA announced that | U.S. DoD "Secret" level. On 23 June 1998, the NSA announced that | |||
| KEA had been declassified. | KEA had been declassified. | |||
| $ key generation | $ key generation | |||
| (I) A process that creates the sequence of symbols that comprise a | (I) A process that creates the sequence of symbols that comprise a | |||
| cryptographic key. (See: key management.) | cryptographic key. (See: key management.) | |||
| skipping to change at page 143, line 41 ¶ | skipping to change at page 152, line 25 ¶ | |||
| mechanism and applies the key to plain text to produce cipher text | mechanism and applies the key to plain text to produce cipher text | |||
| (e.g., by exclusive OR-ing (a) a bit string representation of the | (e.g., by exclusive OR-ing (a) a bit string representation of the | |||
| key with (b) a bit string representation of the plaintext). | key with (b) a bit string representation of the plaintext). | |||
| $ key length | $ key length | |||
| (I) The number of symbols (usually stated as a number of bits) | (I) The number of symbols (usually stated as a number of bits) | |||
| needed to be able to represent any of the possible values of a | needed to be able to represent any of the possible values of a | |||
| cryptographic key. (See: key space.) | cryptographic key. (See: key space.) | |||
| $ key lifetime | $ key lifetime | |||
| (N) /MISSI/ An attribute of a MISSI key pair that specifies a time | 1. (D) Synonym for "cryptoperiod". | |||
| span that bounds the validity period of any MISSI X.509 public-key | ||||
| certificate that contains the public component of the pair. (See: | Deprecated Definition: ISDs SHOULD NOT use this term with this | |||
| cryptoperiod.) | definition because a key's cryptoperiod may be only a part of the | |||
| key's lifetime. A key could be generated at some time prior to | ||||
| when its cryptoperiod begins and might not be destroyed (i.e., | ||||
| zeroized) until some time after its cryptoperiod ends. | ||||
| 2. (O) /MISSI/ An attribute of a MISSI key pair that specifies a | ||||
| time span that bounds the validity period of any MISSI X.509 | ||||
| public-key certificate that contains the public component of the | ||||
| pair. (See: cryptoperiod.) | ||||
| $ key loader | $ key loader | |||
| (N) Synonym for "fill device". | (N) Synonym for "fill device". | |||
| $ key management | $ key management | |||
| 1a. (I) The process of handling keying material during its life | 1a. (I) The process of handling keying material during its life | |||
| cycle in a cryptographic system; and the supervision and control | cycle in a cryptographic system; and the supervision and control | |||
| of that process. (See: key distribution, key escrow, keying | of that process. (See: key distribution, key escrow, keying | |||
| material, public-key infrastructure.) | material, public-key infrastructure.) | |||
| skipping to change at page 144, line 37 ¶ | skipping to change at page 153, line 28 ¶ | |||
| $ key pair | $ key pair | |||
| (I) A set of mathematically related keys -- a public key and a | (I) A set of mathematically related keys -- a public key and a | |||
| private key -- that are used for asymmetric cryptography and are | private key -- that are used for asymmetric cryptography and are | |||
| generated in a way that makes it computationally infeasible to | generated in a way that makes it computationally infeasible to | |||
| derive the private key from knowledge of the public key. (See: | derive the private key from knowledge of the public key. (See: | |||
| Diffie-Hellman, RSA.) | Diffie-Hellman, RSA.) | |||
| Tutorial: A key pair's owner discloses the public key to other | Tutorial: A key pair's owner discloses the public key to other | |||
| system entities so they can use the key to (a) encrypt data, (b) | system entities so they can use the key to (a) encrypt data, (b) | |||
| verify a digital signature, (c) compute a protected checksum, or | verify a digital signature, or (c) generate a key with a key- | |||
| (d) generate a key in a key agreement algorithm. The matching | agreement algorithm. The matching private key is kept secret by | |||
| private key is kept secret by the owner, who uses it to (a') | the owner, who uses it to (a') decrypt data, (b') generate a | |||
| decrypt data, (b') generate a digital signature, (c') verify a | digital signature, or (c') generate a key with a key-agreement | |||
| protected checksum, or (d') generate a key in a key agreement | ||||
| algorithm. | algorithm. | |||
| $ key recovery | $ key recovery | |||
| 1. (I) /cryptanalysis/ A process for learning the value of a | 1. (I) /cryptanalysis/ A process for learning the value of a | |||
| cryptographic key that was previously used to perform some | cryptographic key that was previously used to perform some | |||
| cryptographic operation. (See: cryptanalysis, recovery.) | cryptographic operation. (See: cryptanalysis, recovery.) | |||
| 2. (I) /backup/ Techniques that provide an intentional, alternate, | 2. (I) /backup/ Techniques that provide an intentional, alternate, | |||
| means to access the key used for data confidentiality service in | means to access the key used for data confidentiality service in | |||
| an encrypted association. [DoD4] (Compare: recovery.) | an encrypted association. [DoD4] (Compare: recovery.) | |||
| skipping to change at page 145, line 13 ¶ | skipping to change at page 153, line 55 ¶ | |||
| algorithm or protocol. For the secondary means, there are two | algorithm or protocol. For the secondary means, there are two | |||
| classes of key recovery techniques: key encapsulation and key | classes of key recovery techniques: key encapsulation and key | |||
| escrow. | escrow. | |||
| $ key space | $ key space | |||
| (I) The range of possible values of a cryptographic key; or the | (I) The range of possible values of a cryptographic key; or the | |||
| number of distinct transformations supported by a particular | number of distinct transformations supported by a particular | |||
| cryptographic algorithm. (See: key length.) | cryptographic algorithm. (See: key length.) | |||
| $ key translation center | $ key translation center | |||
| (I) A type of key center that implements a key distribution | (I) A type of key center that implements a key-distribution | |||
| protocol (based on symmetric cryptography) to convey keys between | protocol (based on symmetric cryptography) to convey keys between | |||
| two (or more) parties who wish to communicate securely. (Compare: | two (or more) parties who wish to communicate securely. (Compare: | |||
| key distribution center.) | key distribution center.) | |||
| Tutorial: A key translation center transfers keys for future | Tutorial: A key translation center transfers keys for future | |||
| communication between Bob and Alice, who (a) wish to communicate | communication between Bob and Alice, who (a) wish to communicate | |||
| with each other but do not currently share keys, (b) each share a | with each other but do not currently share keys, (b) each share a | |||
| KEK with the center, and (c) have the ability to generate or | KEK with the center, and (c) have the ability to generate or | |||
| acquire keys by themselves. Alice generates or acquires a set of | acquire keys by themselves. Alice generates or acquires a set of | |||
| keys for communication with Bob. Alice encrypts the set in the KEK | keys for communication with Bob. Alice encrypts the set in the KEK | |||
| skipping to change at page 146, line 31 ¶ | skipping to change at page 155, line 20 ¶ | |||
| (I) A cryptographic hash (e.g., [R1828]) in which the mapping to a | (I) A cryptographic hash (e.g., [R1828]) in which the mapping to a | |||
| hash result is varied by a second input parameter that is a | hash result is varied by a second input parameter that is a | |||
| cryptographic key. (See: checksum.) | cryptographic key. (See: checksum.) | |||
| Tutorial: If the input data object is changed, a new, | Tutorial: If the input data object is changed, a new, | |||
| corresponding hash result cannot be correctly computed without | corresponding hash result cannot be correctly computed without | |||
| knowledge of the secret key. Thus, the secret key protects the | knowledge of the secret key. Thus, the secret key protects the | |||
| hash result so it can be used as a checksum even when there is a | hash result so it can be used as a checksum even when there is a | |||
| threat of an active attack on the data. There are two basic types | threat of an active attack on the data. There are two basic types | |||
| of keyed hash: | of keyed hash: | |||
| - A function based on a keyed encryption algorithm. Example: Data | - A function based on a keyed encryption algorithm. Example: Data | |||
| Authentication Code. | Authentication Code. | |||
| - A function based on a keyless hash that is enhanced by | - A function based on a keyless hash that is enhanced by | |||
| combining (e.g., by concatenating) the input data object | combining (e.g., by concatenating) the input data object | |||
| parameter with a key parameter before mapping to the hash | parameter with a key parameter before mapping to the hash | |||
| result. Example: HMAC. | result. Example: HMAC. | |||
| $ keying material | $ keying material | |||
| (I) Data that is needed to establish and maintain a cryptographic | (I) Data that is needed to establish and maintain a cryptographic | |||
| security association, such as keys, key pairs, and IVs. | security association, such as keys, key pairs, and IVs. | |||
| (O) "Key, code, or authentication information in physical or | (O) "Key, code, or authentication information in physical or | |||
| magnetic form." [C4009] (Compare: COMSEC material.) | magnetic form." [C4009] (Compare: COMSEC material.) | |||
| skipping to change at page 146, line 46 ¶ | skipping to change at page 155, line 35 ¶ | |||
| result. Example: HMAC. | result. Example: HMAC. | |||
| $ keying material | $ keying material | |||
| (I) Data that is needed to establish and maintain a cryptographic | (I) Data that is needed to establish and maintain a cryptographic | |||
| security association, such as keys, key pairs, and IVs. | security association, such as keys, key pairs, and IVs. | |||
| (O) "Key, code, or authentication information in physical or | (O) "Key, code, or authentication information in physical or | |||
| magnetic form." [C4009] (Compare: COMSEC material.) | magnetic form." [C4009] (Compare: COMSEC material.) | |||
| $ keying material identifier (KMID) | $ keying material identifier (KMID) | |||
| 1. (I) An identifier assigned to an item of keying material. | 1. (I) An identifier assigned to an item of keying material. | |||
| 2. (O) /MISSI/ A 64-bit identifier that is assigned to a key pair | 2. (O) /MISSI/ A 64-bit identifier that is assigned to a key pair | |||
| when the public key is bound in a MISSI X.509 public-key | when the public key is bound in a MISSI X.509 public-key | |||
| certificate. | certificate. | |||
| $ Khafre | $ Khafre | |||
| (N) A patented, symmetric block cipher designed by Ralph C. Merkle | (N) A patented, symmetric block cipher designed by Ralph C. Merkle | |||
| as a plug-in replacement for DES. [Schn] | as a plug-in replacement for DES. [Schn] | |||
| Tutorial: Khafre was designed for efficient encryption of small | Tutorial: Khafre was designed for efficient encryption of small | |||
| amounts of data. However, because Khafre does not precompute | amounts of data. However, because Khafre does not precompute | |||
| tables used for encryption, it is slower than Khufu for large | tables used for encryption, it is slower than Khufu for large | |||
| amounts of data. | amounts of data. | |||
| $ Khufu | $ Khufu | |||
| (N) A patented, symmetric block cipher designed by Ralph C. Merkle | (N) A patented, symmetric block cipher designed by Ralph C. Merkle | |||
| as a plug-in replacement for DES. [Schn] | as a plug-in replacement for DES. [Schn] | |||
| Tutorial: Khufu was designed for fast encryption of large amounts | Tutorial: Khufu was designed for fast encryption of large amounts | |||
| of data. However, because Khufu precomputes tables used in | of data. However, because Khufu precomputes tables used in | |||
| encryption, it is less efficient that Khafre for small amounts of | encryption, it is less efficient that Khafre for small amounts of | |||
| data. | data. | |||
| $ KMID | $ KMID | |||
| (I) See: keying material identifier. | (I) See: keying material identifier. | |||
| $ known-plaintext attack | $ known-plaintext attack | |||
| (I) A cryptanalysis technique in which the analyst tries to | (I) A cryptanalysis technique in which the analyst tries to | |||
| determine the key from knowledge of some plaintext-ciphertext | determine the key from knowledge of some plaintext-ciphertext | |||
| pairs (although the analyst may also have other clues, such as the | pairs (although the analyst may also have other clues, such as | |||
| knowing the cryptographic algorithm). | knowing the cryptographic algorithm). | |||
| $ KSOS, KSOS-6, KSOS-11 | $ KSOS, KSOS-6, KSOS-11 | |||
| (O) See: Kernelized Secure Operating System. | (O) See: Kernelized Secure Operating System. | |||
| $ L2F | $ L2F | |||
| (N) See: Layer 2 Forwarding Protocol. | (N) See: Layer 2 Forwarding Protocol. | |||
| $ L2TP | $ L2TP | |||
| (N) See: Layer 2 Tunneling Protocol. | (N) See: Layer 2 Tunneling Protocol. | |||
| $ label | $ label | |||
| See: time stamp, security label. | See: time stamp, security label. | |||
| $ laboratory attack | $ laboratory attack | |||
| (O) "Use of sophisticated signal recovery equipment in a | (O) "Use of sophisticated signal recovery equipment in a | |||
| laboratory environment to recover information from data storage | laboratory environment to recover information from data storage | |||
| media." [C4009] | media." [C4009] | |||
| $ LAN | $ LAN | |||
| (I) Local area network. | (I) local area network. | |||
| $ land attack | $ land attack | |||
| (I) A denial-of-service attack that sends an IP packet that (a) | (I) A denial-of-service attack that sends an IP packet that (a) | |||
| has the same address in both the Source Address and Destination | has the same address in both the Source Address and Destination | |||
| Address fields and (b) contains a TCP SYN packet that has the same | Address fields and (b) contains a TCP SYN packet that has the same | |||
| port number in both the Source Port and Destination Port fields. | port number in both the Source Port and Destination Port fields. | |||
| Derivation: This single-packet attack was named for "land", the | Derivation: This single-packet attack was named for "land", the | |||
| program originally published by the cracker who invented this | program originally published by the cracker who invented this | |||
| exploit. Perhaps that name was chosen because the inventor thought | exploit. Perhaps that name was chosen because the inventor thought | |||
| skipping to change at page 148, line 29 ¶ | skipping to change at page 157, line 18 ¶ | |||
| finite set X of hierarchically ordered classification levels X(1), | finite set X of hierarchically ordered classification levels X(1), | |||
| non-hierarchical categories C(1), ..., C(M) -- together with the | non-hierarchical categories C(1), ..., C(M) -- together with the | |||
| "dominate" relation. Security level (x,c) is said to "dominate" | "dominate" relation. Security level (x,c) is said to "dominate" | |||
| (x',c') if and only if (a) x is greater (higher) than or equal to | (x',c') if and only if (a) x is greater (higher) than or equal to | |||
| x' and (b) c includes at least all of the elements of c'. (See: | x' and (b) c includes at least all of the elements of c'. (See: | |||
| dominate, lattice model.) | dominate, lattice model.) | |||
| $ lattice model | $ lattice model | |||
| 1. (I) A description of the semantic structure formed by a finite | 1. (I) A description of the semantic structure formed by a finite | |||
| set of security levels, such as those used in military | set of security levels, such as those used in military | |||
| organizations. (See: dominate, security model.) | organizations. (See: dominate, lattice, security model.) | |||
| 2. (I) /formal model/ A model for flow control in a system, based | 2. (I) /formal model/ A model for flow control in a system, based | |||
| on the lattice that is formed by the finite security levels in a | on the lattice that is formed by the finite security levels in a | |||
| system and their partial ordering. [Denn] | system and their partial ordering. [Denn] | |||
| $ Law Enforcement Access Field (LEAF) | $ Law Enforcement Access Field (LEAF) | |||
| (N) A data item that is automatically embedded in data encrypted | (N) A data item that is automatically embedded in data encrypted | |||
| by devices (e.g., CLIPPER chip) that implement the Escrowed | by devices (e.g., CLIPPER chip) that implement the Escrowed | |||
| Encryption Standard. | Encryption Standard. | |||
| $ layer 1, 2, 3, 4, 5, 6, 7 | $ Layer 1, 2, 3, 4, 5, 6, 7 | |||
| (N) See: OSIRM. | (N) See: OSIRM. | |||
| $ Layer 2 Forwarding Protocol (L2F) | $ Layer 2 Forwarding Protocol (L2F) | |||
| (N) An Internet protocol (originally developed by Cisco | (N) An Internet protocol (originally developed by Cisco | |||
| Corporation) that uses tunneling of PPP over IP to create a | Corporation) that uses tunneling of PPP over IP to create a | |||
| virtual extension of a dial-up link across a network, initiated by | virtual extension of a dial-up link across a network, initiated by | |||
| the dial-up server and transparent to the dial-up user. (See: | the dial-up server and transparent to the dial-up user. (See: | |||
| L2TP.) | L2TP.) | |||
| $ Layer 2 Tunneling Protocol (L2TP) | $ Layer 2 Tunneling Protocol (L2TP) | |||
| (N) An Internet client-server protocol that combines aspects of | (N) An Internet client-server protocol that combines aspects of | |||
| PPTP and L2F and supports tunneling of PPP over an IP network or | PPTP and L2F and supports tunneling of PPP over an IP network or | |||
| over frame relay or other switched network. (See: virtual private | over frame relay or other switched network. (See: virtual private | |||
| network.) | network.) | |||
| Tutorial: PPP can in turn encapsulate any OSIRM layer 3 protocol. | ||||
| Tutorial: PPP can in turn encapsulate any OSIRM Layer 3 protocol. | ||||
| Thus, L2TP does not specify security services; it depends on | Thus, L2TP does not specify security services; it depends on | |||
| protocols layered above and below it to provide any needed | protocols layered above and below it to provide any needed | |||
| security. | security. | |||
| $ LDAP | $ LDAP | |||
| (I) See: Lightweight Directory Access Protocol. | (I) See: Lightweight Directory Access Protocol. | |||
| $ least common mechanism | $ least common mechanism | |||
| (I) The principle that a security architecture should minimize | (I) The principle that a security architecture should minimize | |||
| reliance on mechanisms that are shared by many users. | reliance on mechanisms that are shared by many users. | |||
| skipping to change at page 149, line 46 ¶ | skipping to change at page 158, line 35 ¶ | |||
| (I) The principle that a security architecture should be designed | (I) The principle that a security architecture should be designed | |||
| in a way that minimizes (a) the number of components that require | in a way that minimizes (a) the number of components that require | |||
| trust and (b) the extent to which each component is trusted. | trust and (b) the extent to which each component is trusted. | |||
| (Compare: least privilege, trust level.) | (Compare: least privilege, trust level.) | |||
| $ legacy system | $ legacy system | |||
| (I) A system that is in operation but will not be improved or | (I) A system that is in operation but will not be improved or | |||
| expanded while a new system is being developed to supersede it. | expanded while a new system is being developed to supersede it. | |||
| $ legal non-repudiation | $ legal non-repudiation | |||
| (I) See: (secondary definition under) non-repudiation. | (I) See: secondary definition under "non-repudiation". | |||
| $ level of concern | $ level of concern | |||
| (N) /U.S. DoD/ A rating assigned to an information system that | (N) /U.S. DoD/ A rating assigned to an information system that | |||
| indicates the extent to which protective measures, techniques, and | indicates the extent to which protective measures, techniques, and | |||
| procedures must be applied. (See: level of robustness.) | procedures must be applied. (See: critical, sensitive, level of | |||
| robustness.) | ||||
| $ level of robustness | $ level of robustness | |||
| (N) /U.S. DoD/ A characterization of the strength of a security | (N) /U.S. DoD/ A characterization of the strength of a security | |||
| function, mechanism, service, or solution, and the assurance (or | function, mechanism, service, or solution, and the assurance (or | |||
| confidence) that is implemented and functioning correctly to | confidence) that is implemented and functioning. [Cons, IATF] | |||
| support the level of concern assigned to a particular information | (See: level of concern.) | |||
| system. | ||||
| $ Lightweight Directory Access Protocol (LDAP) | $ Lightweight Directory Access Protocol (LDAP) | |||
| (I) An Internet client-server protocol (RFC 3377) that supports | (I) An Internet client-server protocol (RFC 3377) that supports | |||
| basic use of the X.500 Directory (or other directory servers) | basic use of the X.500 Directory (or other directory servers) | |||
| without incurring the resource requirements of the full Directory | without incurring the resource requirements of the full Directory | |||
| Access Protocol (DAP). | Access Protocol (DAP). | |||
| Tutorial: Designed for simple management and browser applications | Tutorial: Designed for simple management and browser applications | |||
| that provide simple read/write interactive directory service. | that provide simple read/write interactive directory service. | |||
| Supports both simple authentication and strong authentication of | Supports both simple authentication and strong authentication of | |||
| the client to the directory server. | the client to the directory server. | |||
| $ link | $ link | |||
| 1a. (I) A communication facility or physical medium that can | 1a. (I) A communication facility or physical medium that can | |||
| sustain data communications between multiple network nodes, in the | sustain data communications between multiple network nodes, in the | |||
| protocol layer immediately below IP. [R3573] | protocol layer immediately below IP. (RFC 3753) | |||
| 1b. (I) /subnetwork/ A communication channel connecting subnetwork | 1b. (I) /subnetwork/ A communication channel connecting subnetwork | |||
| relays (especially one between two packet switches) that is | relays (especially one between two packet switches) that is | |||
| implemented at OSIRM layer 2. (See: link encryption.) | implemented at OSIRM Layer 2. (See: link encryption.) | |||
| Tutorial: The relay computers assume that links are logically | Tutorial: The relay computers assume that links are logically | |||
| passive. If a computer at one end of a link sends a sequence of | passive. If a computer at one end of a link sends a sequence of | |||
| bits, the sequence simply arrives at the other end after a finite | bits, the sequence simply arrives at the other end after a finite | |||
| time, although some bits may have been changed either accidentally | time, although some bits may have been changed either accidentally | |||
| (errors) or by active wiretapping. | (errors) or by active wiretapping. | |||
| 2. (I) /World Wide Web/ See: hyperlink. | 2. (I) /World Wide Web/ See: hyperlink. | |||
| $ link encryption | $ link encryption | |||
| (I) Stepwise (link-by-link) protection of data that flows between | (I) Stepwise (link-by-link) protection of data that flows between | |||
| two points in a network, provided by encrypting data separately on | two points in a network, provided by encrypting data separately on | |||
| each network link, i.e., by encrypting data when it leaves a host | each network link, i.e., by encrypting data when it leaves a host | |||
| or subnetwork relay and decrypting when it arrives at the next | or subnetwork relay and decrypting when it arrives at the next | |||
| host or relay. Each link may use a different key or even a | host or relay. Each link may use a different key or even a | |||
| different algorithm. [R1455] (Compare: end-to-end encryption.) | different algorithm. [R1455] (Compare: end-to-end encryption.) | |||
| $ liveness | ||||
| (I) A property of a communication association or a feature of a | ||||
| communication protocol that provides assurance to the recipient of | ||||
| data that the data is being freshly transmitted by its originator, | ||||
| i.e., that the data is not being replayed, by either the | ||||
| originator or a third party, from a previous transmission. (See: | ||||
| nonce, replay attack.) | ||||
| $ logic bomb | $ logic bomb | |||
| (I) Malicious logic that activates when specified conditions are | (I) Malicious logic that activates when specified conditions are | |||
| met. Usually intended to cause denial of service or otherwise | met. Usually intended to cause denial of service or otherwise | |||
| damage system resources. (See: Trojan horse, virus, worm.) | damage system resources. (See: Trojan horse, virus, worm.) | |||
| $ login | $ login | |||
| (I) The act by which a system entity establishes a session in | (I) The act by which a system entity establishes a session in | |||
| which the entity can use system resources. (See: principal, | which the entity can use system resources. (See: principal, | |||
| session.) | session.) | |||
| skipping to change at page 151, line 30 ¶ | skipping to change at page 160, line 27 ¶ | |||
| $ low probability of intercept | $ low probability of intercept | |||
| (I) Result of TRANSEC measures used to prevent interception of a | (I) Result of TRANSEC measures used to prevent interception of a | |||
| communication. | communication. | |||
| $ LOTOS | $ LOTOS | |||
| (N) See: Language of Temporal Ordering Specification. | (N) See: Language of Temporal Ordering Specification. | |||
| $ MAC | $ MAC | |||
| (N) See: mandatory access control, Message Authentication Code. | (N) See: mandatory access control, Message Authentication Code. | |||
| Deprecated Usage: This abbreviation is ambiguous; therefore, ISDs | Deprecated Usage: ISDs that use this term SHOULD state a | |||
| that use it SHOULD state a definition for it. | definition for it because this abbreviation is ambiguous. | |||
| $ magnetic remanence | $ magnetic remanence | |||
| (N) Magnetic representation of residual information remaining on a | (N) Magnetic representation of residual information remaining on a | |||
| magnetic medium after the medium has been cleared. [NCS25] (See: | magnetic medium after the medium has been cleared. [NCS25] (See: | |||
| clear, degauss, purge.) | clear, degauss, purge.) | |||
| $ main mode | ||||
| (I) See: /IKE/ under "mode". | ||||
| $ maintenance hook | $ maintenance hook | |||
| (N) "Special instructions (trapdoors) in software allowing easy | (N) "Special instructions (trapdoors) in software allowing easy | |||
| maintenance and additional feature development. Since maintenance | maintenance and additional feature development. Since maintenance | |||
| hooks frequently allow entry into the code without the usual | hooks frequently allow entry into the code without the usual | |||
| checks, they are a serious security risk if they are not removed | checks, they are a serious security risk if they are not removed | |||
| prior to live implementation." [C4009] (See: back door.) | prior to live implementation." [C4009] (See: back door.) | |||
| $ malicious logic | $ malicious logic | |||
| (I) Hardware, software, or firmware that is intentionally included | (I) Hardware, firmware, or software that is intentionally included | |||
| or inserted in a system for a harmful purpose. (See: logic bomb, | or inserted in a system for a harmful purpose. (See: logic bomb, | |||
| Trojan horse, spyware, virus, worm. Compare: (secondary | Trojan horse, spyware, virus, worm. Compare: secondary definitions | |||
| definitions under) corruption, incapacitation, masquerade, and | under "corruption", "incapacitation", "masquerade", and "misuse".) | |||
| misuse.) | ||||
| $ malware | $ malware | |||
| (D) A contraction of "malicious software". (See: malicious logic.) | (D) A contraction of "malicious software". (See: malicious logic.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it is not listed | Deprecated Term: ISDs SHOULD NOT use this term; it is not listed | |||
| in most dictionaries and could confuse international readers. | in most dictionaries and could confuse international readers. | |||
| $ MAN | $ MAN | |||
| (I) metropolitan area network. | (I) metropolitan area network. | |||
| skipping to change at page 153, line 10 ¶ | skipping to change at page 162, line 9 ¶ | |||
| "checksum"; the word "manipulation" implies protection against | "checksum"; the word "manipulation" implies protection against | |||
| active attacks, which an ordinary checksum might not provide. | active attacks, which an ordinary checksum might not provide. | |||
| Instead, if such protection is intended, use "protected checksum" | Instead, if such protection is intended, use "protected checksum" | |||
| or some particular type thereof, depending on which is meant. If | or some particular type thereof, depending on which is meant. If | |||
| such protection is not intended, use "error detection code" or | such protection is not intended, use "error detection code" or | |||
| some specific type of checksum that is not protected. | some specific type of checksum that is not protected. | |||
| $ marking | $ marking | |||
| See: time stamp, security marking. | See: time stamp, security marking. | |||
| $ MARS | ||||
| (O) A symmetric, 128-bit block cipher with variable key length | ||||
| (128 to 448 bits), developed by IBM as a candidate for the AES. | ||||
| $ Martian | $ Martian | |||
| (D) A packet that arrives unexpectedly at the wrong address or on | (D) /slang/ A packet that arrives unexpectedly at the wrong | |||
| the wrong network because of incorrect routing or because it has a | address or on the wrong network because of incorrect routing or | |||
| non-registered or ill-formed IP address. | because it has a non-registered or ill-formed IP address. | |||
| Deprecated Term: It is likely that other cultures have different | Deprecated Term: It is likely that other cultures use different | |||
| metaphors for this concept. Therefore, to ensure international | metaphors for this concept. Therefore, to avoid international | |||
| understanding, ISDs SHOULD NOT use this term. (See: (Deprecated | misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated | |||
| Usage under) Green Book.) | Usage under "Green Book".) | |||
| $ masquerade | $ masquerade | |||
| (I) A type of threat action whereby an unauthorized entity gains | (I) A type of threat action whereby an unauthorized entity gains | |||
| access to a system or performs a malicious act by illegitimately | access to a system or performs a malicious act by illegitimately | |||
| posing as an authorized entity. (See: deception.) | posing as an authorized entity. (See: deception.) | |||
| Usage: This type includes the following subtypes: | Usage: This type includes the following subtypes: | |||
| - "Spoof": Attempt by an unauthorized entity to gain access to a | - "Spoof": Attempt by an unauthorized entity to gain access to a | |||
| system by posing as an authorized user. | system by posing as an authorized user. | |||
| - "Malicious logic": In context of masquerade, any hardware, | - "Malicious logic": In context of masquerade, any hardware, | |||
| firmware, or software (e.g., Trojan horse) that appears to | firmware, or software (e.g., Trojan horse) that appears to | |||
| perform a useful or desirable function, but actually gains | perform a useful or desirable function, but actually gains | |||
| unauthorized access to system resources or tricks a user into | unauthorized access to system resources or tricks a user into | |||
| executing other malicious logic. (See: (main entry for) | executing other malicious logic. (See: corruption, | |||
| malicious logic.) | incapacitation, main entry for "malicious logic", misuse.) | |||
| $ MCA | $ MCA | |||
| (O) See: merchant certification authority. | (O) See: merchant certification authority. | |||
| $ MD2 | $ MD2 | |||
| (N) A cryptographic hash [R1319] that produces a 128-bit hash | (N) A cryptographic hash [R1319] that produces a 128-bit hash | |||
| result, was designed by Ron Rivest, and is similar to MD4 and MD5 | result, was designed by Ron Rivest, and is similar to MD4 and MD5 | |||
| but slower. | but slower. | |||
| Derivation: Apparently an abbreviation of "message digest", but | Derivation: Apparently an abbreviation of "message digest", but | |||
| that term is deprecated by this Glossary. | that term is deprecated by this Glossary. | |||
| $ MD4 | $ MD4 | |||
| (N) A cryptographic hash [R1320] that produces a 128-bit hash | (N) A cryptographic hash [R1320] that produces a 128-bit hash | |||
| result and was designed by Ron Rivest. (See: SHA-1, (Derivation | result and was designed by Ron Rivest. (See: Derivation under | |||
| under) MD2.) | "MD2", SHA-1.) | |||
| $ MD5 | $ MD5 | |||
| (N) A cryptographic hash [R1321] that produces a 128-bit hash | (N) A cryptographic hash [R1321] that produces a 128-bit hash | |||
| result and was designed by Ron Rivest to be an improved version of | result and was designed by Ron Rivest to be an improved version of | |||
| MD4. (See: (Derivation under) MD2.) | MD4. (See: Derivation under "MD2".) | |||
| $ merchant | $ merchant | |||
| (O) /SET/ "A seller of goods, services, and/or other information | (O) /SET/ "A seller of goods, services, and/or other information | |||
| who accepts payment for these items electronically." [SET2] A | who accepts payment for these items electronically." [SET2] A | |||
| merchant may also provide electronic selling services and/or | merchant may also provide electronic selling services and/or | |||
| electronic delivery of items for sale. With SET, the merchant can | electronic delivery of items for sale. With SET, the merchant can | |||
| offer its cardholders secure electronic interactions, but a | offer its cardholders secure electronic interactions, but a | |||
| merchant that accepts payment cards is required to have a | merchant that accepts payment cards is required to have a | |||
| relationship with an acquirer. [SET1, SET2] | relationship with an acquirer. [SET1, SET2] | |||
| skipping to change at page 154, line 40 ¶ | skipping to change at page 163, line 42 ¶ | |||
| trusted CAs rather than a single root. Each certificate user bases | trusted CAs rather than a single root. Each certificate user bases | |||
| path validations on the public key of one of the trusted CAs, | path validations on the public key of one of the trusted CAs, | |||
| usually the one that issued that user's own public-key | usually the one that issued that user's own public-key | |||
| certificate. Rather than having superior-to-subordinate | certificate. Rather than having superior-to-subordinate | |||
| relationships between CAs, the relationships are peer-to-peer, and | relationships between CAs, the relationships are peer-to-peer, and | |||
| CAs issue cross-certificates to each other. (Compare: hierarchical | CAs issue cross-certificates to each other. (Compare: hierarchical | |||
| PKI, trust-file PKI.) | PKI, trust-file PKI.) | |||
| $ Message Authentication Code, message authentication code | $ Message Authentication Code, message authentication code | |||
| (N) /capitalized/ A specific ANSI standard for a checksum that is | (N) /capitalized/ A specific ANSI standard for a checksum that is | |||
| computed with a keyed hash that is based on DES. [A9009] Also | computed with a keyed hash that is based on DES. [A9009] Usage: | |||
| known as the U.S. Government standard Data Authentication Code. | a.k.a. Data Authentication Code, which is a U.S. Government | |||
| [FP113] (See: MAC.) | standard. [FP113] (See: MAC.) | |||
| (D) /not capitalized/ Synonym for "error detection code". | (D) /not capitalized/ Synonym for "error detection code". | |||
| Deprecated Term: ISDs SHOULD NOT use the uncapitalized form | Deprecated Term: ISDs SHOULD NOT use the uncapitalized form | |||
| "message authentication code"; that form mixes concepts in a | "message authentication code". Instead, use "checksum", "error | |||
| potentially misleading way. Instead, use "checksum", "error | ||||
| detection code", "hash", "keyed hash", "Message Authentication | detection code", "hash", "keyed hash", "Message Authentication | |||
| Code", or "protected checksum", depending on what is meant. (See: | Code", or "protected checksum", depending on what is meant. (See: | |||
| authentication code.) | authentication code.) | |||
| In the uncapitalized form, the word "message" is misleading | The uncapitalized form mixes concepts in a potentially misleading | |||
| because it implies that the mechanism is particularly suitable for | way. The word "message" is misleading because it implies that the | |||
| or limited to electronic mail (see: Message Handling Systems), the | mechanism is particularly suitable for or limited to electronic | |||
| word "authentication" is misleading because the mechanism | mail (see: Message Handling Systems). The word "authentication" is | |||
| primarily serves a data integrity function rather than an | misleading because the mechanism primarily serves a data integrity | |||
| authentication function, and the word "code" is misleading because | function rather than an authentication function. The word "code" | |||
| it implies that either encoding or encryption is involved or that | is misleading because it implies that either encoding or | |||
| the term refers to computer software. | encryption is involved or that the term refers to computer | |||
| software. | ||||
| $ message digest | $ message digest | |||
| (D) Synonym for "hash result". (See: cryptographic hash.) | (D) Synonym for "hash result". (See: cryptographic hash.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | |||
| "hash result"; the term unnecessarily duplicates the meaning of | "hash result"; the term unnecessarily duplicates the meaning of | |||
| the other, more general term and mixes concepts in a potentially | the other, more general term and mixes concepts in a potentially | |||
| misleading way. The word "message" is misleading because it | misleading way. The word "message" is misleading because it | |||
| implies that the mechanism is particularly suitable for or limited | implies that the mechanism is particularly suitable for or limited | |||
| to electronic mail (see: Message Handling Systems). | to electronic mail (see: Message Handling Systems). | |||
| skipping to change at page 155, line 55 ¶ | skipping to change at page 165, line 6 ¶ | |||
| $ message integrity check | $ message integrity check | |||
| $ message integrity code (MIC) | $ message integrity code (MIC) | |||
| (D) Synonyms for some form of "checksum". | (D) Synonyms for some form of "checksum". | |||
| Deprecated Term: ISDs SHOULD NOT use these terms for any form of | Deprecated Term: ISDs SHOULD NOT use these terms for any form of | |||
| checksum. Instead, use "checksum", "error detection code", "hash", | checksum. Instead, use "checksum", "error detection code", "hash", | |||
| "keyed hash", "Message Authentication Code", or "protected | "keyed hash", "Message Authentication Code", or "protected | |||
| checksum", depending on what is meant. | checksum", depending on what is meant. | |||
| The terms mix concepts in potentially misleading ways. The word | These two terms mix concepts in potentially misleading ways. The | |||
| "message" is misleading because it suggests that the mechanism is | word "message" is misleading because it suggests that the | |||
| particularly suitable for or limited to electronic mail. The word | mechanism is particularly suitable for or limited to electronic | |||
| "integrity" is misleading because the checksum may be used to | mail. The word "integrity" is misleading because the checksum may | |||
| perform a data origin authentication function rather than an | be used to perform a data origin authentication function rather | |||
| integrity function. The word "code" is misleading because it | than an integrity function. The word "code" is misleading because | |||
| suggests either that either encoding or encryption is involved or | it suggests either that either encoding or encryption is involved | |||
| that the term refers to computer software. | or that the term refers to computer software. | |||
| $ Message Security Protocol (MSP) | $ Message Security Protocol (MSP) | |||
| (N) A secure message handling protocol [SDNS7] for use with X.400 | (N) A secure message handling protocol [SDNS7] for use with X.400 | |||
| and Internet mail protocols. Developed by NSA's SDNS program and | and Internet mail protocols. Developed by NSA's SDNS program and | |||
| used in the U.S. DoD's Defense Message System. | used in the U.S. DoD's Defense Message System. | |||
| $ meta-data | $ meta-data | |||
| (I) Descriptive information about a data object; i.e., data about | (I) Descriptive information about a data object; i.e., data about | |||
| data, or data labels that describe other data. (See: security | data, or data labels that describe other data. (See: security | |||
| label. Compare: metadata) | label. Compare: metadata) | |||
| Tutorial: Meta-data can serve various management purposes: | Tutorial: Meta-data can serve various management purposes: | |||
| - System management: File name, type, size, creation date. | - System management: File name, type, size, creation date. | |||
| - Application management: Document title, version, author. | - Application management: Document title, version, author. | |||
| - Usage management: Data categories, keywords, classifications. | - Usage management: Data categories, keywords, classifications. | |||
| Meta-data can be associated with a data object in two basic ways: | Meta-data can be associated with a data object in two basic ways: | |||
| - Explicitly: Be part of the data object (e.g., a header field of | - Explicitly: Be part of the data object (e.g., a header field of | |||
| a data file or packet) or be linked to the object. | a data file or packet) or be linked to the object. | |||
| - Implicitly: Be associated with the data object because of some | - Implicitly: Be associated with the data object because of some | |||
| other, explicit attribute of the object. | other, explicit attribute of the object. | |||
| $ metadata, Metadata(trademark), METADATA(trademark) | $ metadata, Metadata(trademark), METADATA(trademark) | |||
| (O) A proprietary variant of "meta-data". (See: SPAM(trademark).) | (D) Proprietary variants of "meta-data". (See: SPAM(trademark).) | |||
| Deprecated Usage: The terms "Metadata" and "METADATA" are claimed | Deprecated Terms: ISDs SHOULD NOT use these unhypenated forms; | |||
| as registered trademarks (numbers 1,409,260 and 2,185,504) owned | ISDs SHOULD use only the uncapitalized, hyphenated "meta-data". | |||
| by The Metadata Company, originally known as Metadata Information | The terms "Metadata" and "METADATA" are claimed as registered | |||
| Partners, a company founded by Jack Myers. To avoid litigation, | trademarks (numbers 1,409,260 and 2,185,504) owned by The Metadata | |||
| this Glossary recommends a hyphenated form, "meta-data". | Company, originally known as Metadata Information Partners, a | |||
| company founded by Jack Myers. The status of "metadata" is | ||||
| unclear. | ||||
| $ MHS | $ MHS | |||
| (N) See: message handling system. | (N) See: message handling system. | |||
| $ MIC | $ MIC | |||
| (D) See: message integrity code. | (D) See: message integrity code. | |||
| $ MIME | $ MIME | |||
| (I) See: Multipurpose Internet Mail Extensions. | (I) See: Multipurpose Internet Mail Extensions. | |||
| skipping to change at page 157, line 18 ¶ | skipping to change at page 166, line 24 ¶ | |||
| between PKI components from different vendors; consists primarily | between PKI components from different vendors; consists primarily | |||
| of a profile of certificate and CRL extensions and a set of | of a profile of certificate and CRL extensions and a set of | |||
| transactions for PKI operation. [SP15] | transactions for PKI operation. [SP15] | |||
| $ misappropriation | $ misappropriation | |||
| (I) A type of threat action whereby an entity assumes unauthorized | (I) A type of threat action whereby an entity assumes unauthorized | |||
| logical or physical control of a system resource. (See: | logical or physical control of a system resource. (See: | |||
| usurpation.) | usurpation.) | |||
| Usage: This type includes the following subtypes: | Usage: This type includes the following subtypes: | |||
| - Theft of data: Unauthorized acquisition and use of data | - Theft of data: Unauthorized acquisition and use of data | |||
| contained in a system. | contained in a system. | |||
| - Theft of service: Unauthorized use of a system service. | - Theft of service: Unauthorized use of a system service. | |||
| - Theft of functionality: Unauthorized acquisition of actual | - Theft of functionality: Unauthorized acquisition of actual | |||
| hardware, software, or firmware of a system component. | hardware, firmware, or software of a system component. | |||
| $ MISPC | $ MISPC | |||
| (N) See: Minimum Interoperability Specification for PKI | (N) See: Minimum Interoperability Specification for PKI | |||
| Components. | Components. | |||
| $ MISSI | $ MISSI | |||
| (N) Multilevel Information System Security Initiative, an NSA | (O) Multilevel Information System Security Initiative, an NSA | |||
| program to encourage development of interoperable, modular | program to encourage development of interoperable, modular | |||
| products for constructing secure network information systems in | products for constructing secure network information systems in | |||
| support of a wide variety of Government missions. (See: MSP, SP3, | support of a wide variety of Government missions. (See: MSP, SP3, | |||
| SP4.) | SP4.) | |||
| $ MISSI user | $ MISSI user | |||
| (O) /MISSI/ A system entity that is the subject of one or more | (O) /MISSI/ A system entity that is the subject of one or more | |||
| MISSI X.509 public-key certificates issued under a MISSI | MISSI X.509 public-key certificates issued under a MISSI | |||
| certification hierarchy. (See: personality.) | certification hierarchy. (See: personality.) | |||
| Tutorial: MISSI users include both end users and the authorities | Tutorial: MISSI users include both end users and the authorities | |||
| that issue certificates. A MISSI user is usually a person but may | that issue certificates. A MISSI user is usually a person but may | |||
| be a machine or other automated process. Some machines are | be a machine or other automated process. Machines that are | |||
| required to operate non-stop. To avoid downtime needed to exchange | required to operate non-stop may be issued their own certificates | |||
| the FORTEZZA cards of machine operators at shift changes, the | to avoid downtime needed to exchange the FORTEZZA cards of machine | |||
| machines may be issued their own cards, as if they were persons. | operators at shift changes. | |||
| $ mission | $ mission | |||
| (I) A statement of a (relatively long-term) duty or (relatively | (I) A statement of a (relatively long-term) duty or (relatively | |||
| short-term) task that is assigned to an organization or system, | short-term) task that is assigned to an organization or system, | |||
| indicates the purpose and objectives of the duty or task, and may | indicates the purpose and objectives of the duty or task, and may | |||
| indicate the actions to be taken to achieve it. | indicate the actions to be taken to achieve it. | |||
| $ mission critical | $ mission critical | |||
| (I) A condition of a system service or other system resource such | (I) A condition of a system service or other system resource such | |||
| that denial of access to, or lack of availability of, the resource | that denial of access to, or lack of availability of, the resource | |||
| would jeopardize a system user~Os ability to perform a primary | would jeopardize a system user's ability to perform a primary | |||
| mission function or would result in other serious consequences. | mission function or would result in other serious consequences. | |||
| (Compare: mission essential.) | (See: Critical. Compare: mission essential.) | |||
| $ mission essential | $ mission essential | |||
| (O) /DoD/ Refers to materiel that is authorized and available to | (O) /DoD/ Refers to materiel that is authorized and available to | |||
| combat, combat support, combat service support, and combat | combat, combat support, combat service support, and combat | |||
| readiness training forces to accomplish their assigned missions. | readiness training forces to accomplish their assigned missions. | |||
| [JCSP1] (Compare: mission critical.) | [JCSP1] (Compare: mission critical.) | |||
| $ misuse | $ misuse | |||
| 1. (I) The intentional use (by authorized users) of system | 1. (I) The intentional use (by authorized users) of system | |||
| resources for other than authorized purposes. Example: An | resources for other than authorized purposes. Example: An | |||
| authorized system administrator creates an unauthorized account | authorized system administrator creates an unauthorized account | |||
| for a friend. | for a friend. | |||
| 2. (I) A type of threat action that causes a system component to | 2. (I) A type of threat action that causes a system component to | |||
| perform a function or service that is detrimental to system | perform a function or service that is detrimental to system | |||
| security. (See: usurpation.) | security. (See: usurpation.) | |||
| Usage: This type includes the following subtypes: | Usage: This type includes the following subtypes: | |||
| - "Tampering": In context of misuse, deliberately altering a | - "Tampering": In context of misuse, deliberately altering a | |||
| system's logic, data, or control information to cause the | system's logic, data, or control information to cause the | |||
| system to perform unauthorized functions or services. (See: | system to perform unauthorized functions or services. (See: | |||
| (main entry for) tampering.) | corruption, main entry for "tampering".) | |||
| - "Malicious logic": In context of misuse, any hardware, | - "Malicious logic": In context of misuse, any hardware, | |||
| software, or firmware intentionally introduced into a system to | firmware, or software intentionally introduced into a system to | |||
| perform or control execution of an unauthorized function or | perform or control execution of an unauthorized function or | |||
| service. (See: (main entry for) malicious logic.) | service. (See: corruption, incapacitation, main entry for | |||
| - "Violation of authorizations": Action by an entity that exceeds | "malicious logic", masquerade.) | |||
| - "Violation of authorizations": Action by an entity that exceeds | ||||
| the entity's system privileges by executing an unauthorized | the entity's system privileges by executing an unauthorized | |||
| function. (See: authorization.) | function. (See: authorization.) | |||
| $ misuse detection | $ misuse detection | |||
| (I) An intrusion detection method that is based on rules that | (I) An intrusion detection method that is based on rules that | |||
| specify system events, sequences of events, or observable | specify system events, sequences of events, or observable | |||
| properties of a system that are believed to be symptomatic of | properties of a system that are believed to be symptomatic of | |||
| security incidents. (See: IDS. Compare: anomaly detection.) | security incidents. (See: IDS. Compare: anomaly detection.) | |||
| $ MLS | $ MLS | |||
| skipping to change at page 159, line 4 ¶ | skipping to change at page 168, line 10 ¶ | |||
| $ mobile code | $ mobile code | |||
| 1a. (I) Software that originates from a remote server or is | 1a. (I) Software that originates from a remote server or is | |||
| embedded in a document or other application file, is transmitted | embedded in a document or other application file, is transmitted | |||
| across a network, and is loaded onto and executed on a local | across a network, and is loaded onto and executed on a local | |||
| client system. | client system. | |||
| 1b. (O) /U.S. DoD/ "Software obtained from remote systems outside | 1b. (O) /U.S. DoD/ "Software obtained from remote systems outside | |||
| the enclave boundary, transferred across a network, and then | the enclave boundary, transferred across a network, and then | |||
| downloaded and executed on a local system without explicit | downloaded and executed on a local system without explicit | |||
| installation or execution by the recipient." | installation or execution by the recipient." | |||
| 2a. (O) /U.S. DoD/ "Technology that enables the creation of | 2a. (O) /U.S. DoD/ "Technology that enables the creation of | |||
| executable information that can be delivered to an information | executable information that can be delivered to an information | |||
| system and directly executed on any hardware/software architecture | system and directly executed on any hardware/software architecture | |||
| that has an appropriate host execution environment." | that has an appropriate host execution environment." | |||
| 2b. (O) "Programs (e.g., script, macro, or other portable | 2b. (O) "Programs (e.g., script, macro, or other portable | |||
| instruction) that can be shipped unchanged to a heterogeneous | instruction) that can be shipped unchanged to a heterogeneous | |||
| collection of platforms and execute with identical semantics" [SP- | collection of platforms and executed with identical semantics" | |||
| 28]. (See: active content.) | [SP-28]. (See: active content.) | |||
| Tutorial: Mobile code might be malicious. Using techniques such as | Tutorial: Mobile code might be malicious. Using techniques such as | |||
| "code signing" and a "sandbox" can reduce the risks of receiving | "code signing" and a "sandbox" can reduce the risks of receiving | |||
| and executing mobile code. | and executing mobile code. | |||
| $ mode | $ mode | |||
| $ mode of operation | $ mode of operation | |||
| 1. (I) /encryption/ A technique for enhancing the effect of a | 1. (I) /cryptographic operation/ A technique for enhancing the | |||
| cryptographic algorithm or adapting the algorithm for an | effect of a cryptographic algorithm or adapting the algorithm for | |||
| application, such as applying a block cipher to a sequence of data | an application, such as applying a block cipher to a sequence of | |||
| blocks or a data stream. (See: ECB, CBC, CFB, OFB.) | data blocks or a data stream. (See: ECB, CBC, CFB, OFB.) | |||
| 2. (I) /system operation/ A type of security policy that states | 2. (I) /system operation/ A type of security policy that states | |||
| the range of classification levels of information that a system is | the range of classification levels of information that a system is | |||
| permitted to handle and the range of clearances and authorizations | permitted to handle and the range of clearances and authorizations | |||
| of users who are permitted to access the system. (See: dedicated | of users who are permitted to access the system. (See: | |||
| compartmented security mode, controlled security mode, dedicated | ||||
| security mode, multilevel security mode, partitioned security | security mode, multilevel security mode, partitioned security | |||
| mode, system high security mode.) | mode, system-high security mode. Compare: protection level.) | |||
| 3. (I) /IKE/ IKE refers to its various types of ISAKMP-scripted | ||||
| exchanges of messages as "modes". Among these are the following: | ||||
| - "Main mode": One of IKE's two phase 1 modes. (See: ISAKMP.) | ||||
| - "Quick mode": IKE's only phase 2 mode. (See: ISAKMP.) | ||||
| $ modulus | $ modulus | |||
| (I) The defining constant in modular arithmetic, and usually a | (I) The defining constant in modular arithmetic, and usually a | |||
| part of the public key in asymmetric cryptography that is based on | part of the public key in asymmetric cryptography that is based on | |||
| modular arithmetic. (See: Diffie-Hellman, RSA.) | modular arithmetic. (See: Diffie-Hellman, RSA.) | |||
| $ Mondex | $ Mondex | |||
| (O) A smartcard-based electronic money system that incorporates | (O) A smartcard-based electronic money system that incorporates | |||
| cryptography and can be used to make payments via the Internet. | cryptography and can be used to make payments via the Internet. | |||
| (See: IOTP.) | (See: IOTP.) | |||
| $ Morris Worm | $ Morris Worm | |||
| (I) A worm program that flooded the ARPANET in November, 1988, | (I) A worm program that flooded the ARPANET in November, 1988, | |||
| causing problems for thousands of hosts. [R1135] (See: worm.) | causing problems for thousands of hosts. [R1135] (See: community | |||
| risk, worm) | ||||
| $ MOSS | $ MOSS | |||
| (I) See: MIME Object Security Services. | (I) See: MIME Object Security Services. | |||
| $ MQV | $ MQV | |||
| (N) A key-agreement protocol [Mene] that was proposed by A.J. | (N) A key-agreement protocol [Mene] that was proposed by A.J. | |||
| Menezes, M. Qu, and S.A. Vanstone in 1995 and is based on the | Menezes, M. Qu, and S.A. Vanstone in 1995 and is based on the | |||
| Diffie-Hellman algorithm. | Diffie-Hellman algorithm. | |||
| $ MSP | $ MSP | |||
| skipping to change at page 160, line 36 ¶ | skipping to change at page 169, line 49 ¶ | |||
| and maintain separation between, resources (particularly stored | and maintain separation between, resources (particularly stored | |||
| data) of different security levels. (Examples: BLACKER, CANEWARE, | data) of different security levels. (Examples: BLACKER, CANEWARE, | |||
| KSOS, Multics, SCOMP.) | KSOS, Multics, SCOMP.) | |||
| Usage: Usually understood to mean that the system permits | Usage: Usually understood to mean that the system permits | |||
| concurrent access by users who differ in their access | concurrent access by users who differ in their access | |||
| authorizations, while denying users access to resources for which | authorizations, while denying users access to resources for which | |||
| they lack authorization. | they lack authorization. | |||
| $ multilevel security mode | $ multilevel security mode | |||
| 1. (N) A mode of system operation that allows two or more security | 1. (N) A mode of system operation wherein (a) two or more security | |||
| levels of information to be handled concurrently within the same | levels of information are allowed to be to be handled concurrently | |||
| system when not all users have a clearance or specific access | within the same system when some users having access to the system | |||
| authorization for all data handled by the system. [DoD2] | have neither a security clearance nor need-to-know for some of the | |||
| data handled by the system and (b) separation of the users and the | ||||
| classified material on the basis, respectively, of clearance and | ||||
| classification level are dependent on operating system control. | ||||
| (See: /system operation/ under "mode", need to know, protection | ||||
| level, security clearance. Compare: controlled mode.) | ||||
| Usage: This term was defined in U.S. DoD policy regarding system | Usage: Usually abbreviated as "multilevel mode". This term was | |||
| accreditation [DoD2], but the term is also used outside the | defined in Government policy regarding system accreditation, but | |||
| Defense Department and outside government. This term can be | the term is also used outside the Government. | |||
| defined more precisely as follows: | ||||
| 2. (N) A mode of system operation in which all three of the | 2. (O) A mode of system operation in which all three of the | |||
| following statements are true: (a) Some authorized users do not | following statements are true: (a) Some authorized users do not | |||
| have a security clearance for all the information handled in the | have a security clearance for all the information handled in the | |||
| system. (b) All authorized users have the proper security | system. (b) All authorized users have the proper security | |||
| clearance and appropriate specific access approval for the | clearance and appropriate specific access approval for the | |||
| information to which they have access. (c) All authorized users | information to which they have access. (c) All authorized users | |||
| have a need-to-know only for information to which they have | have a need-to-know only for information to which they have | |||
| access. [C4009] | access. [C4009] (See: formal access approval, protection level.) | |||
| $ Multipurpose Internet Mail Extensions (MIME) | $ Multipurpose Internet Mail Extensions (MIME) | |||
| (I) An Internet protocol (RFC 2045) that enhances the basic format | (I) An Internet protocol (RFC 2045) that enhances the basic format | |||
| of Internet electronic mail messages (RFC 822) to be able to use | of Internet electronic mail messages (RFC 822) (1) to enable | |||
| character sets other than U.S. ASCII for textual headers and text | character sets other than U.S. ASCII to be used for textual | |||
| content, and to carry non-textual and multi-part content. (See: | headers and content and (2) to carry non-textual and multi-part | |||
| S/MIME.) | content. (See: S/MIME.) | |||
| $ mutual suspicion | $ mutual suspicion | |||
| (I) The state that exists between two interacting system entities | (I) The state that exists between two interacting system entities | |||
| in which neither entity can trust the other to function correctly | in which neither entity can trust the other to function correctly | |||
| with regard to some security requirement. | with regard to some security requirement. | |||
| $ name | $ name | |||
| (I) Synonym for "identifier". | (I) Synonym for "identifier". | |||
| $ National Computer Security Center (NCSC) | $ National Computer Security Center (NCSC) | |||
| skipping to change at page 161, line 34 ¶ | skipping to change at page 170, line 51 ¶ | |||
| $ National Information Assurance Partnership (NIAP) | $ National Information Assurance Partnership (NIAP) | |||
| (N) An joint initiative of NIST and NSA to enhance the quality of | (N) An joint initiative of NIST and NSA to enhance the quality of | |||
| commercial products for information security and increase consumer | commercial products for information security and increase consumer | |||
| confidence in those products through objective evaluation and | confidence in those products through objective evaluation and | |||
| testing methods. | testing methods. | |||
| Tutorial: NIAP is registered, through the U.S. DoD, as a National | Tutorial: NIAP is registered, through the U.S. DoD, as a National | |||
| Performance Review Reinvention Laboratory. NIAP functions include | Performance Review Reinvention Laboratory. NIAP functions include | |||
| the following: | the following: | |||
| - Developing tests, test methods, and other tools that developers | - Developing tests, test methods, and other tools that developers | |||
| and testing laboratories may use to improve and evaluate | and testing laboratories may use to improve and evaluate | |||
| security products. | security products. | |||
| - Collaborating with industry and others on research and testing | - Collaborating with industry and others on research and testing | |||
| programs. | programs. | |||
| - Using the Common Criteria to develop protection profiles and | ||||
| - Using the Common Criteria to develop protection profiles and | ||||
| associated test sets for security products and systems. | associated test sets for security products and systems. | |||
| - Cooperating with the NIST National Voluntary Laboratory | - Cooperating with the NIST National Voluntary Laboratory | |||
| Accreditation Program to develop a program to accredit private- | Accreditation Program to develop a program to accredit private- | |||
| sector laboratories for the testing of information security | sector laboratories for the testing of information security | |||
| products using the Common Criteria. | products using the Common Criteria. | |||
| - Working to establish a formal, international mutual recognition | - Working to establish a formal, international mutual recognition | |||
| scheme for a Common Criteria-based evaluation. | scheme for a Common Criteria-based evaluation. | |||
| $ National Institute of Standards and Technology (NIST) | $ National Institute of Standards and Technology (NIST) | |||
| (N) A U.S. Department of Commerce organization that promotes U.S. | (N) A U.S. Department of Commerce organization that promotes U.S. | |||
| economic growth by working with industry to develop and apply | economic growth by working with industry to develop and apply | |||
| technology, measurements, and standards. Has primary Government | technology, measurements, and standards. Has primary Government | |||
| responsibility for INFOSEC standards for unclassified but | responsibility for INFOSEC standards for sensitive unclassified | |||
| sensitive information. (See: ANSI, DES, DSA, DSS, FIPS, NIAP, | information. (See: ANSI, DES, DSA, DSS, FIPS, NIAP, NSA.) | |||
| NSA.) | ||||
| $ National Security Agency (NSA) | $ National Security Agency (NSA) | |||
| (N) A U.S. DoD organization that has primary Government | (N) A U.S. DoD organization that has primary Government | |||
| responsibility for INFOSEC standards for classified information | responsibility for INFOSEC standards for classified information | |||
| and for unclassified but sensitive information handled by national | and for sensitive unclassified information handled by national | |||
| security systems. (See: FORTEZZA, KEA, MISSI, NIAP, NIST, | security systems. (See: FORTEZZA, KEA, MISSI, national security | |||
| SKIPJACK.) | system, NIAP, NIST, SKIPJACK.) | |||
| $ national security information | $ national security information | |||
| (N) /U.S. Government/ Information that has been determined, | (N) /U.S. Government/ Information that has been determined, | |||
| pursuant to Executive Order 12958 or any predecessor order, to | pursuant to Executive Order 12958 or any predecessor order, to | |||
| require protection against unauthorized disclosure. [C4009] | require protection against unauthorized disclosure. [C4009] | |||
| $ national security system | $ national security system | |||
| (O) /U.S. Government/ Any Government-operated information system | (O) /U.S. Government/ Any Government-operated information system | |||
| for which the function, operation, or use (a) involves | for which the function, operation, or use (a) involves | |||
| intelligence activities; (b) involves cryptologic activities | intelligence activities; (b) involves cryptologic activities | |||
| related to national security; (c) involves command and control of | related to national security; (c) involves command and control of | |||
| military forces; (d) involves equipment that is an integral part | military forces; (d) involves equipment that is an integral part | |||
| of a weapon or weapon system; or (c) is critical to the direct | of a weapon or weapon system; or (e) is critical to the direct | |||
| fulfillment of military or intelligence missions and does not | fulfillment of military or intelligence missions and does not | |||
| include a system that is to be used for routine administrative and | include a system that is to be used for routine administrative and | |||
| business applications (including payroll, finance, logistics, and | business applications (including payroll, finance, logistics, and | |||
| personnel management applications). [Title 40 U.S.C. Section 1552, | personnel management applications). [Title 40 U.S.C. Section 1552, | |||
| Information Technology Management Reform Act of 1996.] (See: type | Information Technology Management Reform Act of 1996.] (See: type | |||
| 2 product.) | 2 product.) | |||
| $ NCSC | $ NCSC | |||
| (O) See: National Computer Security Center. | (O) See: National Computer Security Center. | |||
| $ need to know | $ need to know, need-to-know | |||
| (I) The necessity for access to, knowledge of, or possession of | (I) The necessity for access to, knowledge of, or possession of | |||
| specific information required to carry out official duties. | specific information required to carry out official duties. | |||
| Usage: The compound "need-to-know" is used as both an adjective | ||||
| and a noun. | ||||
| Tutorial: The need-to-know criterion is used in security | Tutorial: The need-to-know criterion is used in security | |||
| procedures that require a custodian of sensitive information, | procedures that require a custodian of sensitive information, | |||
| prior to disclosing the information to someone else, to establish | prior to disclosing the information to someone else, to establish | |||
| that the intended recipient has proper authorization to access the | that the intended recipient has proper authorization to access the | |||
| information. | information. | |||
| $ network | $ network | |||
| (I) An information system comprised of a collection of | (I) An information system comprised of a collection of | |||
| interconnected modes. (See: computer network.) | interconnected nodes. (See: computer network.) | |||
| $ Network Hardware Layer | ||||
| (I) See: Internet Protocol Suite. | ||||
| $ Network Interface Layer | ||||
| (I) See: Internet Protocol Suite. | ||||
| $ Network Layer Security Protocol (NLSP). | $ Network Layer Security Protocol (NLSP). | |||
| (N) An OSI protocol (IS0 11577) for end-to-end encryption services | (N) An OSI protocol (IS0 11577) for end-to-end encryption services | |||
| at the top of OSIRM layer 3. NLSP is derived from SP3 but is more | at the top of OSIRM Layer 3. NLSP is derived from SP3 but is more | |||
| complex. (Compare: IPsec.) | complex. (Compare: IPsec.) | |||
| $ Network Substrate Layer | ||||
| (I) Synonym for "Network Hardware Layer". | ||||
| $ network weaving | $ network weaving | |||
| (I) A penetration technique in which an intruder avoids detection | (I) A penetration technique in which an intruder avoids detection | |||
| and traceback by using multiple linked communication networks to | and traceback by using multiple linked communication networks to | |||
| access and attack a system. [C4009] | access and attack a system. [C4009] | |||
| $ NIAP | $ NIAP | |||
| (N) See: National Information Assurance Partnership. | (N) See: National Information Assurance Partnership. | |||
| $ nibble | $ nibble | |||
| (D) Half of a byte (i.e., usually, 4 bits). | (D) Half of a byte (i.e., usually, 4 bits). | |||
| Deprecated Term: To ensure international understanding, ISDs | Deprecated Term: To avoid international misunderstanding, ISDs | |||
| SHOULD NOT use this term; instead, state the size of the block | SHOULD NOT use this term; instead, state the size of the block | |||
| explicitly (e.g., "4-bit block"). (See: (Deprecated Usage under) | explicitly (e.g., "4-bit block"). (See: Deprecated Usage under | |||
| Green Book.) | "Green Book".) | |||
| $ NIPRNET | $ NIPRNET | |||
| (O) The U.S. DoD~Os common-use Non-Classified Internet Protocol | (O) The U.S. DoD's common-use Non-Classified Internet Protocol | |||
| Router Network; the part of the Internet that is wholly controlled | Router Network; the part of the Internet that is wholly controlled | |||
| by the U.S. DoD and is used for official DoD business. | by the U.S. DoD and is used for official DoD business. | |||
| $ NIST | $ NIST | |||
| (N) See: National Institute of Standards and Technology. | (N) See: National Institute of Standards and Technology. | |||
| $ NLSP | $ NLSP | |||
| (N) See: Network Layer Security Protocol | (N) See: Network Layer Security Protocol | |||
| $ no-lone zone | $ no-lone zone | |||
| skipping to change at page 164, line 4 ¶ | skipping to change at page 173, line 33 ¶ | |||
| exchanged by a protocol, usually for the purpose of guaranteeing | exchanged by a protocol, usually for the purpose of guaranteeing | |||
| liveness and thus detecting and protecting against replay attacks. | liveness and thus detecting and protecting against replay attacks. | |||
| $ non-critical | $ non-critical | |||
| See: critical. | See: critical. | |||
| $ non-repudiation service | $ non-repudiation service | |||
| 1. (I) A security service that provide protection against false | 1. (I) A security service that provide protection against false | |||
| denial of involvement in a communication. (See: repudiation, time | denial of involvement in a communication. (See: repudiation, time | |||
| stamp.) | stamp.) | |||
| 2. (O) "Assurance [that] the sender of data is provided with proof | ||||
| 2. (D) "Assurance [that] the sender of data is provided with proof | ||||
| of delivery and the recipient is provided with proof of the | of delivery and the recipient is provided with proof of the | |||
| sender's identity, so neither can later deny having processed the | sender's identity, so neither can later deny having processed the | |||
| data." [NS4009] | data." [NS4009] | |||
| Deprecated Definition: ISDs SHOULD NOT use the "O" definition | Deprecated Definition: ISDs SHOULD NOT use this definition because | |||
| because it bundles two security services -- non-repudiation with | it bundles two security services -- non-repudiation with proof of | |||
| proof of origin, and non-repudiation with proof of receipt -- that | origin, and non-repudiation with proof of receipt -- that can be | |||
| can be provided independently of each other. | provided independently of each other. | |||
| Usage: ISDs SHOULD distinguish between the technical aspects and | Usage: ISDs SHOULD distinguish between the technical aspects and | |||
| the legal aspects of a non-repudiation service: | the legal aspects of a non-repudiation service: | |||
| - "Technical non-repudiation": Refers to the assurance a relying | - "Technical non-repudiation": Refers to the assurance a relying | |||
| party has that if a public key is used to validate a digital | party has that if a public key is used to validate a digital | |||
| signature, that signature had to have been made by the | signature, then that signature had to have been made by the | |||
| corresponding private signature key. [SP32] | corresponding private signature key. [SP32] | |||
| -"Legal non-repudiation": Refers to how well possession or | - "Legal non-repudiation": Refers to how well possession or | |||
| control of the private signature key can be established. [SP32] | control of the private signature key can be established. [SP32] | |||
| Tutorial: Non-repudiation service does not prevent an entity from | Tutorial: Non-repudiation service does not prevent an entity from | |||
| repudiating a communication. Instead, the service provides | repudiating a communication. Instead, the service provides | |||
| evidence that can be stored and later presented to a third party | evidence that can be stored and later presented to a third party | |||
| to resolve disputes that arise if and when a communication is | to resolve disputes that arise if and when a communication is | |||
| repudiated by one of the entities involved. | repudiated by one of the entities involved. | |||
| Ford describes the six phases of a complete non-repudiation | Ford describes the six phases of a complete non-repudiation | |||
| service and uses "critical action" to refer to the act of | service and uses "critical action" to refer to the act of | |||
| communication that is the subject of the service [For94, For97]: | communication that is the subject of the service [For94, For97]: | |||
| skipping to change at page 165, line 4 ¶ | skipping to change at page 174, line 33 ¶ | |||
| +-------------------+ | +-------------------+ | |||
| Phase / Explanation | Phase / Explanation | |||
| ------------------- | ------------------- | |||
| 1. Request service: Before the critical action, the service | 1. Request service: Before the critical action, the service | |||
| requester asks, either implicitly or explicitly, to have | requester asks, either implicitly or explicitly, to have | |||
| evidence of the action be generated. | evidence of the action be generated. | |||
| 2. Generate evidence: When the critical action occurs, evidence is | 2. Generate evidence: When the critical action occurs, evidence is | |||
| generated by a process involving the potential repudiator and | generated by a process involving the potential repudiator and | |||
| possibly also a trusted third party. | possibly also a trusted third party. | |||
| 3. Transfer evidence: The evidence is transferred to the requester | 3. Transfer evidence: The evidence is transferred to the requester | |||
| or stored by a third party, for later use (if needed.) | or stored by a third party, for later use (if needed.) | |||
| 4. Verify evidence: The entity that holds the evidence tests it to | 4. Verify evidence: The entity that holds the evidence tests it to | |||
| be sure that it will suffice if a dispute arises. | be sure that it will suffice if a dispute arises. | |||
| 5. Retain evidence: The evidence is retained for possible future | 5. Retain evidence: The evidence is retained for possible future | |||
| retrieval and use. | retrieval and use. | |||
| 6. Resolve dispute: In this phase, which occurs only if the | 6. Resolve dispute: In this phase, which occurs only if the | |||
| critical action is repudiated, the evidence is retrieved from | critical action is repudiated, the evidence is retrieved from | |||
| storage, presented, and verified to resolve the dispute. | storage, presented, and verified to resolve the dispute. | |||
| $ non-repudiation with proof of origin | $ non-repudiation with proof of origin | |||
| (I) A security service that provides the recipient of data with | (I) A security service that provides the recipient of data with | |||
| evidence that proves the origin of the data, and thus protects the | evidence that proves the origin of the data, and thus protects the | |||
| recipient against an attempt by the originator to falsely deny | recipient against an attempt by the originator to falsely deny | |||
| sending the data. This service can be viewed as a strong version | sending the data. (See: non-repudiation service.) | |||
| of data origin authentication service, in that it proves | ||||
| authenticity to a third party. (See: non-repudiation service.) | Tutorial: This service is a strong version of data origin | |||
| authentication service. This service can not only verify the | ||||
| identity of a system entity that is the original source of | ||||
| received data; it can also provide proof of that identity to a | ||||
| third party. | ||||
| $ non-repudiation with proof of receipt | $ non-repudiation with proof of receipt | |||
| (I) A security service that provides the originator of data with | (I) A security service that provides the originator of data with | |||
| evidence that proves the data was received as addressed, and thus | evidence that proves the data was received as addressed, and thus | |||
| protects the originator against an attempt by the recipient to | protects the originator against an attempt by the recipient to | |||
| falsely deny receiving the data. (See: non-repudiation service.) | falsely deny receiving the data. (See: non-repudiation service.) | |||
| $ non-volatile media | $ non-volatile media | |||
| (I) Storage media that, once written into, provide stable storage | (I) Storage media that, once written into, provide stable storage | |||
| of information without an external power supply. (Compare: | of information without an external power supply. (Compare: | |||
| volatile media, permanent storage.) | permanent storage, volatile media.) | |||
| $ NORA | $ NORA | |||
| (O) See: no-PIN ORA. | (O) See: no-PIN ORA. | |||
| $ notarization | $ notarization | |||
| (I) Registration of data under the authority or in the care of a | (I) Registration of data under the authority or in the care of a | |||
| trusted third party, thus making it possible to provide subsequent | trusted third party, thus making it possible to provide subsequent | |||
| assurance of the accuracy of characteristics claimed for the data, | assurance of the accuracy of characteristics claimed for the data, | |||
| such as content, origin, time of existence, and delivery. [I7498 | such as content, origin, time of existence, and delivery. [I7498 | |||
| Part 2] (See: digital notary.) | Part 2] (See: digital notary.) | |||
| skipping to change at page 167, line 16 ¶ | skipping to change at page 176, line 49 ¶ | |||
| ccitt(2) country(16) US(840) organization(1) gov(101) csor(3)}. | ccitt(2) country(16) US(840) organization(1) gov(101) csor(3)}. | |||
| The NIST CSOR records PKI objects below the branch {joint-iso-itu- | The NIST CSOR records PKI objects below the branch {joint-iso-itu- | |||
| t(2) country(16) us(840) organization (1) gov(101) csor(3)}. The | t(2) country(16) us(840) organization (1) gov(101) csor(3)}. The | |||
| U.S. DoD registers INFOSEC objects below the branch {joint-iso- | U.S. DoD registers INFOSEC objects below the branch {joint-iso- | |||
| itu-t(2) country(16) us(840) organization(1) gov(101) dod(2) | itu-t(2) country(16) us(840) organization(1) gov(101) dod(2) | |||
| infosec(1)}. | infosec(1)}. | |||
| The IETF's Public-Key Infrastructure (pkix) Working Group | The IETF's Public-Key Infrastructure (pkix) Working Group | |||
| registers PKI objects below the branch {iso(1) identified- | registers PKI objects below the branch {iso(1) identified- | |||
| organization(3) dod(6) internet(1) security(5) mechanisms(5) | organization(3) dod(6) internet(1) security(5) mechanisms(5) | |||
| pkix(7)}. [R2459] | pkix(7)}. [R3280] | |||
| $ object reuse | $ object reuse | |||
| (N) /COMPUSEC/ Reassignment and reuse of an area of a storage | (N) /COMPUSEC/ Reassignment and reuse of an area of a storage | |||
| medium (e.g., random-access memory, floppy disk, magnetic tape) | medium (e.g., random-access memory, floppy disk, magnetic tape) | |||
| that once contained sensitive data objects. Before being | that once contained sensitive data objects. Before being | |||
| reassigned for use by a new subject, the area must erased or, in | reassigned for use by a new subject, the area needs to be erased | |||
| some cases, purged. [NCS04] | or, in some cases, purged. [NCS04] | |||
| $ obstruction | $ obstruction | |||
| (I) A type of threat action that interrupts delivery of system | (I) A type of threat action that interrupts delivery of system | |||
| services by hindering system operations. (See: disruption.) | services by hindering system operations. (See: disruption.) | |||
| Tutorial: This type includes the following subtypes: | Tutorial: This type includes the following subtypes: | |||
| - "Interference": Disruption of system operations by blocking | - "Interference": Disruption of system operations by blocking | |||
| communications or user data or control information. (See: | communication of user data or control information. (See: | |||
| jamming.) | jamming.) | |||
| - "Overload": Hindrance of system operation by placing excess | - "Overload": Hindrance of system operation by placing excess | |||
| burden on the performance capabilities of a system component. | burden on the performance capabilities of a system component. | |||
| (See: flooding.) | (See: flooding.) | |||
| $ OCSP | $ OCSP | |||
| (I) See: On-line Certificate Status Protocol. | (I) See: On-line Certificate Status Protocol. | |||
| $ octet | $ octet | |||
| (I) A data unit of eight bits. (Compare: byte.) | (I) A data unit of eight bits. (Compare: byte.) | |||
| Usage: This term is used in networking (especially in OSI | Usage: This term is used in networking (especially in OSI | |||
| standards) in preference to "byte", because some systems use | standards) in preference to "byte", because some systems use | |||
| "byte" for data storage units of a size other than eight bits. | "byte" for data storage units of a size other than eight bits. | |||
| $ OFB | $ OFB | |||
| (N) See: output feedback. | (N) See: output feedback. | |||
| $ off-line attack | $ off-line attack | |||
| (I) See: (secondary definition under) attack. | (I) See: secondary definition under "attack". | |||
| $ ohnosecond | $ ohnosecond | |||
| (D) That minuscule fraction of time in which you realize that your | (D) That minuscule fraction of time in which you realize that your | |||
| private key has been compromised. | private key has been compromised. | |||
| Deprecated Usage: This is a joke for English speakers. (See: | Deprecated Usage: This is a joke for English speakers. (See: | |||
| (Deprecated Usage under) Green Book.) | Deprecated Usage under "Green Book".) | |||
| $ OID | $ OID | |||
| (N) See: object identifier. | (N) See: object identifier. | |||
| $ On-line Certificate Status Protocol (OCSP) | $ On-line Certificate Status Protocol (OCSP) | |||
| (I) An Internet protocol [R2560] used by a client to obtain from a | (I) An Internet protocol [R2560] used by a client to obtain from a | |||
| server the validity status and other information concerning a | server the validity status and other information about a digital | |||
| digital certificate. | certificate. | |||
| Tutorial: In some applications, such as those involving high-value | Tutorial: In some applications, such as those involving high-value | |||
| commercial transactions, it may be necessary either (a) to obtain | commercial transactions, it may be necessary either (a) to obtain | |||
| certificate revocation status that is more timely than is possible | certificate revocation status that is more timely than is possible | |||
| with CRLs or (b) to obtain other kinds of status information. OCSP | with CRLs or (b) to obtain other kinds of status information. OCSP | |||
| may be used to determine the current revocation status of a | may be used to determine the current revocation status of a | |||
| digital certificate, in lieu of or as a supplement to checking | digital certificate, in lieu of or as a supplement to checking | |||
| against a periodic CRL. An OCSP client issues a status request to | against a periodic CRL. An OCSP client issues a status request to | |||
| an OCSP server and suspends acceptance of the certificate in | an OCSP server and suspends acceptance of the certificate in | |||
| question until the server provides a response. | question until the server provides a response. | |||
| $ one-time pad | $ one-time pad | |||
| 1. (N) A manual encryption system in the form of a paper pad for | 1. (N) A manual encryption system in the form of a paper pad for | |||
| one-time use. | one-time use. | |||
| 2. (I) An encryption algorithm in which the key is a random | 2. (I) An encryption algorithm in which the key is a random | |||
| sequence of symbols and each symbol is used for encryption only | sequence of symbols and each symbol is used for encryption only | |||
| one time -- to encrypt only one plaintext symbol to produce only | one time -- i.e., used to encrypt only one plaintext symbol and | |||
| one ciphertext symbol -- and a copy of the key is used similarly | thus produce only one ciphertext symbol -- and a copy of the key | |||
| for decryption. | is used similarly for decryption. | |||
| Tutorial: To ensure one-time use, the copy of the key used for | Tutorial: To ensure one-time use, the copy of the key used for | |||
| encryption is destroyed after use, as is the copy used for | encryption is destroyed after use, as is the copy used for | |||
| decryption. This is the only encryption algorithm that is truly | decryption. This is the only encryption algorithm that is truly | |||
| unbreakable, even given unlimited resources for cryptanalysis | unbreakable, even given unlimited resources for cryptanalysis | |||
| [Schn], but key management costs and synchronization problems make | [Schn], but key management costs and synchronization problems make | |||
| it impractical except in special situations. | it impractical except in special situations. | |||
| $ one-time password, One-Time Password (OTP) | $ one-time password, One-Time Password (OTP) | |||
| 1. (I) /not capitalized/ A "one-time password" is a simple | 1. (I) /not capitalized/ A "one-time password" is a simple | |||
| skipping to change at page 169, line 47 ¶ | skipping to change at page 179, line 27 ¶ | |||
| constant size; and sends the padded onion to that next router. | constant size; and sends the padded onion to that next router. | |||
| $ open security environment | $ open security environment | |||
| (O) /U.S. DoD/ A system environment that meets at least one of the | (O) /U.S. DoD/ A system environment that meets at least one of the | |||
| following two conditions: (a) Application developers (including | following two conditions: (a) Application developers (including | |||
| maintainers) do not have sufficient clearance or authorization to | maintainers) do not have sufficient clearance or authorization to | |||
| provide an acceptable presumption that they have not introduced | provide an acceptable presumption that they have not introduced | |||
| malicious logic. (b) Configuration control does not provide | malicious logic. (b) Configuration control does not provide | |||
| sufficient assurance that applications and the equipment are | sufficient assurance that applications and the equipment are | |||
| protected against the introduction of malicious logic prior to and | protected against the introduction of malicious logic prior to and | |||
| during the operation of system applications. [NCS04] (See: (first | during the operation of system applications. [NCS04] (See: "first | |||
| law under) Courtney's laws. Compare: closed security environment.) | law" under "Courtney's laws". Compare: closed security | |||
| environment.) | ||||
| $ open storage | $ open storage | |||
| (N) /U.S. Government/ "Storage of classified information within an | (N) /U.S. Government/ "Storage of classified information within an | |||
| accredited facility, but not in General Services Administration | accredited facility, but not in General Services Administration | |||
| approved secure containers, while the facility is unoccupied by | approved secure containers, while the facility is unoccupied by | |||
| authorized personnel." [C4009] | authorized personnel." [C4009] | |||
| $ Open Systems Interconnection (OSI) Reference Model (OSIRM) | $ Open Systems Interconnection (OSI) Reference Model (OSIRM) | |||
| (N) A joint ISO/ITU-T standard [I7498 Part 1] for a seven-layer, | (N) A joint ISO/ITU-T standard [I7498 Part 1] for a seven-layer, | |||
| architectural communication framework for interconnection of | architectural communication framework for interconnection of | |||
| computers in networks. | computers in networks. (See: OSIRM Security Architecture. Compare: | |||
| Internet Protocol Suite.) | ||||
| Tutorial: OSIRM-based standards include communication protocols | Tutorial: OSIRM-based standards include communication protocols | |||
| that are mostly incompatible with the IPS, but also include | that are mostly incompatible with the IPS, but also include | |||
| security models, such as X.509, that are used in the Internet. | security models, such as X.509, that are used in the Internet. | |||
| The OSIRM layers, from highest to lowest, are (7) Application, (6) | The OSIRM layers, from highest to lowest, are (7) Application, (6) | |||
| Presentation, (5) Session, (4) Transport, (3) Network, (2) Data | Presentation, (5) Session, (4) Transport, (3) Network, (2) Data | |||
| Link, and (1) Physical. | Link, and (1) Physical. | |||
| Usage: In other Glossary entries, OSIRM layers are referred to by | Usage: This Glossary refers to OSIRM layers by number to avoid | |||
| number to avoid confusing them with IPS layers, which are referred | confusing them with IPS layers, which are referred to by name. | |||
| to by name. | ||||
| Some unknown person described how the OSIRM layers correspond to | Some unknown person described how the OSIRM layers correspond to | |||
| the seven deadly sins: | the seven deadly sins: | |||
| 7. Wrath: Application is always angry at the mess it sees below | 7. Wrath: Application is always angry at the mess it sees below | |||
| itself. (Hey! Who is it to be pointing fingers?) | itself. (Hey! Who is it to be pointing fingers?) | |||
| 6. Sloth: Presentation is too lazy to do anything productive by | 6. Sloth: Presentation is too lazy to do anything productive by | |||
| itself. | itself. | |||
| 5. Lust: Session is always craving and demanding what truly | 5. Lust: Session is always craving and demanding what truly | |||
| belongs to Application's functionality. | belongs to Application's functionality. | |||
| skipping to change at page 171, line 12 ¶ | skipping to change at page 180, line 45 ¶ | |||
| attention. | attention. | |||
| 1. Bashful: Physical quietly does its work, unnoticed by the | 1. Bashful: Physical quietly does its work, unnoticed by the | |||
| others. | others. | |||
| $ operational integrity | $ operational integrity | |||
| (I) Synonym for "system integrity"; this synonym emphasizes the | (I) Synonym for "system integrity"; this synonym emphasizes the | |||
| actual performance of system functions rather than just the | actual performance of system functions rather than just the | |||
| ability to perform them. | ability to perform them. | |||
| $ operational security | $ operational security | |||
| (D) Synonym for "administrative security". (Compare: OPSEC.) | 1. (I) System capabilities, or performance of system functions, | |||
| that are needed either (a) to securely manage a system or (b) to | ||||
| manage security features of a system. (Compare: operations | ||||
| security (OPSEC).) | ||||
| Usage: ISDs that use this term SHOULD state a definition because | ||||
| (a) the definition provide here is general and vauge and (b) the | ||||
| term could easily be confused with "operations security", which is | ||||
| a different concept. | ||||
| Tutorial: For example, in the context of an Internet service | ||||
| provider, the term could refer to capabilities to manage network | ||||
| devices in the event of attacks, simplify troubleshooting, keep | ||||
| track of events that affect system integrity, help analyze sources | ||||
| of attacks, and provide administrators with control over network | ||||
| addresses and protocols to help mitigate the most common attacks | ||||
| and exploits. [R3871] | ||||
| 2. (D) Synonym for "administrative security". | ||||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "administrative security". Any type of security may affect | for "administrative security". Any type of security may affect | |||
| system operations; therefore, the term may be misleading. Instead, | system operations; therefore, the term may be misleading. Instead, | |||
| use "administrative security", "communication security", "computer | use "administrative security", "communication security", "computer | |||
| security", "emanations security", "personnel security", "physical | security", "emanations security", "personnel security", "physical | |||
| security", or whatever specific type is meant. (Compare: OPSEC. | security", or whatever specific type is meant. (See: security | |||
| See: security architecture.) | architecture. Compare: operational integrity, OPSEC.) | |||
| $ operations security (OPSEC) | $ operations security (OPSEC) | |||
| (I) A process to identify, control, and protect evidence of the | (I) A process to identify, control, and protect evidence of the | |||
| planning and execution of sensitive activities and operations, and | planning and execution of sensitive activities and operations, and | |||
| thereby prevent potential adversaries from gaining knowledge of | thereby prevent potential adversaries from gaining knowledge of | |||
| capabilities and intentions. (See: communications cover. Compare: | capabilities and intentions. (See: communications cover. Compare: | |||
| operational security.) | operational security.) | |||
| $ operator | $ operator | |||
| (I) A person who has been authorized to direct selected functions | (I) A person who has been authorized to direct selected functions | |||
| of a system. (Compare: manager.) | of a system. (Compare: manager.) | |||
| Usage: A system operator may or may not be treated as a "user"; | Usage: ISDs that use this term SHOULD state a definition for it | |||
| therefore, ISDs that use this term SHOULD state a definition for | because a system operator may or may not be treated as a "user". | |||
| it. | ||||
| $ OPSEC | $ OPSEC | |||
| (I) See: operations security. | 1. (I) Abbreviation for "operations security". | |||
| 2. (D) Abbreviation for "operational security". | ||||
| Deprecated Usage: ISDs SHOULD NOT use this abbreviation for | ||||
| "operational security" (as defined in this Glossary), because its | ||||
| use for "operations security" has been well established for many | ||||
| years, particular in the military community. | ||||
| $ ORA | $ ORA | |||
| See: organizational registration authority. | See: organizational registration authority. | |||
| $ Orange Book | $ Orange Book | |||
| (D) Synonym for "Trusted Computer System Evaluation Criteria" | (D) /slang/ Synonym for "Trusted Computer System Evaluation | |||
| [CSC001, DoD1]. | Criteria" [CSC001, DoD1]. | |||
| Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for | Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for | |||
| "Trusted Computer System Evaluation Criteria" [CSC001, DoD1]. | "Trusted Computer System Evaluation Criteria" [CSC001, DoD1]. | |||
| Instead, use the full, proper name of the document or, in | Instead, use the full, proper name of the document or, in | |||
| subsequent references, the abbreviation "TCSEC". (See: (Deprecated | subsequent references, the abbreviation "TCSEC". (See: Deprecated | |||
| Usage under) Green Book.) | Usage under "Green Book".) | |||
| $ organizational certificate | $ organizational certificate | |||
| (I) A X.509 certificate in which the "subject" field contains the | (I) An X.509 certificate in which the "subject" field contains the | |||
| name of an institution or set (e.g., a business, government, | name of an institution or set (e.g., a business, government, | |||
| school, labor union, club, ethnic group, nationality, system, or | school, labor union, club, ethnic group, nationality, system, or | |||
| group of individuals playing the same role), rather than the name | group of individuals playing the same role), rather than the name | |||
| of an individual person or device. (Compare: persona certificate, | of an individual person or device. (Compare: persona certificate, | |||
| role certificate.) | role certificate.) | |||
| Tutorial: Such a certificate might be issued for one of the | Tutorial: Such a certificate might be issued for one of the | |||
| following purposes: | following purposes: | |||
| - To enable an individual to prove membership in the | - To enable an individual to prove membership in the | |||
| organization. | organization. | |||
| - To enable an individual to represent the organization, i.e., to | - To enable an individual to represent the organization, i.e., to | |||
| act in its name and with it powers or permissions. | act in its name and with it powers or permissions. | |||
| (O) /MISSI/ A type of MISSI X.509 public-key certificate that is | (O) /MISSI/ A type of MISSI X.509 public-key certificate that is | |||
| issued to support organizational message handling for the U.S. | issued to support organizational message handling for the U.S. | |||
| DoD's Defense Message System. | DoD's Defense Message System. | |||
| $ organizational registration authority (ORA) | $ organizational registration authority (ORA) | |||
| 1. (I) /PKI/ An RA for an organization. | 1. (I) /PKI/ An RA for an organization. | |||
| 2. (O) /MISSI/ An end entity that (a) assists a PCA, CA, or SCA to | 2. (O) /MISSI/ An end entity that (a) assists a PCA, CA, or SCA to | |||
| register other end entities, by gathering, verifying, and entering | register other end entities, by gathering, verifying, and entering | |||
| data and forwarding it to the signing authority and (b) may also | data and forwarding it to the signing authority and (b) may also | |||
| assist with card management functions. An ORA is a local | assist with card management functions. An ORA is a local | |||
| administrative authority, and the term refers both to the role and | administrative authority, and the term refers both to the role and | |||
| to the person who plays that role. An ORA does not sign | to the person who plays that role. An ORA does not sign | |||
| certificates, CRLs, or CKLs. (See: no-PIN ORA, SSO-PIN ORA, user- | certificates, CRLs, or CKLs. (See: no-PIN ORA, SSO-PIN ORA, user- | |||
| PIN ORA.) | PIN ORA.) | |||
| $ origin authentication | $ origin authentication | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it looks like | (D) Synonym for "data origin authentication". (See: | |||
| authentication, data origin authentication.) | ||||
| Deprecated Term: ISDs SHOULD NOT use this term; it suggests | ||||
| careless use of the internationally standardized term "data origin | careless use of the internationally standardized term "data origin | |||
| authentication", and also could be confused with "peer entity | authentication" and also could be confused with "peer entity | |||
| authentication." (See: authentication.) | authentication." | |||
| $ origin authenticity | $ origin authenticity | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it looks like | (D) Synonym for "data origin authentication". (See: authenticity, | |||
| data origin authentication.) | ||||
| Deprecated Term: ISDs SHOULD NOT use this term; it suggests | ||||
| careless use of the internationally standardized term "data origin | careless use of the internationally standardized term "data origin | |||
| authentication", and mixes concepts in a potentially misleading | authentication" and mixes concepts in a potentially misleading | |||
| way. (See: authenticity, origin authentication.) | way. | |||
| $ OSI | $ OSI, OSIRM | |||
| $ OSIRM | ||||
| (N) See: Open Systems Interconnection Reference Model. | (N) See: Open Systems Interconnection Reference Model. | |||
| $ OSIRM Security Architecture | ||||
| (N) The part of the OSIRM [I7498-2] that specifies the security | ||||
| services and security mechanisms that can be applied to protect | ||||
| communications between two systems. (See: security architecture.) | ||||
| Tutorial: This part of the OSIRM includes an allocation of | ||||
| security services to protocol layers. The following table show | ||||
| which security services (see definitions in this Glossary) are | ||||
| permitted by the OSIRM in each of its layer. (Also, an application | ||||
| process that operates above the Application Layer may itself | ||||
| provide security services.) Similarly, the table suggests which | ||||
| services are suitable for each IPS layer. However, explaining and | ||||
| justifying these allocations is beyond the scope of this Glossary. | ||||
| Legend for Table Entries: | ||||
| O = Yes, [IS7498-2] permits the service in this OSIRM layer. | ||||
| I = Yes, the service can be incorporated in this IPS layer. | ||||
| IPS Protocol Layers +-----------------------------------------+ | ||||
| |Network| Net |In-| Trans | Application | | ||||
| | H/W |Inter|ter| -port | | | ||||
| | |-face|net| | | | ||||
| OSIRM Protocol Layers +-----------------------------------------+ | ||||
| | 1 | 2 | 3 | 4 | 5 | 6 | 7 # | | ||||
| Confidentiality +-----------------------------------------+ | ||||
| - Datagram | O I | O I | O I | O I | | O * | O I | | ||||
| - Selective Field | | | I | | | O * | O I | | ||||
| - Traffic Flow | O | | O | | | | O | | ||||
| -- Full | I | | | | | | | | ||||
| -- Partial | | I | I | | | | I | | ||||
| Integrity +-----------------------------------------+ | ||||
| - Datagram | I | I | O I | O I | | | O I | | ||||
| - Selective Field | | | I | | | | O I | | ||||
| - Stream | | | O I | O I | | | O I | | ||||
| Authentication +-----------------------------------------+ | ||||
| - Peer Entity | | I | O I | O I | | | O I | | ||||
| - Data Origin | | I | O I | O I | | | O I | | ||||
| Access Control +-----------------------------------------+ | ||||
| - type as appropriate | | I | O I | O I | | | O I | | ||||
| Non-Repudiation +-----------------------------------------+ | ||||
| - of Origin | | | | | | | O I | | ||||
| - of Receipt | | | | | | | O I | | ||||
| +-----------------------------------------+ | ||||
| $ OTAR | $ OTAR | |||
| (N) See: over-the-air rekeying. | (N) See: over-the-air rekeying. | |||
| $ OTP | $ OTP | |||
| (I) See: One-Time Password. | (I) See: One-Time Password. | |||
| $ out of band | $ out-of-band | |||
| 1a. (I) Transfer of information using a channel that is outside | (I) /adjective, adverb/ Information transfer using a channel or | |||
| (i.e., separate from) the main or normal channel. | method that is outside (i.e., separate from or different from) the | |||
| main channel or normal method. | ||||
| 1b. (I) Transfer of information using a means or method that | ||||
| differs from the main or normal method of communication.(See: | ||||
| covert channel.) | ||||
| Tutorial: Out-of-band mechanisms are often used to distribute | Tutorial: Out-of-band mechanisms are often used to distribute | |||
| shared secrets (e.g., a symmetric key) or other sensitive | shared secrets (e.g., a symmetric key) or other sensitive | |||
| information items (e.g., a root key) that are needed to initialize | information items (e.g., a root key) that are needed to initialize | |||
| or otherwise enable the operation of cryptography or other | or otherwise enable the operation of cryptography or other | |||
| security mechanisms. Example: Using postal mail to distribute | security mechanisms. Example: Using postal mail to distribute | |||
| printed or magnetic media containing symmetric cryptographic keys | printed or magnetic media containing symmetric cryptographic keys | |||
| for use in Internet encryption devices. (See: key distribution.) | for use in Internet encryption devices. (See: key distribution.) | |||
| $ output feedback (OFB) | $ output feedback (OFB) | |||
| skipping to change at page 173, line 31 ¶ | skipping to change at page 184, line 31 ¶ | |||
| block length. | block length. | |||
| Tutorial: This mode operates by directly using the algorithm's | Tutorial: This mode operates by directly using the algorithm's | |||
| previously generated output block as the algorithm's next input | previously generated output block as the algorithm's next input | |||
| block (i.e., by "feeding back" the output block) and combining | block (i.e., by "feeding back" the output block) and combining | |||
| (exclusive OR-ing) the output block with the next plaintext | (exclusive OR-ing) the output block with the next plaintext | |||
| segment (of block length or less) to form the next ciphertext | segment (of block length or less) to form the next ciphertext | |||
| segment. | segment. | |||
| $ outside attack | $ outside attack | |||
| (I) See: (secondary definition under) attack. Compare: outsider.) | (I) See: secondary definition under "attack". Compare: outsider.) | |||
| $ outsider | $ outsider | |||
| (I) A user (usually a person) that accesses a system from a | (I) A user (usually a person) that accesses a system from a | |||
| position that is outside the system's security perimeter. | position that is outside the system's security perimeter. | |||
| (Compare: authorized user, insider, unauthorized user.) | (Compare: authorized user, insider, unauthorized user.) | |||
| Tutorial: The actions performed by an outsider in accessing the | Tutorial: The actions performed by an outsider in accessing the | |||
| system may be either authorized or unauthorized; i.e., an outsider | system may be either authorized or unauthorized; i.e., an outsider | |||
| may act either as an authorized user or as an unauthorized user. | may act either as an authorized user or as an unauthorized user. | |||
| $ over-the-air rekeying (OTAR) | $ over-the-air rekeying (OTAR) | |||
| (N) Changing a key in a remote cryptographic device by sending a | (N) Changing a key in a remote cryptographic device by sending a | |||
| new key directly to the device via a channel that the device is | new key directly to the device via a channel that the device is | |||
| protecting. [C4009] | protecting. [C4009] | |||
| $ overload | $ overload | |||
| (I) See: (secondary definition under) obstruction. | (I) /threat action/ See: secondary definition under "obstruction". | |||
| $ P1363 | $ P1363 | |||
| (N) See: IEEE P1363. | (N) See: IEEE P1363. | |||
| $ PAA | $ PAA | |||
| (O) See: policy approving authority. | (O) See: policy approving authority. | |||
| $ package | $ package | |||
| (N) /Common Criteria/ A reusable set of either functional or | (N) /Common Criteria/ A reusable set of either functional or | |||
| assurance components (e.g. an EAL), combined in a single unit to | assurance components (e.g. an EAL), combined in a single unit to | |||
| satisfy a set of identified security objectives. | satisfy a set of identified security objectives. Example: The | |||
| seven EALs defined in Part 3 of the Common Criteria are predefined | ||||
| assurance packages. (Compare: protection profile.) | ||||
| Tutorial: A package is a combination of security requirement | Tutorial: A package is a combination of security requirement | |||
| components and is intended to be reusable in the construction of | components and is intended to be reusable in the construction of | |||
| either more complex packages or protection profiles and security | either more complex packages or protection profiles and security | |||
| targets. A package expresses a set of either functional or | targets. A package expresses a set of either functional or | |||
| assurance requirements that meet some particular need, expressed | assurance requirements that meet some particular need, expressed | |||
| as a set of security objectives. Example: The seven EALs defined | as a set of security objectives. | |||
| in Part 3 of the Common Criteria are predefined assurance | ||||
| packages. | $ packet | |||
| (I) A block of data that is carried from a source to a destination | ||||
| through a communication channel or, more generally, across a | ||||
| network. (Compare: datagram, PDU.) | ||||
| $ packet filter | $ packet filter | |||
| (I) See: (secondary definition under) filtering router. | (I) See: secondary definition under "filtering router". | |||
| $ packet monkey | $ packet monkey | |||
| (D) Someone who floods a system with packets, creating a denial- | (D) /slang/ Someone who floods a system with packets, creating a | |||
| of-service condition for the system's users.(See: cracker.) | denial-of-service condition for the system's users. (See: | |||
| cracker.) | ||||
| Deprecated Term: To avoid international misunderstanding, ISDs | ||||
| SHOULD NOT use this term. (See: Deprecated Usage under "Green | ||||
| Book".) | ||||
| $ pagejacking | $ pagejacking | |||
| (D) A contraction of "Web page hijacking". A masquerade attack in | (D) /slang/ A contraction of "Web page hijacking". A masquerade | |||
| which the attacker copies (steals) a home page or other material | attack in which the attacker copies (steals) a home page or other | |||
| from the target server, rehosts the page on a server the attacker | material from the target server, rehosts the page on a server the | |||
| controls, and causes the rehosted page to be indexed by the major | attacker controls, and causes the rehosted page to be indexed by | |||
| Web search services, thereby diverting browsers from the target | the major Web search services, thereby diverting browsers from the | |||
| server to the attacker's server. | target server to the attacker's server. | |||
| Deprecated Term: ISDs SHOULD NOT use this contraction. The term is | Deprecated Term: ISDs SHOULD NOT use this contraction. The term is | |||
| not listed in most dictionaries and could confuse international | not listed in most dictionaries and could confuse international | |||
| readers. (See: (Deprecated Usage under) Green Book.) | readers. (See: Deprecated Usage under "Green Book".) | |||
| $ PAN | $ PAN | |||
| (O) See: primary account number. | (O) See: primary account number. | |||
| $ PAP | $ PAP | |||
| (I) See: Password Authentication Protocol. | (I) See: Password Authentication Protocol. | |||
| $ parity bit | $ parity bit | |||
| (I) A checksum that is computed on a block of bits by computing | (I) A checksum that is computed on a block of bits by computing | |||
| the binary sum of the individual bits in the block and then | the binary sum of the individual bits in the block and then | |||
| discarding all but the low-order bit of the sum. | discarding all but the low-order bit of the sum. (See: checksum.) | |||
| $ partitioned security mode | $ partitioned security mode | |||
| (N) A mode of operation of an information system, wherein all | (N) A mode of system operation wherein all users having access to | |||
| users have the clearance, but not necessarily formal access | the system have the necessary security clearances for all data | |||
| authorization and need-to-know, for all data handled by the | handled by the system, but some users might not have either formal | |||
| system. This mode is defined in U.S. DoD policy regarding system | access approval or need-to-know for all the data. (See: /system | |||
| accreditation. [DoD2] | operation/ under "mode", formal access approval, need to know, | |||
| protection level, security clearance.) | ||||
| Usage: Usually abbreviated as "partitioned mode". This term was | ||||
| defined in U.S. Government policy on system accreditation. | ||||
| $ PASS | $ PASS | |||
| (N) See: personnel authentication system string. | (N) See: personnel authentication system string. | |||
| $ passive attack | $ passive attack | |||
| (I) See: (secondary definition under) attack. | (I) See: secondary definition under "attack". | |||
| $ passive user | ||||
| (I) See: secondary definition under "user". | ||||
| $ passive wiretapping | $ passive wiretapping | |||
| (I) A wiretapping attack that attempts only to observer | (I) A wiretapping attack that attempts only to observe a | |||
| communication flow and gain knowledge of the data it contains, but | communication flow and gain knowledge of the data it contains, but | |||
| does not alter or otherwise affect that flow. (See: wiretapping. | does not alter or otherwise affect that flow. (See: wiretapping. | |||
| Compare: passive attack, active wiretapping.) | Compare: passive attack, active wiretapping.) | |||
| $ password | $ password | |||
| (I) A secret data value, usually a character string, that is | (I) A secret data value, usually a character string, that is | |||
| presented to a system by a user to authenticate the user's | presented to a system by a user to authenticate the user's | |||
| identity. (See: challenge-response, PIN, simple authentication.) | identity. (See: authentication information, challenge-response, | |||
| PIN, simple authentication.) | ||||
| (O) "A character string used to authenticate an identity." [CSC2] | (O) "A character string used to authenticate an identity." [CSC2] | |||
| (O) "A string of characters (letters, numbers, and other symbols) | (O) "A string of characters (letters, numbers, and other symbols) | |||
| used to authenticate an identity or to verify access | used to authenticate an identity or to verify access | |||
| authorization." [FP140] | authorization." [FP140] | |||
| (O) "A secret that a claimant memorizes and uses to authenticate | (O) "A secret that a claimant memorizes and uses to authenticate | |||
| his or her identity. Passwords are typically character strings." | his or her identity. Passwords are typically character strings." | |||
| [SP63] | [SP63] | |||
| skipping to change at page 175, line 53 ¶ | skipping to change at page 187, line 17 ¶ | |||
| passwords in cleartext form is inadequate. (See: one-time | passwords in cleartext form is inadequate. (See: one-time | |||
| password, strong authentication.) | password, strong authentication.) | |||
| $ Password Authentication Protocol (PAP) | $ Password Authentication Protocol (PAP) | |||
| (I) A simple authentication mechanism in PPP. In PAP, a user | (I) A simple authentication mechanism in PPP. In PAP, a user | |||
| identifier and password are transmitted in cleartext form. [R1334] | identifier and password are transmitted in cleartext form. [R1334] | |||
| (See: CHAP.) | (See: CHAP.) | |||
| $ password sniffing | $ password sniffing | |||
| (I) Passive wiretapping, usually on a LAN, to gain knowledge of | (I) Passive wiretapping, usually on a LAN, to gain knowledge of | |||
| passwords. (See: (Deprecated Usage note under) sniffing.) | passwords. (See: Deprecated Usage under "sniffing".) | |||
| $ path discovery | $ path discovery | |||
| (I) For a digital certificate, the process of finding a set of | (I) For a digital certificate, the process of finding a set of | |||
| public-key certificates that comprise a certification path from a | public-key certificates that comprise a certification path from a | |||
| trusted key to that specific certificate. | trusted key to that specific certificate. | |||
| $ path validation | $ path validation | |||
| (I) The process of validating (a) all of the digital certificates | (I) The process of validating (a) all of the digital certificates | |||
| in a certification path and (b) the required relationships between | in a certification path and (b) the required relationships between | |||
| those certificates, thus validating the contents of the last | those certificates, thus validating the contents of the last | |||
| skipping to change at page 176, line 53 ¶ | skipping to change at page 188, line 20 ¶ | |||
| Tutorial: The international PC Card Standard defines a non- | Tutorial: The international PC Card Standard defines a non- | |||
| proprietary form factor in three sizes -- Types I, II and III -- | proprietary form factor in three sizes -- Types I, II and III -- | |||
| each of which have a 68-pin interface between the card and the | each of which have a 68-pin interface between the card and the | |||
| socket into which it plugs. All three types have the same length | socket into which it plugs. All three types have the same length | |||
| and width, roughly the size of a credit card, but differ in their | and width, roughly the size of a credit card, but differ in their | |||
| thickness from 3.3 to 10.5 mm. Examples include storage modules, | thickness from 3.3 to 10.5 mm. Examples include storage modules, | |||
| modems, device interface adapters, and cryptographic modules. | modems, device interface adapters, and cryptographic modules. | |||
| $ PCA | $ PCA | |||
| Deprecated Term: ISDs SHOULD NOT use this acronym without a | (D) Abbreviation of various kinds of "certification authority". | |||
| qualifying adjective; that would be ambiguous. (See: Internet | (See: Internet policy certification authority, (MISSI) policy | |||
| policy certification authority, (MISSI) policy creation authority, | creation authority, (SET) payment gateway certification | |||
| (SET) payment gateway certification authority.) | authority.) | |||
| Deprecated Abbreviation: An ISD that uses this abbreviation SHOULD | ||||
| define it at the point of first use. | ||||
| $ PCI | ||||
| (N) See: "protocol control information" under "protocol data | ||||
| unit". | ||||
| $ PCMCIA | $ PCMCIA | |||
| (N) Personal Computer Memory Card International Association, a | (N) Personal Computer Memory Card International Association, a | |||
| group of manufacturers, developers, and vendors, founded in 1989 | group of manufacturers, developers, and vendors, founded in 1989 | |||
| to standardize plug-in peripheral memory cards for personal | to standardize plug-in peripheral memory cards for personal | |||
| computers and now extended to deal with any technology that works | computers and now extended to deal with any technology that works | |||
| in the PC Card form factor. (See: PC card.) | in the PC Card form factor. (See: PC card.) | |||
| $ PDS | $ PDS | |||
| (N) See: protective distribution system. | (N) See: protective distribution system. | |||
| $ PDU | ||||
| (N) See: protocol data unit. | ||||
| $ peer entity authentication | $ peer entity authentication | |||
| (I) "The corroboration that a peer entity in an association is the | (I) "The corroboration that a peer entity in an association is the | |||
| one claimed." [I7498 Part 2] (See: authentication.) | one claimed." [I7498 Part 2] (See: authentication.) | |||
| $ peer entity authentication service | $ peer entity authentication service | |||
| (I) A security service that verifies an identity claimed by or for | (I) A security service that verifies an identity claimed by or for | |||
| a system entity in an association. (See: authentication, | a system entity in an association. (See: authentication, | |||
| authentication service.) | authentication service.) | |||
| Tutorial: This service is used at the establishment of, or at | Tutorial: This service is used at the establishment of, or at | |||
| times during, an association to confirm the identity of one entity | times during, an association to confirm the identity of one entity | |||
| to another, thus protecting against a masquerade by the first | to another, thus protecting against a masquerade by the first | |||
| entity. However, unlike data origin authentication service, this | entity. However, unlike data origin authentication service, this | |||
| service requires an association to exist between the two entities, | service requires an association to exist between the two entities, | |||
| and the corroboration provided by the service is valid only at the | and the corroboration provided by the service is valid only at the | |||
| current time that the service is provided. (See: ("relationship | current time that the service is provided. (See: "relationship | |||
| between data integrity service and authentication services" under) | between data integrity service and authentication services" under | |||
| data integrity service). | "data integrity service"). | |||
| $ PEM | $ PEM | |||
| (I) See: Privacy Enhanced Mail. | (I) See: Privacy Enhanced Mail. | |||
| $ penetrate | $ penetrate | |||
| 1a. Circumvent a system's security protections. (See: attack, | 1a. Circumvent a system's security protections. (See: attack, | |||
| break, violation.) | break, violation.) | |||
| 1b. (I) Successfully and repeatedly gain unauthorized access to a | 1b. (I) Successfully and repeatedly gain unauthorized access to a | |||
| protected system resource. [Huff] | protected system resource. [Huff] | |||
| skipping to change at page 178, line 10 ¶ | skipping to change at page 189, line 38 ¶ | |||
| a system by using tools and techniques that are available to | a system by using tools and techniques that are available to | |||
| adversaries. Testing may be performed under various constraints | adversaries. Testing may be performed under various constraints | |||
| and conditions, including a specified level of knowledge of the | and conditions, including a specified level of knowledge of the | |||
| system design and implementation. For a TCSEC evaluation, testers | system design and implementation. For a TCSEC evaluation, testers | |||
| are assumed to have all system design and implementation | are assumed to have all system design and implementation | |||
| documentation, including source code, manuals, and circuit | documentation, including source code, manuals, and circuit | |||
| diagrams, and to work under no greater constraints than those | diagrams, and to work under no greater constraints than those | |||
| applied to ordinary users. | applied to ordinary users. | |||
| $ perfect forward secrecy | $ perfect forward secrecy | |||
| (I) See: (usage discussion under) public-key forward secrecy. | (I) See: Usage under "public-key forward secrecy". | |||
| $ perimeter | $ perimeter | |||
| See: security perimeter. | See: security perimeter. | |||
| $ periods processing | $ periods processing | |||
| (I) A mode of system operation in which information of different | (I) A mode of system operation in which information of different | |||
| sensitivities is processed at distinctly different times by the | sensitivities is processed at distinctly different times by the | |||
| same system, with the system being properly purged or sanitized | same system, with the system being properly purged or sanitized | |||
| between periods. (See: color change.) | between periods. (See: color change.) | |||
| skipping to change at page 178, line 35 ¶ | skipping to change at page 190, line 12 ¶ | |||
| system to the completion of any purging of sensitive data handled | system to the completion of any purging of sensitive data handled | |||
| by the system during the period. | by the system during the period. | |||
| $ permanent storage | $ permanent storage | |||
| (I) Non-volatile media that, once written into, can never be | (I) Non-volatile media that, once written into, can never be | |||
| completely erased. | completely erased. | |||
| $ permission | $ permission | |||
| 1a. (I) A synonym for "authorization". (Compare: privilege.) | 1a. (I) A synonym for "authorization". (Compare: privilege.) | |||
| 1b. (I) An authorization or set of authorizations to perform | 1b. (N) An authorization or set of authorizations to perform | |||
| security-relevant functions in the context of role-based access | security-relevant functions in the context of role-based access | |||
| control. [ANSI] | control. [ANSI] | |||
| Tutorial: A permission is a positively-stated authorization for | Tutorial: A permission is a positively stated authorization for | |||
| access that (a) can be associated with one or more roles and (b) | access that (a) can be associated with one or more roles and (b) | |||
| enables a user in a role to access a specified set of system | enables a user in a role to access a specified set of system | |||
| resources by causing a specific set of system actions to be | resources by causing a specific set of system actions to be | |||
| performed on the resources. | performed on the resources. | |||
| $ persona certificate | $ persona certificate | |||
| (I) An X.509 certificate issued to a system entity that wishes to | (I) An X.509 certificate issued to a system entity that wishes to | |||
| use a persona to conceal its true identity when using PEM or other | use a persona to conceal its true identity when using PEM or other | |||
| Internet services that depend on PKI support. (See: anonymity.) | Internet services that depend on PKI support. (See: anonymity.) | |||
| [R1422] | [R1422] | |||
| skipping to change at page 179, line 35 ¶ | skipping to change at page 191, line 11 ¶ | |||
| seldom serves as a user identifier, and a PIN's characters are not | seldom serves as a user identifier, and a PIN's characters are not | |||
| necessarily all numeric. Retail banking applications use 4-digit | necessarily all numeric. Retail banking applications use 4-digit | |||
| numeric user PINs, but the FORTEZZA PC card uses 12-character | numeric user PINs, but the FORTEZZA PC card uses 12-character | |||
| alphanumeric SSO PINs. | alphanumeric SSO PINs. | |||
| Thus, a better name for this concept would have been "personnel | Thus, a better name for this concept would have been "personnel | |||
| authentication system string" (PASS), in which case an | authentication system string" (PASS), in which case an | |||
| alphanumeric character string for this purpose would have been | alphanumeric character string for this purpose would have been | |||
| called, obviously, a "PASSword". | called, obviously, a "PASSword". | |||
| $ personal information | ||||
| (I) Information about a particular person, especially information | ||||
| of an intimate or critical nature, that could cause harm or pain | ||||
| to that person if disclosed to unauthorized parties. Examples: | ||||
| medical record, arrest record, credit report, academic transcript, | ||||
| training report, job application, credit card number, Social | ||||
| Security number. (See: privacy.) | ||||
| $ personality | $ personality | |||
| 1. (I) Synonym for "principal". | 1. (I) Synonym for "principal". | |||
| 2. (O) /MISSI/ A set of MISSI X.509 public-key certificates that | 2. (O) /MISSI/ A set of MISSI X.509 public-key certificates that | |||
| have the same subject DN, together with their associated private | have the same subject DN, together with their associated private | |||
| keys and usage specifications, that is stored on a FORTEZZA PC | keys and usage specifications, that is stored on a FORTEZZA PC | |||
| card to support a role played by the card's user. | card to support a role played by the card's user. | |||
| Tutorial: When a card's user selects a personality to use in a | Tutorial: When a card's user selects a personality to use in a | |||
| FORTEZZA-aware application, the data determines behavior traits | FORTEZZA-aware application, the data determines behavior traits | |||
| skipping to change at page 180, line 6 ¶ | skipping to change at page 191, line 41 ¶ | |||
| label", a user-friendly character string that applications can | label", a user-friendly character string that applications can | |||
| display to the user for selecting or changing the personality to | display to the user for selecting or changing the personality to | |||
| be used. For example, a military user's card might contain three | be used. For example, a military user's card might contain three | |||
| personalities: GENERAL HALFTRACK, COMMANDER FORT SWAMPY, and NEW | personalities: GENERAL HALFTRACK, COMMANDER FORT SWAMPY, and NEW | |||
| YEAR'S EVE PARTY CHAIRMAN. Each personality includes one or more | YEAR'S EVE PARTY CHAIRMAN. Each personality includes one or more | |||
| certificates of different types (such as DSA versus RSA), for | certificates of different types (such as DSA versus RSA), for | |||
| different purposes (such as digital signature versus encryption), | different purposes (such as digital signature versus encryption), | |||
| or with different authorizations. | or with different authorizations. | |||
| $ personnel authentication system string (PASS) | $ personnel authentication system string (PASS) | |||
| (N) See: (Tutorial under) personal identification number. | (N) See: Tutorial under "personal identification number". | |||
| $ personnel security | $ personnel security | |||
| (I) Procedures to ensure that persons who access a system have | (I) Procedures to ensure that persons who access a system have | |||
| proper clearance, authorization, and need-to-know as required by | proper clearance, authorization, and need-to-know as required by | |||
| the system's security policy. | the system's security policy. | |||
| $ PGP(trademark) | $ PGP(trademark) | |||
| (O) See: Pretty Good Privacy(trademark). | (O) See: Pretty Good Privacy(trademark). | |||
| $ phase 1 negotiation | ||||
| $ phase 2 negotiation | ||||
| (I) /ISAKMP/ See: secondary definition under "Internet Security | ||||
| Association and Key Management Protocol". | ||||
| $ Photuris | $ Photuris | |||
| (I) A UDP-based, key establishment protocol for session keys, | (I) A UDP-based, key establishment protocol for session keys, | |||
| designed for use with the IPsec protocols AH and ESP. Superseded | designed for use with the IPsec protocols AH and ESP. Superseded | |||
| by IKE. | by IKE. | |||
| $ phreaking | $ phreaking | |||
| (D) A contraction of "telephone breaking". An attack on or | (D) A contraction of "telephone breaking". An attack on or | |||
| penetration of a telephone system or, by extension, any other | penetration of a telephone system or, by extension, any other | |||
| communication or information system. [Raym] | communication or information system. [Raym] | |||
| skipping to change at page 180, line 42 ¶ | skipping to change at page 192, line 31 ¶ | |||
| system. Examples: Fences, walls, and other barriers; locks, safes, | system. Examples: Fences, walls, and other barriers; locks, safes, | |||
| and vaults; dogs and armed guards; sensors and alarm bells. | and vaults; dogs and armed guards; sensors and alarm bells. | |||
| [FP031, R1455] | [FP031, R1455] | |||
| $ piggyback attack | $ piggyback attack | |||
| (I) A form of active wiretapping in which the attacker gains | (I) A form of active wiretapping in which the attacker gains | |||
| access to a system via intervals of inactivity in another user's | access to a system via intervals of inactivity in another user's | |||
| legitimate communication connection. Sometimes called a "between- | legitimate communication connection. Sometimes called a "between- | |||
| the-lines" attack. (See: hijack attack, man-in-the-middle attack.) | the-lines" attack. (See: hijack attack, man-in-the-middle attack.) | |||
| Deprecated Usage: This term could confuse international readers; | Deprecated Usage: ISDs that use this term SHOULD state a | |||
| therefore, ISDs that use it SHOULD state a definition for it. | definition for it because the term could confuse international | |||
| readers. | ||||
| $ PIN | $ PIN | |||
| (I) See: personal identification number. | (I) See: personal identification number. | |||
| $ ping of death | $ ping of death | |||
| (D) A denial-of-service attack that sends an improperly large ICMP | (D) A denial-of-service attack that sends an improperly large ICMP | |||
| echo request packet (a "ping") with the intent of causing the | echo request packet (a "ping") with the intent of causing the | |||
| destination system to fail. (See: ping sweep, teardrop.) | destination system to fail. (See: ping sweep, teardrop.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term; instead, use "ping | Deprecated Term: ISDs SHOULD NOT use this term; instead, use "ping | |||
| skipping to change at page 181, line 47 ¶ | skipping to change at page 193, line 36 ¶ | |||
| requests for public-key certificates. (See: certification | requests for public-key certificates. (See: certification | |||
| request.) | request.) | |||
| Tutorial: A PKCS #10 request contains a DN and a public key, and | Tutorial: A PKCS #10 request contains a DN and a public key, and | |||
| may contain other attributes, and is signed by the entity making | may contain other attributes, and is signed by the entity making | |||
| the request. The request is sent to a CA, who converts it to an | the request. The request is sent to a CA, who converts it to an | |||
| X.509 public-key certificate (or some other form), and returns it, | X.509 public-key certificate (or some other form), and returns it, | |||
| possibly in PKCS #7 format. | possibly in PKCS #7 format. | |||
| $ PKCS #11 | $ PKCS #11 | |||
| (N) A standard [PKC11] from the PKCS series; defines a software | (N) A standard [PKC11] from the PKCS series; defines CAPI called | |||
| CAPI called Cryptoki (an abbreviation of "cryptographic token | "Cryptoki" for devices that hold cryptographic information and | |||
| interface", pronounced "CRYPTO-key") for devices that hold | perform cryptographic functions. | |||
| cryptographic information and perform cryptographic functions. | ||||
| $ PKI | $ PKI | |||
| (I) See: public-key infrastructure. | (I) See: public-key infrastructure. | |||
| $ PKIX | $ PKIX | |||
| 1a. (I) A contraction of "Public-Key Infrastructure (X.509)", the | 1a. (I) A contraction of "Public-Key Infrastructure (X.509)", the | |||
| name of the IETF working group that is specifying an architecture | name of the IETF working group that is specifying an architecture | |||
| [R3280] and set of protocols [R2510] to provide X.509-based PKI | [R3280] and set of protocols [R2510] to provide X.509-based PKI | |||
| services for the Internet. | services for the Internet. | |||
| skipping to change at page 182, line 26 ¶ | skipping to change at page 194, line 15 ¶ | |||
| environments and a range of usage environments. PKIX specifies (a) | environments and a range of usage environments. PKIX specifies (a) | |||
| profiles of the v3 X.509 public-key certificate standards and the | profiles of the v3 X.509 public-key certificate standards and the | |||
| v2 X.509 CRL standards for the Internet, (b) operational protocols | v2 X.509 CRL standards for the Internet, (b) operational protocols | |||
| used by relying parties to obtain information such as certificates | used by relying parties to obtain information such as certificates | |||
| or certificate status, (c) management protocols used by system | or certificate status, (c) management protocols used by system | |||
| entities to exchange information needed for proper management of | entities to exchange information needed for proper management of | |||
| the PKI, and (d) information about certificate policies and CPSs, | the PKI, and (d) information about certificate policies and CPSs, | |||
| covering the areas of PKI security not directly addressed in the | covering the areas of PKI security not directly addressed in the | |||
| rest of PKIX. | rest of PKIX. | |||
| $ PKIX private extension | ||||
| (I) PKIX defines an private extension to identify an on-line | ||||
| verification service supporting the issuing CA. | ||||
| $ plain text | $ plain text | |||
| (I) /noun/ Data that is input to and transformed by an encryption | (I) /noun/ Data that is input to and transformed by an encryption | |||
| process, or that is output from a decryption process. (Compare: | process, or that is output from a decryption process. (See: | |||
| plaintext.) | plaintext. Compare: cipher text, clear text.) | |||
| Tutorial: Usually, the plain text that is the input to an | Tutorial: Usually, the plain text that is the input to an | |||
| encryption operation is clear text. But in some cases, the input | encryption operation is clear text, but the input could be cipher | |||
| is cipher text that was output from another encryption operation. | text that was output from another encryption operation. (See: | |||
| (See: superencryption.) | superencryption.) | |||
| $ plaintext | $ plaintext | |||
| 1a. (I) /adjective/ Referring to plain text. (See: plain text.) | 1. (I) /adjective/ Referring to plain text. (See: plain text. | |||
| Compare: ciphertext, cleartext.) | ||||
| 1b. (D) /noun/ A synonym for plain text. | 2. (D) /noun/ A synonym for plain text. | |||
| Deprecated Usage: To avoid ambiguity, ISDs SHOULD differentiate | Deprecated Usage: ISDs should not use this term as a synonym for | |||
| between the noun phrase "plain text" and adjective "plaintext". | "plain text". ISDs SHOULD distinguish between the adjective | |||
| "plaintext" and the noun phrase "plain text". | ||||
| $ PLI | $ PLI | |||
| (I) See: Private Line Interface. | (I) See: Private Line Interface. | |||
| $ Point-to-Point Protocol (PPP) | $ Point-to-Point Protocol (PPP) | |||
| (I) An Internet Standard protocol (RFC 1661) for encapsulation and | (I) An Internet Standard protocol (RFC 1661) for encapsulation and | |||
| full-duplex transportation of protocol data packets in OSIRM layer | full-duplex transportation of protocol data packets in OSIRM Layer | |||
| 3 over an OSIRM layer 2 link between two peers, and for | 3 over an OSIRM Layer 2 link between two peers, and for | |||
| multiplexing different layer 3 protocols over the same link. | multiplexing different Layer 3 protocols over the same link. | |||
| Includes optional negotiation to select and use a peer entity | Includes optional negotiation to select and use a peer entity | |||
| authentication protocol to authenticate the peers to each other | authentication protocol to authenticate the peers to each other | |||
| before they exchange layer 3 data. (See: CHAP, EAP, PAP.) | before they exchange Layer 3 data. (See: CHAP, EAP, PAP.) | |||
| $ Point-to-Point Tunneling Protocol (PPTP) | $ Point-to-Point Tunneling Protocol (PPTP) | |||
| (I) An Internet client-server protocol (RFC 2637) (originally | (I) An Internet client-server protocol (RFC 2637) (originally | |||
| developed by Ascend and Microsoft) that enables a dial-up user to | developed by Ascend and Microsoft) that enables a dial-up user to | |||
| create a virtual extension of the dial-up link across a network by | create a virtual extension of the dial-up link across a network by | |||
| tunneling PPP over IP. (See: L2TP.) | tunneling PPP over IP. (See: L2TP.) | |||
| Tutorial: PPP can encapsulate any IPS network layer protocol or | Tutorial: PPP can encapsulate any IPS Network Interface Layer | |||
| OSIRM layer 3 protocol. Therefore, PPTP does not specify security | protocol or OSIRM Layer 3 protocol. Therefore, PPTP does not | |||
| services; it depends on protocols above and below it to provide | specify security services; it depends on protocols above and below | |||
| any needed security. PPTP makes it possible to divorce the | it to provide any needed security. PPTP makes it possible to | |||
| location of the initial dial-up server (i.e., the PPTP Access | divorce the location of the initial dial-up server (i.e., the PPTP | |||
| Concentrator, the client, which runs on a special-purpose host) | Access Concentrator, the client, which runs on a special-purpose | |||
| from the location at which the dial-up protocol (PPP) connection | host) from the location at which the dial-up protocol (PPP) | |||
| is terminated and access to the network is provided (i.e., at the | connection is terminated and access to the network is provided | |||
| PPTP Network Server, which runs on a general-purpose host). | (i.e., at the PPTP Network Server, which runs on a general-purpose | |||
| host). | ||||
| $ policy | $ policy | |||
| 1a. (I) A plan or course of action that is stated for a system or | 1a. (I) A plan or course of action that is stated for a system or | |||
| organization and is intended to affect and direct the decisions | organization and is intended to affect and direct the decisions | |||
| and deeds of that entity's components or members. (See: security | and deeds of that entity's components or members. (See: security | |||
| policy.) | policy.) | |||
| 1b. (O) A definite goal, course, or method of action to guide and | 1b. (O) A definite goal, course, or method of action to guide and | |||
| determine present and future decisions, that is implemented or | determine present and future decisions, that is implemented or | |||
| executed within a particular context, such as within a business | executed within a particular context, such as within a business | |||
| unit. [R3198] | unit. [R3198] | |||
| Deprecated Usage: ISDs SHOULD NOT use "policy" as an abbreviation | Deprecated Abbreviation: ISDs SHOULD NOT use "policy" as an | |||
| for either "security policy" or "certificate policy". Instead, to | abbreviation of either "security policy" or "certificate policy". | |||
| avoid misunderstanding, use a fully qualified term, at least at | Instead, to avoid misunderstanding, use a fully qualified term, at | |||
| the point of first usage. | least at the point of first usage. | |||
| Tutorial: The introduction of new technology to replace | Tutorial: The introduction of new technology to replace | |||
| traditional systems can result in new systems being deployed | traditional systems can result in new systems being deployed | |||
| without adequate policy definition and before the implications of | without adequate policy definition and before the implications of | |||
| the new technology are fully understand. In some cases, it can be | the new technology are fully understand. In some cases, it can be | |||
| difficult to establish policies for new technology before the | difficult to establish policies for new technology before the | |||
| technology has been operationally tested and evaluated. Thus, | technology has been operationally tested and evaluated. Thus, | |||
| policy changes tend to lag behind technological changes, such that | policy changes tend to lag behind technological changes, such that | |||
| either old policies impede the technical innovation, or the new | either old policies impede the technical innovation, or the new | |||
| technology is deployed without adequate policies to govern its | technology is deployed without adequate policies to govern its | |||
| use. | use. | |||
| When new technology changes the ways that things are done, new | When new technology changes the ways that things are done, new | |||
| "procedures" must be defined to establish operational guidelines | "procedures" must be defined to establish operational guidelines | |||
| for using the technology and achieving satisfactory results, and | for using the technology and achieving satisfactory results, and | |||
| new "practices" must be established for managing new systems and | new "practices" must be established for managing new systems and | |||
| monitoring results. Practices and procedures are more directly | monitoring results. Practices and procedures are more directly | |||
| coupled to actual systems and business operations than are | coupled to actual systems and business operations than are | |||
| polices, which tend to be more abstract. | polices, which tend to be more abstract. | |||
| - "Practices" define how a system is to be managed and what | - "Practices" define how a system is to be managed and what | |||
| controls are in place to monitor the system and detect abnormal | controls are in place to monitor the system and detect abnormal | |||
| behavior or quality problems. Practices are established to | behavior or quality problems. Practices are established to | |||
| ensure that a system is managed in compliance with stated | ensure that a system is managed in compliance with stated | |||
| policies. System audits are primarily concerned with whether or | policies. System audits are primarily concerned with whether or | |||
| not practices are being followed. Auditors evaluate the | not practices are being followed. Auditors evaluate the | |||
| controls to make sure they conform to accepted industry | controls to make sure they conform to accepted industry | |||
| standards, and then confirm that controls are in place and that | standards, and then confirm that controls are in place and that | |||
| control measurements are being gathered. Audit trails are | control measurements are being gathered. Audit trails are | |||
| examples of control measurements that are recorded as part of | examples of control measurements that are recorded as part of | |||
| system operations. | system operations. | |||
| - "Procedures" define how a system is operated, and relate | - "Procedures" define how a system is operated, and relate | |||
| closely to issues of what technology is used, who the operators | closely to issues of what technology is used, who the operators | |||
| are, and how the system is deployed physically. Procedures | are, and how the system is deployed physically. Procedures | |||
| define both normal and abnormal operating circumstances. | define both normal and abnormal operating circumstances. | |||
| For every control defined by a practice statement, there should be | - For every control defined by a practice statement, there should | |||
| corresponding procedures to implement the control and provide | be corresponding procedures to implement the control and | |||
| ongoing measurement of the control parameters. Conversely, | provide ongoing measurement of the control parameters. | |||
| procedures require management practices to insure consistent and | Conversely, procedures require management practices to insure | |||
| correct operational behavior. | consistent and correct operational behavior. | |||
| $ policy approving authority (PAA) | $ policy approving authority (PAA) | |||
| (O) /MISSI/ The top-level signing authority of a MISSI | (O) /MISSI/ The top-level signing authority of a MISSI | |||
| certification hierarchy. The term refers both to that | certification hierarchy. The term refers both to that | |||
| authoritative office or role and to the person who plays that | authoritative office or role and to the person who plays that | |||
| role. (See: root registry.) | role. (See: root registry.) | |||
| Tutorial: A PAA registers MISSI PCAs and signs their X.509 public- | Tutorial: A PAA registers MISSI PCAs and signs their X.509 public- | |||
| key certificates. A PAA issues CRLs but does not issue a CKL. A | key certificates. A PAA issues CRLs but does not issue a CKL. A | |||
| PAA may issue cross-certificates to other PAAs. | PAA may issue cross-certificates to other PAAs. | |||
| skipping to change at page 185, line 7 ¶ | skipping to change at page 196, line 47 ¶ | |||
| office. (See: policy certification authority.) | office. (See: policy certification authority.) | |||
| Tutorial: A MISSI PCA's certificate is issued by a PAA. The PCA | Tutorial: A MISSI PCA's certificate is issued by a PAA. The PCA | |||
| registers the CAs in its domain, defines their configurations, and | registers the CAs in its domain, defines their configurations, and | |||
| issues their X.509 public-key certificates. (The PCA may also | issues their X.509 public-key certificates. (The PCA may also | |||
| issue certificates for SCAs, ORAs, and other end entities, but a | issue certificates for SCAs, ORAs, and other end entities, but a | |||
| PCA does not usually do this.) The PCA periodically issues CRLs | PCA does not usually do this.) The PCA periodically issues CRLs | |||
| and CKLs for its domain. | and CKLs for its domain. | |||
| $ Policy Management Authority | $ Policy Management Authority | |||
| (N) Canadian usage: An organization responsible for PKI oversight | (O) Canadian usage: An organization responsible for PKI oversight | |||
| and policy management in the Government of Canada. | and policy management in the Government of Canada. | |||
| $ policy mapping | $ policy mapping | |||
| (I) "Recognizing that, when a CA in one domain certifies a CA in | (I) "Recognizing that, when a CA in one domain certifies a CA in | |||
| another domain, a particular certificate policy in the second | another domain, a particular certificate policy in the second | |||
| domain may be considered by the authority of the first domain to | domain may be considered by the authority of the first domain to | |||
| be equivalent (but not necessarily identical in all respects) to a | be equivalent (but not necessarily identical in all respects) to a | |||
| particular certificate policy in the first domain." [X509] | particular certificate policy in the first domain." [X509] | |||
| $ policy rule | ||||
| (I) A building block of a security policy; it (a) defines a set of | ||||
| system conditions and (b) specifies a set of system actions that | ||||
| are to be performed if those conditions occur. [R3198] | ||||
| $ POP3 | $ POP3 | |||
| (I) See: Post Office Protocol, version 3. | (I) See: Post Office Protocol, version 3. | |||
| $ POP3 APOP | $ POP3 APOP | |||
| (I) A POP3 command (i.e., a transaction type, or a protocol- | (I) A POP3 command (better described as a transaction type, or | |||
| within-a-protocol) by which a POP3 client optionally uses a keyed | subprotocol) by which a POP3 client optionally uses a keyed hash | |||
| hash (based on MD5) to authenticate itself to a POP3 server and, | (based on MD5) to authenticate itself to a POP3 server and, | |||
| depending on the server implementation, to protect against replay | depending on the server implementation, to protect against replay | |||
| attacks. (See: CRAM, POP3 AUTH, IMAP4 AUTHENTICATE.) | attacks. (See: CRAM, POP3 AUTH, IMAP4 AUTHENTICATE.) | |||
| Tutorial: The server includes a unique timestamp in its greeting | Tutorial: The server includes a unique timestamp in its greeting | |||
| to the client. The subsequent APOP command sent by the client to | to the client. The subsequent APOP command sent by the client to | |||
| the server contains the client's name and the hash result of | the server contains the client's name and the hash result of | |||
| applying MD5 to a string formed from both the timestamp and a | applying MD5 to a string formed from both the timestamp and a | |||
| shared secret that is known only to the client and the server. | shared secret value that is known only to the client and the | |||
| APOP was designed to provide an alternative to using POP3's USER | server. APOP was designed to provide an alternative to using | |||
| and PASS (i.e., password) command pair, in which the client sends | POP3's USER and PASS (i.e., password) command pair, in which the | |||
| a cleartext password to the server. | client sends a cleartext password to the server. | |||
| $ POP3 AUTH | $ POP3 AUTH | |||
| (I) A POP3 command [R1734] (i.e., a transaction type, or a | (I) A POP3 command [R1734] (better described as a transaction | |||
| protocol-within-a-protocol) by which a POP3 client optionally | type, or subprotocol) by which a POP3 client optionally proposes a | |||
| proposes a mechanism to a POP3 server to authenticate the client | mechanism to a POP3 server to authenticate the client to the | |||
| to the server and provide other security services. (See: POP3 | server and provide other security services. (See: POP3 APOP, IMAP4 | |||
| APOP, IMAP4 AUTHENTICATE.) | AUTHENTICATE.) | |||
| Tutorial: If the server accepts the proposal, the command is | Tutorial: If the server accepts the proposal, the command is | |||
| followed by performing a challenge-response authentication | followed by performing a challenge-response authentication | |||
| protocol and, optionally, negotiating a protection mechanism for | protocol and, optionally, negotiating a protection mechanism for | |||
| subsequent POP3 interactions. The security mechanisms used by POP3 | subsequent POP3 interactions. The security mechanisms used by POP3 | |||
| AUTH are those used by IMAP4. | AUTH are those used by IMAP4. | |||
| $ port scan | $ port scan | |||
| (I) An attack that sends client requests to a range of server port | (I) An attack that sends client requests to a range of server port | |||
| addresses on a host, with the goal of finding an active port and | addresses on a host, with the goal of finding an active port and | |||
| skipping to change at page 186, line 42 ¶ | skipping to change at page 198, line 35 ¶ | |||
| client to a server and providing other security services. (See: | client to a server and providing other security services. (See: | |||
| POP3 APOP, POP3 AUTH.) | POP3 APOP, POP3 AUTH.) | |||
| $ PPP | $ PPP | |||
| (I) See: Point-to-Point Protocol. | (I) See: Point-to-Point Protocol. | |||
| $ PPTP | $ PPTP | |||
| (I) See: Point-to-Point Tunneling Protocol. | (I) See: Point-to-Point Tunneling Protocol. | |||
| $ preauthorization | $ preauthorization | |||
| (I) A CAW capability that enables certification requests to be | (N) /PKI/ A CAW feature that enables certification requests to be | |||
| automatically validated against data provided in advance to the CA | automatically validated against data provided in advance to the CA | |||
| by an authorizing entity. | by an authorizing entity. | |||
| $ precedence | $ precedence | |||
| (N) A designation assigned to a communication (i.e., packet, | (N) A designation assigned to a communication (i.e., packet, | |||
| message, data stream, connection, etc.) by the originator to state | message, data stream, connection, etc.) by the originator to state | |||
| the importance or urgency of that communication versus other | the importance or urgency of that communication versus other | |||
| communications, and thus indicate to the transmission system the | communications, and thus indicate to the transmission system the | |||
| relative order of handling, and indicate to the receiver the order | relative order of handling, and indicate to the receiver the order | |||
| in which the communication is to be noted. [F1037] (See: | in which the communication is to be noted. [F1037] (See: | |||
| skipping to change at page 187, line 28 ¶ | skipping to change at page 199, line 21 ¶ | |||
| (O) Trademarks of Network Associates, Inc., referring to a | (O) Trademarks of Network Associates, Inc., referring to a | |||
| computer program (and related protocols) that uses cryptography to | computer program (and related protocols) that uses cryptography to | |||
| provide data security for electronic mail and other applications | provide data security for electronic mail and other applications | |||
| on the Internet. (Compare: MOSS, MSP, PEM, S/MIME.) | on the Internet. (Compare: MOSS, MSP, PEM, S/MIME.) | |||
| Tutorial: PGP encrypts messages with IDEA in CFB mode, distributes | Tutorial: PGP encrypts messages with IDEA in CFB mode, distributes | |||
| the IDEA keys by encrypting them with RSA, and creates digital | the IDEA keys by encrypting them with RSA, and creates digital | |||
| signatures on messages with MD5 and RSA. To establish ownership of | signatures on messages with MD5 and RSA. To establish ownership of | |||
| public keys, PGP depends on the web of trust. | public keys, PGP depends on the web of trust. | |||
| $ prevention | ||||
| (I) See: secondary definition under "security". | ||||
| $ primary account number (PAN) | $ primary account number (PAN) | |||
| (O) /SET/ "The assigned number that identifies the card issuer and | (O) /SET/ "The assigned number that identifies the card issuer and | |||
| cardholder. This account number is composed of an issuer | cardholder. This account number is composed of an issuer | |||
| identification number, an individual account number | identification number, an individual account number | |||
| identification, and an accompanying check digit as defined by ISO | identification, and an accompanying check digit as defined by ISO | |||
| 7812-1985." [SET2, IS7812] (See: bank identification number.) | 7812-1985." [SET2, IS7812] (See: bank identification number.) | |||
| Tutorial: The PAN is embossed, encoded, or both on a magnetic- | Tutorial: The PAN is embossed, encoded, or both on a magnetic- | |||
| strip-based credit card. The PAN identifies the issuer to which a | strip-based credit card. The PAN identifies the issuer to which a | |||
| transaction is to be routed and the account to which it is to be | transaction is to be routed and the account to which it is to be | |||
| skipping to change at page 188, line 9 ¶ | skipping to change at page 200, line 4 ¶ | |||
| subjects, but each subject is associated with only one principal. | subjects, but each subject is associated with only one principal. | |||
| (Compare: role, subject, user.) | (Compare: role, subject, user.) | |||
| (N) /Kerberos/ A uniquely named client or server instance that | (N) /Kerberos/ A uniquely named client or server instance that | |||
| participates in a network communication. | participates in a network communication. | |||
| $ privacy | $ privacy | |||
| 1. (I) The right of an entity (normally a person), acting in its | 1. (I) The right of an entity (normally a person), acting in its | |||
| own behalf, to determine the degree to which it will interact with | own behalf, to determine the degree to which it will interact with | |||
| its environment, including the degree to which the entity is | its environment, including the degree to which the entity is | |||
| willing to share information about itself with others. (See: | willing to share its personal information with others. (See: | |||
| HIPAA, Privacy Act of 1974. Compare: anonymity, data | HIPAA, personal information, Privacy Act of 1974. Compare: | |||
| confidentiality.) | anonymity, data confidentiality.) | |||
| 2. (O) "The right of individuals to control or influence what | 2. (O) "The right of individuals to control or influence what | |||
| information related to them may be collected and stored and by | information related to them may be collected and stored and by | |||
| whom and to whom that information may be disclosed." [I7498 Part | whom and to whom that information may be disclosed." [I7498 Part | |||
| 2] | 2] | |||
| 3. (D) Synonym for "data confidentiality". | 3. (D) Synonym for "data confidentiality". | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "data confidentiality" or "data confidentiality service", | for "data confidentiality" or "data confidentiality service", | |||
| skipping to change at page 188, line 42 ¶ | skipping to change at page 200, line 37 ¶ | |||
| Code) that seeks to balance the U.S. Government's need to maintain | Code) that seeks to balance the U.S. Government's need to maintain | |||
| data about individuals with the rights of individuals to be | data about individuals with the rights of individuals to be | |||
| protected against unwarranted invasions of their privacy stemming | protected against unwarranted invasions of their privacy stemming | |||
| from federal agencies' collection, maintenance, use, and | from federal agencies' collection, maintenance, use, and | |||
| disclosure of personal data. (See: privacy.) | disclosure of personal data. (See: privacy.) | |||
| Tutorial: In 1974, the U.S. Congress was concerned with the | Tutorial: In 1974, the U.S. Congress was concerned with the | |||
| potential for abuses that could arise from the Government's | potential for abuses that could arise from the Government's | |||
| increasing use of computers to store and retrieve personal data. | increasing use of computers to store and retrieve personal data. | |||
| Therefore, the Act has four basic policy objectives: | Therefore, the Act has four basic policy objectives: | |||
| - To restrict disclosure of personally identifiable records | - To restrict disclosure of personally identifiable records | |||
| maintained by Federal agencies. | maintained by Federal agencies. | |||
| - To grant individuals increased rights of access to Federal | - To grant individuals increased rights of access to Federal | |||
| agency records maintained on themselves. | agency records maintained on themselves. | |||
| - To grant individuals the right to seek amendment of agency | - To grant individuals the right to seek amendment of agency | |||
| records maintained on themselves upon a showing that the | records maintained on themselves upon a showing that the | |||
| records are not accurate, relevant, timely, or complete. | records are not accurate, relevant, timely, or complete. | |||
| - To establish a code of "fair information practices" that | - To establish a code of "fair information practices" that | |||
| requires agencies to comply with statutory norms for | requires agencies to comply with statutory norms for | |||
| collection, maintenance, and dissemination of records. | collection, maintenance, and dissemination of records. | |||
| $ Privacy Enhanced Mail (PEM) | $ Privacy Enhanced Mail (PEM) | |||
| (I) An Internet protocol to provide data confidentiality, data | (I) An Internet protocol to provide data confidentiality, data | |||
| integrity, and data origin authentication for electronic mail. | integrity, and data origin authentication for electronic mail. | |||
| [R1421, R1422]. (Compare: MOSS, MSP, PGP, S/MIME.) | [R1421, R1422]. (Compare: MOSS, MSP, PGP, S/MIME.) | |||
| Tutorial: PEM encrypts messages with DES in CBC mode, provides key | ||||
| distribution of DES keys by encrypting them with RSA, and signs | Tutorial: PEM encrypts messages with DES in CBC mode, provides | |||
| distribution for DES keys by encrypting them with RSA, and signs | ||||
| messages with RSA over either MD2 or MD5. To establish ownership | messages with RSA over either MD2 or MD5. To establish ownership | |||
| of public keys, PEM uses a certification hierarchy, with X.509 | of public keys, PEM uses a certification hierarchy, with X.509 | |||
| public-key certificates and X.509 CRLs that are signed with RSA | public-key certificates and X.509 CRLs that are signed with RSA | |||
| and MD2. | and MD2. | |||
| PEM is designed to be compatible with a wide range of key | PEM is designed to be compatible with a wide range of key | |||
| management methods, but is limited to specifying security services | management methods, but is limited to specifying security services | |||
| only for text messages and, like MOSS, has not been widely | only for text messages and, like MOSS, has not been widely | |||
| implemented in the Internet. | implemented in the Internet. | |||
| $ private component | $ private component | |||
| (I) Synonym for "private key". | (I) Synonym for "private key". | |||
| Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; | Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; | |||
| instead, to avoid confusing readers, use "private key". However, | instead, to avoid confusing readers, use "private key". However, | |||
| the term MAY be used when discussing a key pair; e.g., "A key pair | the term MAY be used when discussing a key pair; e.g., "A key pair | |||
| has a public component and a private component." | has a public component and a private component." | |||
| $ private extension | $ private extension | |||
| (I) See: (secondary definition under) extension. | (I) See: secondary definition under "extension". | |||
| $ private key | $ private key | |||
| 1. (I) The secret component of a pair of cryptographic keys used | 1. (I) The secret component of a pair of cryptographic keys used | |||
| for asymmetric cryptography. (See: key pair, public key.) | for asymmetric cryptography. (See: key pair, public key, secret | |||
| key.) | ||||
| 2. (O) In a public key cryptosystem, "that key of a user's key | 2. (O) In a public key cryptosystem, "that key of a user's key | |||
| pair which is known only by that user." [X509] | pair which is known only by that user." [X509] | |||
| $ Private Line Interface (PLI) | $ Private Line Interface (PLI) | |||
| (I) The first end-to-end packet encryption system for a computer | (I) The first end-to-end packet encryption system for a computer | |||
| network, developed by BBN starting in 1975 for the U.S. DoD, | network, developed by BBN starting in 1975 for the U.S. DoD, | |||
| incorporating Government-furnished, military-grade COMSEC | incorporating Government-furnished, military-grade COMSEC | |||
| equipment (TSEC/KG-34). [B1822] (Compare: IPLI.) | equipment (TSEC/KG-34). [B1822] (Compare: IPLI.) | |||
| $ privilege | $ privilege | |||
| 1a. (I) A synonym for "authorization". (Compare: permission.) | 1a. (I) /access control/ A synonym for "authorization". (See | |||
| authorization. Compare: permission.) | ||||
| 1b. (I) An authorization or set of authorizations to perform | ||||
| security-relevant functions in the context of computer operating | ||||
| systems. | ||||
| Tutorial: A privilege can be modeled as (a) an action acting upon | 1b. (I) /computer platform/ An authorization to perform a | |||
| (b) an object that contains (c) attributes that can be constrained | security-relevant function in the context of a computer's | |||
| by (d) domains. | operating system. | |||
| $ privilege management infrastructure | $ privilege management infrastructure | |||
| (O) "The infrastructure able to support the management of | (O) "The infrastructure able to support the management of | |||
| privileges in support of a comprehensive authorization service and | privileges in support of a comprehensive authorization service and | |||
| in relationship with a" PKI; i.e., processes concerned with | in relationship with a" PKI; i.e., processes concerned with | |||
| attribute certificates. [X509] | attribute certificates. [X509] | |||
| Deprecated Usage: ISDs SHOULD NOT use this term; this definition | Deprecated Usage: ISDs SHOULD NOT use this term with this | |||
| is vague and there is no consensus on a more specific definition. | definition. This definition is vague, and there is no consensus on | |||
| a more specific one. | ||||
| $ privileged process | $ privileged process | |||
| (I) An computer process that is authorized (and, therefore, | (I) An computer process that is authorized (and, therefore, | |||
| trusted) to perform some security-relevant functions that ordinary | trusted) to perform some security-relevant functions that ordinary | |||
| processes are not. (See: privilege, trusted process.) | processes are not. (See: privilege, trusted process.) | |||
| $ privileged user | ||||
| (I) An user that has access to system control, monitoring, or | ||||
| administration functions. (See: privilege, /UNIX/ under "root", | ||||
| superuser, user.) | ||||
| Tutorial: Privileged users include the following types: | ||||
| - Users with near or complete control of a system, who are | ||||
| authorized to set up and administer user accounts, identifiers, | ||||
| and authentication information, or are authorized to assign or | ||||
| change other users' access to system resources. | ||||
| - Users that are authorized to change control parameters (e.g., | ||||
| network addresses, routing tables, processing priorities) on | ||||
| routers, multiplexers, and other important equipment. | ||||
| - Users that are authorized to monitor or perform troubleshooting | ||||
| for a system's security functions, typically using special | ||||
| tools and features that are not available to ordinary users. | ||||
| $ probe | $ probe | |||
| (I) /verb/ To access an information system in an attempt to gather | (I) /verb/ To access an information system in an attempt to gather | |||
| information about the system for the purpose of circumventing the | information about the system for the purpose of circumventing the | |||
| system's security measures. | system's security measures. | |||
| $ procedural security | $ procedural security | |||
| (I) Synonym for "administrative security". | (D) Synonym for "administrative security". | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | |||
| for "administrative security". Any type of security may involve | "administrative security". The term may be misleading because any | |||
| procedures; therefore, the term may be misleading. Instead, use | type of security may involve procedures, and procedures may be | |||
| either external to the system or internal. Instead, use | ||||
| "administrative security", "communication security", "computer | "administrative security", "communication security", "computer | |||
| security", "emanations security", "personnel security", "physical | security", "emanations security", "personnel security", "physical | |||
| security", or whatever specific type is meant. (See: security | security", or whatever specific type is meant. (See: security | |||
| architecture.) | architecture.) | |||
| $ profile | $ profile | |||
| See: certificate profile, protection profile. | See: certificate profile, protection profile. | |||
| $ proof-of-possession protocol | $ proof-of-possession protocol | |||
| (I) A protocol whereby a system entity proves to another that it | (I) A protocol whereby a system entity proves to another that it | |||
| skipping to change at page 190, line 47 ¶ | skipping to change at page 203, line 9 ¶ | |||
| $ proprietary | $ proprietary | |||
| (I) Refers to information (or other property) that is owned by an | (I) Refers to information (or other property) that is owned by an | |||
| individual or organization and for which the use is restricted by | individual or organization and for which the use is restricted by | |||
| that entity. | that entity. | |||
| $ protected checksum | $ protected checksum | |||
| (I) A checksum that is computed for a data object by means that | (I) A checksum that is computed for a data object by means that | |||
| protect against active attacks that would attempt to change the | protect against active attacks that would attempt to change the | |||
| checksum to make it match changes made to the data object. (See: | checksum to make it match changes made to the data object. (See: | |||
| digital signature, keyed hash, (discussion under) checksum. | digital signature, keyed hash, Tutorial under "checksum".) | |||
| $ protective packaging | $ protective packaging | |||
| (N) Packaging techniques for COMSEC material that discourage | (N) Packaging techniques for COMSEC material that discourage | |||
| penetration, reveal a penetration has occurred or was attempted, | penetration, reveal a penetration has occurred or was attempted, | |||
| or inhibit viewing or copying of keying material prior to the time | or inhibit viewing or copying of keying material prior to the time | |||
| it is exposed for use. [C4008] (Compare: QUADRANT. See: tamper | it is exposed for use. [C4008] (See: tamper-evident, tamper- | |||
| evident, tamper resistant.) | resistant. Compare: QUADRANT.) | |||
| $ protection authority | $ protection authority | |||
| (I) See: (secondary definition under) Internet Protocol Security | (I) See: secondary definition under "Internet Protocol Security | |||
| Option. | Option". | |||
| $ protection level | ||||
| (N) /U.S. Government/ An indication of the trust that is needed in | ||||
| a system's technical ability to enforce security policy for | ||||
| confidentiality. (Compare: /system operation/ under "mode of | ||||
| operation".) | ||||
| Tutorial: An organization's security policy could define | ||||
| protection levels that are based on (a) the sensitivity of | ||||
| information handled by a system compared to (b) the authorizations | ||||
| of users that receive information from the system without manual | ||||
| intervention and reliable human review. For each level, the policy | ||||
| could specify security features and assurances that must be | ||||
| included in any system that was intended to operate at that level. | ||||
| Example: Given some set of data objects that are classified at one | ||||
| or more hierarchical levels and in one or more non-hierarchical | ||||
| categories, the following table defines five protection levels for | ||||
| systems that would handle that data. Beginning with PL1 and | ||||
| evolving to PL5, each successive level would require stronger | ||||
| features and assurances to handle the dataset. (See: clearance, | ||||
| formal access approval, and need-to-know.) | ||||
| Lowest Clearance Formal Access Need-To-Know | ||||
| Among All Users Approval of Users of Users | ||||
| +-------------------+-------------------+-------------------+ | ||||
| PL5 | Some user has no | [Does not matter.]| [Does not matter.]| | ||||
| High | clearance at all. | | | | ||||
| +-------------------+-------------------+-------------------+ | ||||
| PL4 | All are cleared | [Does not matter.]| [Does not matter.]| | ||||
| | for some data. | | | | ||||
| +-------------------+-------------------+-------------------+ | ||||
| PL3 | All are cleared | Some not approved | [Does not matter.]| | ||||
| | for all data. | for all data. | | | ||||
| +-------------------+-------------------+-------------------+ | ||||
| PL2 | All are cleared | All are approved | Some don't need to| | ||||
| | for all data. | for all data. | to know all data. | | ||||
| +-------------------+-------------------+-------------------+ | ||||
| PL1 | All are cleared | All are approved | All have a need | | ||||
| Low | for all data. | for all data. | to know all data.| | ||||
| +-------------------+-------------------+-------------------+ | ||||
| Each of these protection levels can be viewed as being equivalent | ||||
| to one or more modes of system operation defined in this Glossary: | ||||
| - PL5 is equivalent to multilevel security mode. | ||||
| - PL4 is equivalent to either multilevel or compartmented | ||||
| security mode, depending on the details of users' clearances. | ||||
| - PL3 is equivalent to partitioned security mode. | ||||
| - PL2 is equivalent to system-high security mode. | ||||
| - PL1 is equivalent to dedicated security mode. | ||||
| $ protection profile | $ protection profile | |||
| (N) /Common Criteria/ An implementation-independent set of | (N) /Common Criteria/ An implementation-independent set of | |||
| security requirements for a category of targets of evaluation that | security requirements for a category of targets of evaluation that | |||
| meet specific consumer needs. [CCIB] Example: [IDSAN]. | meet specific consumer needs. [CCIB] Example: [IDSAN]. (See: | |||
| target of evaluation. Compare: package.) | ||||
| Tutorial: A protection profile (PP) is intended to be a reusable | Tutorial: A protection profile (PP) is the kind of document used | |||
| statement of product security needs, which are known to be useful | by consumers to specify functional requirements they want in a | |||
| and effective, for a set of information technology security | product, and a target of evaluation (TOE) is the kind of document | |||
| products that could be built. A PP contains a set of security | used by vendors to make functional claims about a product. | |||
| requirements, preferably taken from the catalogs in Parts 2 and 3 | ||||
| of the Common Criteria, and should include an EAL. A PP could be | A PP is intended to be a reusable statement of product security | |||
| developed by user communities, product developers, or any other | needs, which are known to be useful and effective, for a set of | |||
| parties interested in defining a common set of requirements. | information technology security products that could be built. A PP | |||
| contains a set of security requirements, preferably taken from the | ||||
| catalogs in Parts 2 and 3 of the Common Criteria, and should | ||||
| include an EAL. A PP could be developed by user communities, | ||||
| product developers, or any other parties interested in defining a | ||||
| common set of requirements. | ||||
| $ protection ring | $ protection ring | |||
| (I) One of a hierarchy of privileged operation modes of a system | (I) One of a hierarchy of privileged operation modes of a system | |||
| that gives certain access rights to processes authorized to | that gives certain access rights to processes authorized to | |||
| operate in that mode. (See: Multics.) | operate in that mode. (See: Multics.) | |||
| $ protective distribution system (PDS) | $ protective distribution system (PDS) | |||
| (N) A wireline or fiber-optic communication system used to | (N) A wireline or fiber-optic communication system used to | |||
| transmit cleartext classified information through an area of | transmit cleartext classified information through an area of | |||
| lesser classification or control. [N7003] | lesser classification or control. [N7003] | |||
| $ protocol | $ protocol | |||
| 1a. (I) A set of rules (i.e., formats and procedures) to implement | 1a. (I) A set of rules (i.e., formats and procedures) to implement | |||
| and control some type of association (e.g., communication) between | and control some type of association (e.g., communication) between | |||
| systems. Example: Internet Protocol. | systems. Example: Internet Protocol. | |||
| 1b. (I) A series of ordered computing and communication steps that | 1b. (I) A series of ordered computing and communication steps that | |||
| are performed by two or more system entities to achieve a joint | are performed by two or more system entities to achieve a joint | |||
| objective. [A9042] | objective. [A9042] | |||
| $ protocol control information (PCI) | ||||
| (N) See: secondary definition under "protocol data unit". | ||||
| $ protocol data unit (PDU) | ||||
| (N) A data packet that is defined for peer-to-peer transfers in a | ||||
| protocol layer. | ||||
| Tutorial: A PDU consists of two disjoint subsets of data: the SDU | ||||
| and the PCI. (Although these terms -- PDU, SDU, and PCI -- | ||||
| originated in the OSIRM, they are also useful and permissible in | ||||
| an IPS context.) | ||||
| - The "service data unit" (SDU) in a packet is data that the | ||||
| protocol transfers between peer protocol entities on behalf of | ||||
| the users of that layer's services. For Layers 1 through 6, the | ||||
| layer's users are peer protocol entities at a higher layer; for | ||||
| Layer 7, the users are application entities outside the scope | ||||
| of the OSIRM. | ||||
| - The "protocol control information" (PCI) in a packet is data | ||||
| that peer protocol entities exchange between themselves to | ||||
| control their joint operation of the layer. | ||||
| $ protocol suite | $ protocol suite | |||
| (I) A complementary collection of communication protocols used in | (I) A complementary collection of communication protocols used in | |||
| a computer network. (See: Internet, OSI.) | a computer network. (See: IPS, OSI.) | |||
| $ proxy | $ proxy | |||
| 1. (I) A computer process that acts on behalf of a user or client. | 1. (I) A computer process that acts on behalf of a user or client. | |||
| 2. (I) A computer process -- often used as, or as part of, a | 2. (I) A computer process -- often used as, or as part of, a | |||
| firewall -- that relays a protocol between client and server | firewall -- that relays a protocol between client and server | |||
| computer systems, by appearing to the client to be the server and | computer systems, by appearing to the client to be the server and | |||
| appearing to the server to be the client. (See: SOCKS.) | appearing to the server to be the client. (See: SOCKS.) | |||
| Tutorial: In a firewall, a proxy server usually runs on a bastion | Tutorial: In a firewall, a proxy server usually runs on a bastion | |||
| skipping to change at page 192, line 18 ¶ | skipping to change at page 206, line 17 ¶ | |||
| firewall, gets the response, then sends the response back to the | firewall, gets the response, then sends the response back to the | |||
| client. The proxy may be transparent to the clients, or they may | client. The proxy may be transparent to the clients, or they may | |||
| need to connect first to the proxy server, and then use that | need to connect first to the proxy server, and then use that | |||
| association to also initiate a connection to the real server. | association to also initiate a connection to the real server. | |||
| Proxies are generally preferred over SOCKS for their ability to | Proxies are generally preferred over SOCKS for their ability to | |||
| perform caching, high-level logging, and access control. A proxy | perform caching, high-level logging, and access control. A proxy | |||
| can provide security service beyond that which is normally part of | can provide security service beyond that which is normally part of | |||
| the relayed protocol, such as access control based on peer entity | the relayed protocol, such as access control based on peer entity | |||
| authentication of clients, or peer entity authentication of | authentication of clients, or peer entity authentication of | |||
| servers when clients do not have that capability. A proxy at OSIRM | servers when clients do not have that ability. A proxy at OSIRM | |||
| layer 7 can also provide finer-grained security service than can a | Layer 7 can also provide finer-grained security service than can a | |||
| filtering router at layer 3. For example, an FTP proxy could | filtering router at Layer 3. For example, an FTP proxy could | |||
| permit transfers out of, but not into, a protected network. | permit transfers out of, but not into, a protected network. | |||
| $ proxy certificate | $ proxy certificate | |||
| (I) An X.509 public-key certificate derived from a end-entity | (I) An X.509 public-key certificate derived from a end-entity | |||
| certificate, or from another proxy certificate, for the purpose of | certificate, or from another proxy certificate, for the purpose of | |||
| establishing proxies and delegating authorizations in the context | establishing proxies and delegating authorizations in the context | |||
| of a PKI-based authentication system. [R3280] | of a PKI-based authentication system. [R3280] | |||
| Tutorial: A proxy certificate has the following properties: | Tutorial: A proxy certificate has the following properties: | |||
| - It contains an critical extension that (a) identifies it as a | - It contains an critical extension that (a) identifies it as a | |||
| proxy certificate and (b) may contain a certification path | proxy certificate and (b) may contain a certification path | |||
| length constraint and policy constraints. | length constraint and policy constraints. | |||
| - It contains the public component of a key pair that is distinct | - It contains the public component of a key pair that is distinct | |||
| from that associated with any other certificate. | from that associated with any other certificate. | |||
| - It is signed by the private component of a key pair that is | - It is signed by the private component of a key pair that is | |||
| associated with an end-entity certificate or another proxy | associated with an end-entity certificate or another proxy | |||
| certificate. | certificate. | |||
| - Its associated private key can be used to sign only other proxy | - Its associated private key can be used to sign only other proxy | |||
| certificates (not end-entity certificates). | certificates (not end-entity certificates). | |||
| - Its "subject" DN is derived from its "issuer" DN and is unique. | - Its "subject" DN is derived from its "issuer" DN and is unique. | |||
| - Its "issuer" DN is the "subject" DN of an end-entity | - Its "issuer" DN is the "subject" DN of an end-entity | |||
| certificate or another proxy certificate. | certificate or another proxy certificate. | |||
| $ pseudorandom | $ pseudorandom | |||
| (I) A sequence of values that appears to be random (i.e., | (I) A sequence of values that appears to be random (i.e., | |||
| unpredictable) but is actually generated by a deterministic | unpredictable) but is actually generated by a deterministic | |||
| algorithm. (See: compression, random, random number generator.) | algorithm. (See: compression, random, random number generator.) | |||
| $ pseudorandom number generator | $ pseudorandom number generator | |||
| See: random number generator. | (I) See: secondary definition under "random number generator". | |||
| $ public component | $ public component | |||
| (I) Synonym for "public key". | (I) Synonym for "public key". | |||
| Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; to | Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; to | |||
| avoid confusing readers, use "private key" instead. However, the | avoid confusing readers, use "private key" instead. However, the | |||
| term MAY be used when discussing a key pair; e.g., "A key pair has | term MAY be used when discussing a key pair; e.g., "A key pair has | |||
| a public component and a private component." | a public component and a private component." | |||
| $ public key | $ public key | |||
| 1. (I) The publicly-disclosable component of a pair of | 1. (I) The publicly disclosable component of a pair of | |||
| cryptographic keys used for asymmetric cryptography. (See: key | cryptographic keys used for asymmetric cryptography. (See: key | |||
| pair, private key.) | pair. Compare: private key.) | |||
| 2. (O) In a public key cryptosystem, "that key of a user's key | 2. (O) In a public key cryptosystem, "that key of a user's key | |||
| pair which is publicly known." [X509] | pair which is publicly known." [X509] | |||
| $ public-key certificate | $ public-key certificate | |||
| 1. (I) A digital certificate that binds a system entity's identity | 1. (I) A digital certificate that binds a system entity's | |||
| to a public key value, and possibly to additional, secondary data | identifier to a public key value, and possibly to additional, | |||
| items; i.e., a digitally-signed data structure that attests to the | secondary data items; i.e., a digitally signed data structure that | |||
| ownership of a public key. (See: X.509 public-key certificate.) | attests to the ownership of a public key. (See: X.509 public-key | |||
| certificate.) | ||||
| 2. (O) "The public key of a user, together with some other | 2. (O) "The public key of a user, together with some other | |||
| information, rendered unforgeable by encipherment with the private | information, rendered unforgeable by encipherment with the private | |||
| key of the certification authority which issued it." [X509] | key of the certification authority which issued it." [X509] | |||
| Tutorial: The digital signature on a public-key certificate is | Tutorial: The digital signature on a public-key certificate is | |||
| unforgeable. Thus, the certificate can be published, such as by | unforgeable. Thus, the certificate can be published, such as by | |||
| posting it in a directory, without the directory having to protect | posting it in a directory, without the directory having to protect | |||
| the certificate's data integrity. | the certificate's data integrity. | |||
| $ public-key cryptography | $ public-key cryptography | |||
| (I) The popular synonym for "asymmetric cryptography". | (I) Synonym for "asymmetric cryptography". | |||
| $ Public-Key Cryptography Standards (PKCS) | $ Public-Key Cryptography Standards (PKCS) | |||
| (N) A series of specifications published by RSA Laboratories for | (N) A series of specifications published by RSA Laboratories for | |||
| data structures and algorithm used in basic applications of | data structures and algorithms used in basic applications of | |||
| asymmetric cryptography. (See: PKCS #5 through PKCS #11.) | asymmetric cryptography. (See: PKCS #5 through PKCS #11.) | |||
| Tutorial: The PKCS were begun in 1991 in cooperation with industry | Tutorial: The PKCS were begun in 1991 in cooperation with industry | |||
| and academia, originally including Apple, Digital, Lotus, | and academia, originally including Apple, Digital, Lotus, | |||
| Microsoft, Northern Telecom, Sun, and MIT. Today, the | Microsoft, Northern Telecom, Sun, and MIT. Today, the | |||
| specifications are widely used, but they are not sanctioned by an | specifications are widely used, but they are not sanctioned by an | |||
| official standards organization, such as ANSI, ITU-T, or IETF. RSA | official standards organization, such as ANSI, ITU-T, or IETF. RSA | |||
| Laboratories retains sole decision-making authority over the PKCS. | Laboratories retains sole decision-making authority over the PKCS. | |||
| $ public-key forward secrecy (PFS) | $ public-key forward secrecy (PFS) | |||
| (I) For a key agreement protocol based on asymmetric cryptography, | (I) For a key-agreement protocol based on asymmetric cryptography, | |||
| the property that ensures that a session key derived from a set of | the property that ensures that a session key derived from a set of | |||
| long-term public and private keys will not be compromised if one | long-term public and private keys will not be compromised if one | |||
| of the private keys is compromised in the future. | of the private keys is compromised in the future. | |||
| Usage: Some existing RFCs use the term "perfect forward secrecy" | Usage: Some existing RFCs use the term "perfect forward secrecy" | |||
| but either do not define it or do not define it precisely. While | but either do not define it or do not define it precisely. While | |||
| preparing this Glossary, we tried to find a good definition for | preparing this Glossary, we tried to find a good definition for | |||
| that term, but found this to be a muddled area. Experts did not | that term, but found this to be a muddled area. Experts did not | |||
| agree. For all practical purposes, the literature defines "perfect | agree. For all practical purposes, the literature defines "perfect | |||
| forward secrecy" by stating the Diffie-Hellman algorithm. The term | forward secrecy" by stating the Diffie-Hellman algorithm. The term | |||
| "public-key forward secrecy" (suggested by Hilarie Orman) and the | "public-key forward secrecy" (suggested by Hilarie Orman) and the | |||
| "I" definition stated for it here were crafted to be compatible | "I" definition stated for it here were crafted to be compatible | |||
| with current Internet documents, yet be narrow and leave room for | with current Internet documents, yet be narrow and leave room for | |||
| improved terminology. | improved terminology. | |||
| Challenge to the Internet security community: We need a taxonomy | Challenge to the Internet security community: We need a taxonomy | |||
| -- a family of mutually exclusive and collectively exhaustive | of terms and definitions to cover the basic properties discussed | |||
| terms and definitions to cover the basic properties discussed here | here for the full range of cryptographic algorithms and protocols | |||
| -- for the full range of cryptographic algorithms and protocols | ||||
| used in Internet Standards: | used in Internet Standards: | |||
| Involvement of session keys vs. long-term keys: Experts disagree | Involvement of session keys vs. long-term keys: Experts disagree | |||
| about the basic ideas involved: | about the basic ideas involved: | |||
| - One concept of "forward secrecy" is that, given observations of | - One concept of "forward secrecy" is that, given observations of | |||
| the operation of a key establishment protocol up to time t, and | the operation of a key establishment protocol up to time t, and | |||
| given some of the session keys derived from those protocol | given some of the session keys derived from those protocol | |||
| runs, you cannot derive unknown past session keys or future | runs, you cannot derive unknown past session keys or future | |||
| session keys. | session keys. | |||
| - A related property is that, given observations of the protocol | - A related property is that, given observations of the protocol | |||
| and knowledge of the derived session keys, you cannot derive | and knowledge of the derived session keys, you cannot derive | |||
| one or more of the long-term private keys. | one or more of the long-term private keys. | |||
| - The "I" definition presented above involves a third concept of | - The "I" definition presented above involves a third concept of | |||
| "forward secrecy" that refers to the effect of the compromise | "forward secrecy" that refers to the effect of the compromise | |||
| of long-term keys. | of long-term keys. | |||
| - All three concepts involve the idea that a compromise of "this" | - All three concepts involve the idea that a compromise of "this" | |||
| encryption key is not supposed to compromise the "next" one. | encryption key is not supposed to compromise the "next" one. | |||
| There also is the idea that compromise of a single key will | There also is the idea that compromise of a single key will | |||
| compromise only the data protected by the single key. In | compromise only the data protected by the single key. In | |||
| Internet literature, the focus has been on protection against | Internet literature, the focus has been on protection against | |||
| decryption of back traffic in the event of a compromise of | decryption of back traffic in the event of a compromise of | |||
| secret key material held by one or both parties to a | secret key material held by one or both parties to a | |||
| communication. | communication. | |||
| Forward vs. backward: Experts are unhappy with the word "forward", | Forward vs. backward: Experts are unhappy with the word "forward", | |||
| because compromise of "this" encryption key also is not supposed | because compromise of "this" encryption key also is not supposed | |||
| skipping to change at page 195, line 49 ¶ | skipping to change at page 209, line 49 ¶ | |||
| approve or coordinate CPSs, which are security policies under | approve or coordinate CPSs, which are security policies under | |||
| which components of a PKI operate. | which components of a PKI operate. | |||
| A number of other servers and agents may support the core PKI, and | A number of other servers and agents may support the core PKI, and | |||
| PKI clients may obtain services from them. The full range of such | PKI clients may obtain services from them. The full range of such | |||
| services is not yet fully understood and is evolving, but | services is not yet fully understood and is evolving, but | |||
| supporting roles may include archive agent, certified delivery | supporting roles may include archive agent, certified delivery | |||
| agent, confirmation agent, digital notary, directory, key escrow | agent, confirmation agent, digital notary, directory, key escrow | |||
| agent, key generation agent, naming agent who ensures that issuers | agent, key generation agent, naming agent who ensures that issuers | |||
| and subjects have unique identifiers within the PKI, repository, | and subjects have unique identifiers within the PKI, repository, | |||
| ticket-granting agent, and time stamp agent. | ticket-granting agent, and time-stamp agent. | |||
| $ purge | $ purge | |||
| (I) Use degaussing or other means to render (magnetically) stored | (I) Use degaussing or other means to render (magnetically) stored | |||
| data unusable and unrecoverable by any means, including laboratory | data unusable and unrecoverable by any means, including laboratory | |||
| methods. [C4009] (See: zeroize. Compare: erase, sanitize.) | methods. [C4009] (See: zeroize. Compare: erase, sanitize.) | |||
| $ QUADRANT | $ QUADRANT | |||
| (O) /U.S. Government/ Short name for technology and methods that | (O) /U.S. Government/ Short name for technology and methods that | |||
| protect cryptographic equipment by making the equipment tamper- | protect cryptographic equipment by making the equipment tamper- | |||
| resistant. [C4009] (Compare: protective packaging, TEMPEST.) | resistant. [C4009] (Compare: protective packaging, TEMPEST.) | |||
| skipping to change at page 196, line 20 ¶ | skipping to change at page 210, line 20 ¶ | |||
| Tutorial: Equipment cannot be made completely tamper-proof, but it | Tutorial: Equipment cannot be made completely tamper-proof, but it | |||
| can be made tamper-resistant or tamper-evident. | can be made tamper-resistant or tamper-evident. | |||
| $ qualified certificate | $ qualified certificate | |||
| (I) A public-key certificate that has the primary purpose of | (I) A public-key certificate that has the primary purpose of | |||
| identifying a person with a high level of assurance, where the | identifying a person with a high level of assurance, where the | |||
| certificate meets some qualification requirements defined by an | certificate meets some qualification requirements defined by an | |||
| applicable legal framework, such as the European Directive on | applicable legal framework, such as the European Directive on | |||
| Electronic Signature [EU-ESDIR]. [R3739]. | Electronic Signature [EU-ESDIR]. [R3739]. | |||
| $ quick mode | ||||
| (I) See: /IKE/ under "mode". | ||||
| $ RA | $ RA | |||
| (I) See: registration authority. | (I) See: registration authority. | |||
| $ RA domains | $ RA domains | |||
| (I) A capability of a CAW that allows a CA to divide the | (I) A feature of a CAW that allows a CA to divide the | |||
| responsibility for certificate requests among multiple RAs. | responsibility for certificate requests among multiple RAs. | |||
| Tutorial: This capability might be used to restrict access to | Tutorial: This ability might be used to restrict access to private | |||
| private authorization data that is provided with a certificate | authorization data that is provided with a certificate request, | |||
| request, and to distribute the responsibility to review and | and to distribute the responsibility to review and approve | |||
| approve certificate requests in high volume environments. RA | certificate requests in high volume environments. RA domains might | |||
| domains might segregate certificate requests according to an | segregate certificate requests according to an attribute of the | |||
| attribute of the certificate subject, such as an organizational | certificate subject, such as an organizational unit. | |||
| unit. | ||||
| $ RADIUS | $ RADIUS | |||
| (I) See: Remote Authentication Dial-In User Service. | (I) See: Remote Authentication Dial-In User Service. | |||
| $ Rainbow Series | $ Rainbow Series | |||
| (O) A set of more than 30 technical and policy documents with | (O) /COMPUSEC/ A set of more than 30 technical and policy | |||
| colored covers, issued by the NCSC, that discuss in detail the | documents with colored covers, issued by the NCSC, that discuss in | |||
| TCSEC and provide guidance for meeting and applying the criteria. | detail the TCSEC and provide guidance for meeting and applying the | |||
| (See: Green Book, Orange Book, Red Book, Yellow Book.) | criteria. (See: Green Book, Orange Book, Red Book, Yellow Book.) | |||
| $ random | $ random | |||
| (I) In essence, "random" means "unpredictable". [SP22, Knut, | (I) In essence, "random" means "unpredictable". [SP22, Knut, | |||
| R1750] (See: cryptographic key, pseudorandom.) | R1750] (See: cryptographic key, pseudorandom.) | |||
| - "Random sequence": A sequence in which each successive value is | - "Random sequence": A sequence in which each successive value is | |||
| obtained merely by chance and does not depend on the preceding | obtained merely by chance and does not depend on the preceding | |||
| values of the sequence. In a random sequence of bits, each bit | values of the sequence. In a random sequence of bits, each bit | |||
| is unpredictable; i.e., (a) the probability of each bit being a | is unpredictable; i.e., (a) the probability of each bit being a | |||
| "0" or "1" is 1/2, and (b) the value of each bit is independent | "0" or "1" is 1/2, and (b) the value of each bit is independent | |||
| of any other bit in the sequence. | of any other bit in the sequence. | |||
| - "Random value": A individual value that is unpredictable; i.e., | - "Random value": A individual value that is unpredictable; i.e., | |||
| each value in the total population of possibilities has equal | each value in the total population of possibilities has equal | |||
| probability of being selected. | probability of being selected. | |||
| $ random number generator | $ random number generator | |||
| (I) A process that is invoked to generate a random sequence of | (I) A process that is invoked to generate a random sequence of | |||
| values (usually a sequence of bits) or an individual random value. | values (usually a sequence of bits) or an individual random value. | |||
| Tutorial: There are two basic types of generators. [SP22] | Tutorial: There are two basic types of generators. [SP22] | |||
| - (True) random number generator: Uses one or more non- | - "(True) random number generator": It uses one or more non- | |||
| deterministic bit sources (usually physical phenomena; e.g., | deterministic bit sources (e.g., electrical circuit noise, | |||
| electrical circuit noise, timing of user processes such as key | timing of human processes such as key strokes or mouse | |||
| strokes or mouse movements, semiconductor quantum effects) and | movements, semiconductor quantum effects, and other physical | |||
| some processing function that formats the bits; and outputs an | phenomena) and a processing function that formats the bits, and | |||
| sequence of values that is unpredictable and uniformly | it outputs a sequence of values that is unpredictable and | |||
| distributed. | uniformly distributed. | |||
| - Pseudorandom number generator: Uses a deterministic | - "Pseudorandom number generator": It uses a deterministic | |||
| computational process (usually implemented by software) that | computational process (usually implemented by software) that | |||
| has one or more inputs called "seeds"; and outputs a sequence | has one or more inputs called "seeds", and it outputs a | |||
| of values that appears to be random according to specified | sequence of values that appears to be random according to | |||
| statistical tests. | specified statistical tests. | |||
| $ RBAC | $ RBAC | |||
| (N) See: role-based access control, rule-based access control. | (N) See: role-based access control, rule-based access control. | |||
| Deprecated Usage: This abbreviation is ambiguous; therefore, ISDs | Deprecated Usage: ISDs that use this term SHOULD state a | |||
| that use it SHOULD state a definition for it. | definition for it because the abbreviation is ambiguous. | |||
| $ RC2, RC4, RC6 | $ RC2, RC4, RC6 | |||
| (N) See: Rivest Cipher #2, #4, #6. | (N) See: Rivest Cipher #2, #4, #6. | |||
| $ read | $ read | |||
| (I) A fundamental operation in an information system that results | (I) A fundamental operation in an information system that results | |||
| only in the flow of information from an object to a subject. (See: | only in the flow of information from an object to a subject. (See: | |||
| access mode.) | access mode.) | |||
| $ realm | $ realm | |||
| (O) /Kerberos/ The domain of authority of a Kerberos server | (O) /Kerberos/ The domain of authority of a Kerberos server | |||
| (consisting of an authentication server and a ticket-granting | (consisting of an authentication server and a ticket-granting | |||
| server), including the Kerberized clients and the Kerberized | server), including the Kerberized clients and the Kerberized | |||
| application servers | application servers. (See: domain.) | |||
| $ recovery | $ recovery | |||
| 1. (I) /cryptography/ The process of learning or obtaining | 1. (I) /cryptography/ The process of learning or obtaining | |||
| cryptographic data or plain text through cryptanalysis. (See: key | cryptographic data or plain text through cryptanalysis. (See: key | |||
| recovery, data recovery.) | recovery, data recovery.) | |||
| 2a. (I) /system integrity/ The process of restoring a secure state | 2a. (I) /system integrity/ The process of restoring a secure state | |||
| in a system after there has been an accidental failure or a | in a system after there has been an accidental failure or a | |||
| successful attack. (See: system integrity.) | successful attack. (See: secondary definition under "security", | |||
| system integrity.) | ||||
| 2b. (I) /system integrity/ The process of restoring an information | 2b. (I) /system integrity/ The process of restoring an information | |||
| system's assets and operation following damage or destruction. | system's assets and operation following damage or destruction. | |||
| (See: contingency plan.) | (See: contingency plan.) | |||
| $ RED | $ RED | |||
| 1. (I) Designation for data that consists only of clear text, and | 1. (I) Designation for data that consists only of clear text, and | |||
| for information system equipment items and facilities that handle | for information system equipment items and facilities that handle | |||
| only clear text. Example: "RED key". (Compare: BLACK. See: color | only clear text. Example: "RED key". (See: color change, RED/BLACK | |||
| change, RED/BLACK separation.) | separation. Compare: BLACK.) | |||
| Derivation: From the practice of marking equipment with colors to | Derivation: From the practice of marking equipment with colors to | |||
| prevent operational errors. | prevent operational errors. | |||
| 2. (O) /U.S. Government/ Designation applied to information | 2. (O) /U.S. Government/ Designation applied to information | |||
| systems, and to associated areas, circuits, components, and | systems, and to associated areas, circuits, components, and | |||
| equipment, "in which unencrypted national security information is | equipment, "in which unencrypted national security information is | |||
| being processed." [C4009] | being processed." [C4009] | |||
| $ RED/BLACK separation | $ RED/BLACK separation | |||
| (I) An architectural concept for cryptographic systems that | (I) An architectural concept for cryptographic systems that | |||
| strictly separates the parts of a system that handle plain text | strictly separates the parts of a system that handle plain text | |||
| (i.e., RED information) from the parts that handle cipher text | (i.e., RED information) from the parts that handle cipher text | |||
| (i.e., BLACK information). (See: BLACK, RED.) | (i.e., BLACK information). (See: BLACK, RED.) | |||
| $ Red Book | $ Red Book | |||
| (D) Synonym for "Trusted Network Interpretation of the Trusted | (D) /slang/ Synonym for "Trusted Network Interpretation of the | |||
| Computer System Evaluation Criteria" [NCS05]. | Trusted Computer System Evaluation Criteria" [NCS05]. | |||
| Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | Deprecated Term: ISDs SHOULD NOT use this term. Instead, use the | |||
| "Trusted Network Interpretation of the Trusted Computer System | full proper name of the document or, in subsequent references, a | |||
| Evaluation Criteria". Instead, use the full proper name of the | more conventional abbreviation, e.g., TNI-TCSEC. (See: TCSEC, | |||
| document or, in subsequent references, a more conventional | Rainbow Series, Deprecated Usage under "Green Book".) | |||
| abbreviation. (See: TCSEC, Rainbow Series, (Deprecated Usage | ||||
| under) Green Book.) | ||||
| $ RED key | $ RED key | |||
| (I) A key that is usable in its present form without any | (I) A cleartext key, which is usable in its present form (i.e., it | |||
| additional decryption. (Compare: BLACK key. See: RED.) | does not need to be decrypted before being used). (See: RED. | |||
| Compare: BLACK key.) | ||||
| $ reference monitor | $ reference monitor | |||
| (I) "An access control concept that refers to an abstract machine | (I) "An access control concept that refers to an abstract machine | |||
| that mediates all accesses to objects by subjects." [NCS04] (See: | that mediates all accesses to objects by subjects." [NCS04] (See: | |||
| security kernel.) | security kernel.) | |||
| Tutorial: This concept was described in the Anderson report. A | Tutorial: This concept was described in the Anderson report. A | |||
| reference monitor should be (a) complete (i.e., it mediates every | reference monitor should be (a) complete (i.e., it mediates every | |||
| access), (b) isolated (i.e., it cannot be modified by other system | access), (b) isolated (i.e., it cannot be modified by other system | |||
| entities), and (c) verifiable (i.e., small enough to be subjected | entities), and (c) verifiable (i.e., small enough to be subjected | |||
| to analysis and tests to ensure that it is correct). | to analysis and tests to ensure that it is correct). | |||
| $ reflection attack | $ reflection attack | |||
| (I) An attack in which a valid data transmission is maliciously or | (I) An attack in which a valid data transmission is maliciously or | |||
| fraudulently retransmitted, either by an adversary who intercepts | fraudulently retransmitted, either by an adversary who intercepts | |||
| the data or by its originator. (Compare: replay attack.) | the data or by its originator. (Compare: replay attack.) | |||
| $ registered user | ||||
| (I) A system entity that is authorized to receive a system's | ||||
| products and services or otherwise access system resources. (See: | ||||
| registration, user.) | ||||
| $ registration | $ registration | |||
| 1. (I) A system process that (a) initializes an identity in the | 1. (I) /information system/ A system process that (a) initializes | |||
| system, (b) establishes an identifier for that identity, (c) may | an identity (of a system entity) in the system, (b) establishes an | |||
| associate authentication information with that identifier, and (d) | identifier for that identity, (c) may associate authentication | |||
| may issue an identifier credential (depending on the type of | information with that identifier, and (d) may issue an identifier | |||
| authentication mechanism being used). (See: authentication | credential (depending on the type of authentication mechanism | |||
| information, credential, identifier, identity.) | being used). (See: authentication information, credential, | |||
| identifier, identity, identity proofing.) | ||||
| 2. (I) /PKI/ An administrative act or process whereby an entity's | 2. (I) /PKI/ An administrative act or process whereby an entity's | |||
| name and other attributes are established for the first time at a | name and other attributes are established for the first time at a | |||
| CA, prior to the CA issuing a digital certificate that has the | CA, prior to the CA issuing a digital certificate that has the | |||
| entity's name as the subject. (See: registration authority.) | entity's name as the subject. (See: registration authority.) | |||
| Tutorial: Registration may be accomplished either directly, by the | Tutorial: Registration may be accomplished either directly, by the | |||
| CA, or indirectly, by a separate RA. An entity is presented to the | CA, or indirectly, by a separate RA. An entity is presented to the | |||
| CA or RA, and the authority either records the name(s) claimed for | CA or RA, and the authority either records the name(s) claimed for | |||
| the entity or assigns the entity's name(s). The authority also | the entity or assigns the entity's name(s). The authority also | |||
| determines and records other attributes of the entity that are to | determines and records other attributes of the entity that are to | |||
| be bound in a certificate (such as a public key or authorizations) | be bound in a certificate (such as a public key or authorizations) | |||
| or maintained in the authority's database (such as street address | or maintained in the authority's database (such as street address | |||
| and telephone number). The authority is responsible, possibly | and telephone number). The authority is responsible, possibly | |||
| assisted by an RA, for verifying the entity's identity and vetting | assisted by an RA, for verifying the entity's identity and vetting | |||
| the other attributes, in accordance with the CA's CPS. | the other attributes, in accordance with the CA's CPS. | |||
| Among the registration issues that a CPS may address are the | Among the registration issues that a CPS may address are the | |||
| following [R2527]: | following [R3647]: | |||
| - How a claimed identity and other attributes are verified. | - How a claimed identity and other attributes are verified. | |||
| - How organization affiliation or representation is verified. | - How organization affiliation or representation is verified. | |||
| - What forms of names are permitted, such as X.500 DN, domain | - What forms of names are permitted, such as X.500 DN, domain | |||
| name, or IP address. | name, or IP address. | |||
| - Whether names are required to be meaningful or unique, and | - Whether names are required to be meaningful or unique, and | |||
| within what domain. | within what domain. | |||
| - How naming disputes are resolved, including the role of | - How naming disputes are resolved, including the role of | |||
| trademarks. | trademarks. | |||
| - Whether certificates are issued to entities that are not | - Whether certificates are issued to entities that are not | |||
| persons. | persons. | |||
| - Whether a person is required to appear before the CA or RA, or | - Whether a person is required to appear before the CA or RA, or | |||
| can instead be represented by an agent. | can instead be represented by an agent. | |||
| - Whether and how an entity proves possession of the private key | - Whether and how an entity proves possession of the private key | |||
| matching a public key. | matching a public key. | |||
| $ registration authority (RA) | $ registration authority (RA) | |||
| 1. (I) An optional PKI entity (separate from the CAs) that does | 1. (I) An optional PKI entity (separate from the CAs) that does | |||
| not sign either digital certificates or CRLs but has | not sign either digital certificates or CRLs but has | |||
| responsibility for recording or verifying some or all of the | responsibility for recording or verifying some or all of the | |||
| information (particularly the identities of subjects) needed by a | information (particularly the identities of subjects) needed by a | |||
| CA to issue certificates and CRLs and to perform other certificate | CA to issue certificates and CRLs and to perform other certificate | |||
| management functions. (See: ORA, registration.) | management functions. (See: ORA, registration.) | |||
| skipping to change at page 200, line 15 ¶ | skipping to change at page 214, line 21 ¶ | |||
| revocation reporting. [R2510] | revocation reporting. [R2510] | |||
| Tutorial: Sometimes, a CA may perform all certificate management | Tutorial: Sometimes, a CA may perform all certificate management | |||
| functions for all end users for which the CA signs certificates. | functions for all end users for which the CA signs certificates. | |||
| Other times, such as in a large or geographically dispersed | Other times, such as in a large or geographically dispersed | |||
| community, it may be necessary or desirable to offload secondary | community, it may be necessary or desirable to offload secondary | |||
| CA functions and delegate them to an assistant, while the CA | CA functions and delegate them to an assistant, while the CA | |||
| retains the primary functions (signing certificates and CRLs). The | retains the primary functions (signing certificates and CRLs). The | |||
| tasks that are delegated to an RA by a CA may include personal | tasks that are delegated to an RA by a CA may include personal | |||
| authentication, name assignment, token distribution, revocation | authentication, name assignment, token distribution, revocation | |||
| reporting, key generation, and archiving. An RA is an optional PKI | reporting, key generation, and archiving. | |||
| component, separate from the CA, that is assigned secondary | ||||
| functions. The duties assigned to RAs vary from case to case but | An RA is an optional PKI entity, separate from the CA, that is | |||
| may include the following: | assigned secondary functions. The duties assigned to RAs vary from | |||
| - Verifying a subject's identity, i.e., performing personal | case to case but may include the following: | |||
| - Verifying a subject's identity, i.e., performing personal | ||||
| authentication functions. | authentication functions. | |||
| - Assigning a name to a subject. (See: distinguished name.) | - Assigning a name to a subject. (See: distinguished name.) | |||
| - Verifying that a subject is entitled to have the attributes | - Verifying that a subject is entitled to have the attributes | |||
| requested for a certificate. | requested for a certificate. | |||
| - Verifying that a subject possesses the private key that matches | - Verifying that a subject possesses the private key that matches | |||
| the public key requested for a certificate. | the public key requested for a certificate. | |||
| - Performing functions beyond mere registration, such as | - Performing functions beyond mere registration, such as | |||
| generating key pairs, distributing tokens, and handling | generating key pairs, distributing tokens, handling revocation | |||
| revocation reports. (Such functions may be assigned to a PKI | reports, and archiving data. (Such functions may be assigned to | |||
| component that is separate from both the CA and the RA.) | a PKI component that is separate from both the CA and the RA.) | |||
| 3. (O) /SET/ "An independent third-party organization that | 3. (O) /SET/ "An independent third-party organization that | |||
| processes payment card applications for multiple payment card | processes payment card applications for multiple payment card | |||
| brands and forwards applications to the appropriate financial | brands and forwards applications to the appropriate financial | |||
| institutions." [SET2] | institutions." [SET2] | |||
| $ regrade | $ regrade | |||
| (I) Deliberately change the classification level of information in | (I) Deliberately change the security level (especially the | |||
| an authorized manner. (See: downgrade, upgrade.) | hierarchical classification level) of information in an authorized | |||
| manner. (See: downgrade, upgrade.) | ||||
| $ rekey | $ rekey | |||
| (I) Change the value of a cryptographic key that is being used in | (I) Change the value of a cryptographic key that is being used in | |||
| an application of a cryptographic system. (See: certificate | an application of a cryptographic system. (See: certificate | |||
| rekey.) | rekey.) | |||
| Tutorial: Rekey is required at the end of a cryptoperiod or key | Tutorial: Rekey is required at the end of a cryptoperiod or key | |||
| lifetime. | lifetime. | |||
| $ reliability | $ reliability | |||
| skipping to change at page 201, line 20 ¶ | skipping to change at page 215, line 29 ¶ | |||
| Usage: Used in a legal context to mean a recipient of a | Usage: Used in a legal context to mean a recipient of a | |||
| certificate who acts in reliance on that certificate. (See: ABA | certificate who acts in reliance on that certificate. (See: ABA | |||
| Guidelines.) | Guidelines.) | |||
| $ remanence | $ remanence | |||
| (I) Residual information that can be recovered from a storage | (I) Residual information that can be recovered from a storage | |||
| medium after clearing. (See: clear, magnetic remanence, purge.) | medium after clearing. (See: clear, magnetic remanence, purge.) | |||
| $ Remote Authentication Dial-In User Service (RADIUS) | $ Remote Authentication Dial-In User Service (RADIUS) | |||
| (I) An Internet protocol [R2138] for carrying dial-in users' | (I) An Internet protocol [R2865] for carrying dial-in users' | |||
| authentication information and configuration information between a | authentication information and configuration information between a | |||
| shared, centralized authentication server (the RADIUS server) and | shared, centralized authentication server (the RADIUS server) and | |||
| a network access server (the RADIUS client) that needs to | a network access server (the RADIUS client) that needs to | |||
| authenticate the users of its network access ports. (See: TACACS.) | authenticate the users of its network access ports. (See: TACACS.) | |||
| Tutorial: A user of the RADIUS client presents authentication | Tutorial: A user of the RADIUS client presents authentication | |||
| information to the client, and the client passes that information | information to the client, and the client passes that information | |||
| to the RADIUS server. The server authenticates the client using a | to the RADIUS server. The server authenticates the client using a | |||
| shared secret value, then checks the user's authentication | shared secret value, then checks the user's authentication | |||
| information, and finally returns to the client all authorization | information, and finally returns to the client all authorization | |||
| and configuration information needed by the client to deliver | and configuration information needed by the client to deliver | |||
| service to the user. | service to the user. | |||
| $ renew | $ renew | |||
| See: certificate renewal. | See: certificate renewal. | |||
| $ replay attack | $ replay attack | |||
| (I) An attack in which a valid data transmission is maliciously or | (I) An attack in which a valid data transmission is maliciously or | |||
| fraudulently repeated, either by the originator or by an adversary | fraudulently repeated, either by the originator or by an adversary | |||
| who intercepts the data and retransmits it, possibly as part of a | who intercepts the data and retransmits it, possibly as part of a | |||
| masquerade attack. (See: active wiretapping. Compare: reflection | masquerade attack. (See: active wiretapping, liveness. Compare: | |||
| attack.) | reflection attack.) | |||
| $ reordering | ||||
| (I) /packet/ See: secondary definition under "stream integrity | ||||
| service". | ||||
| $ repository | $ repository | |||
| 1. (I) A system for storing and distributing digital certificates | 1. (I) A system for storing and distributing digital certificates | |||
| and related information (including CRLs, CPSs, and certificate | and related information (including CRLs, CPSs, and certificate | |||
| policies) to certificate users. (See: archive, directory.) | policies) to certificate users. (Compare: archive, directory.) | |||
| 2. (O) "A trustworthy system for storing and retrieving | 2. (O) "A trustworthy system for storing and retrieving | |||
| certificates or other information relevant to certificates." [ABA] | certificates or other information relevant to certificates." [ABA] | |||
| Tutorial: A certificate is published to those who might need it by | Tutorial: A certificate is published to those who might need it by | |||
| putting it in a repository. The repository usually is a publicly | putting it in a repository. The repository usually is a publicly | |||
| accessible, on-line server. In the Federal Public-key | accessible, on-line server. In the FPKI, for example, the expected | |||
| Infrastructure, for example, the expected repository is a | repository is a directory that uses LDAP, but also may be an X.500 | |||
| directory that uses LDAP, but also may be the X.500 Directory that | Directory that uses DAP, or an HTTP server, or an FTP server that | |||
| uses DAP, or an HTTP server, or an FTP server that permits | permits anonymous login. | |||
| anonymous login. | ||||
| $ repudiation | $ repudiation | |||
| 1. (I) Denial by a system entity that was involved in an | 1. (I) Denial by a system entity that was involved in an | |||
| association (especially an association that transfers information) | association (especially an association that transfers information) | |||
| of having participated in the relationship. (See: accountability, | of having participated in the relationship. (See: accountability, | |||
| non-repudiation service.) | non-repudiation service.) | |||
| 2. (I) A type of threat action whereby an entity deceives another | 2. (I) A type of threat action whereby an entity deceives another | |||
| by falsely denying responsibility for an act. (See: deception.) | by falsely denying responsibility for an act. (See: deception.) | |||
| Usage: This type of threat action includes the following subtypes: | Usage: This type of threat action includes the following subtypes: | |||
| - False denial of origin: Action whereby an originator denies | - False denial of origin: Action whereby an originator denies | |||
| responsibility for sending data. | responsibility for sending data. | |||
| - False denial of receipt: Action whereby a recipient denies | - False denial of receipt: Action whereby a recipient denies | |||
| receiving and possessing data. | receiving and possessing data. | |||
| 3. (O) /OSIRM/ "Denial by one of the entities involved in a | 3. (O) /OSIRM/ "Denial by one of the entities involved in a | |||
| communication of having participated in all or part of the | communication of having participated in all or part of the | |||
| communication." [I7498 Part 2] | communication." [I7498 Part 2] | |||
| $ Request for Comment (RFC) | $ Request for Comment (RFC) | |||
| (I) One of the documents in the archival series that is the | 1. (I) One of the documents in the archival series that is the | |||
| official channel for ISDs and other publications of the Internet | official channel for ISDs and other publications of the Internet | |||
| Engineering Steering Group, the Internet Architecture Board, and | Engineering Steering Group, the Internet Architecture Board, and | |||
| the Internet community in general. [R2026, R2223] (See: Internet | the Internet community in general. (RFC 2026, 2223) (See: Internet | |||
| Standard.) | Standard.) | |||
| Deprecated Usage: This term is NOT a synonym for "Internet | 2. (D) A popularly misused synonym for a document on the Internet | |||
| Standard". | Standards Track, i.e., an Internet Standard, Draft Standard, or | |||
| Proposed Standard. (See: Internet Standard.) | ||||
| Deprecated Definition: This term SHOULD NOT be used as a synonym | ||||
| for a document on the Internet Standards Track because many other | ||||
| types of documents also are published as RFCs. | ||||
| $ residual risk | $ residual risk | |||
| (I) The portion of an original risk or set of risks that remains | (I) The portion of an original risk or set of risks that remains | |||
| after countermeasures have been applied. (Compare: acceptable | after countermeasures have been applied. (Compare: acceptable | |||
| risk, risk analysis.) | risk, risk analysis.) | |||
| $ restore | $ restore | |||
| See: card restore. | See: card restore. | |||
| $ revocation | $ revocation | |||
| skipping to change at page 203, line 20 ¶ | skipping to change at page 217, line 36 ¶ | |||
| $ revocation list | $ revocation list | |||
| See: certificate revocation list. | See: certificate revocation list. | |||
| $ revoke | $ revoke | |||
| (I) See: certificate revocation. | (I) See: certificate revocation. | |||
| $ RFC | $ RFC | |||
| (I) See: Request for Comment. | (I) See: Request for Comment. | |||
| $ Rijndael | $ Rijndael | |||
| (I) A block cipher, designed by Joan Daemen and Vincent Rijmen as | (N) A symmetric, block cipher that was designed by Joan Daemen and | |||
| a candidate algorithm for the AES. [Daem] | Vincent Rijmen as a candidate for the AES, and that won that | |||
| competition. [Daem] (See: Advanced Encryption Standard.) | ||||
| $ risk | $ risk | |||
| 1. (I) An expectation of loss expressed as the probability that a | 1. (I) An expectation of loss expressed as the probability that a | |||
| particular threat will exploit a particular vulnerability with a | particular threat will exploit a particular vulnerability with a | |||
| particular harmful result. | particular harmful result. | |||
| 2. (O) /SET/ "The possibility of loss because of one or more | 2. (O) /SET/ "The possibility of loss because of one or more | |||
| threats to information (not to be confused with financial or | threats to information (not to be confused with financial or | |||
| business risk)." [SET2] | business risk)." [SET2] | |||
| Tutorial: There are four basic ways to deal with a risk [SP30]: | ||||
| - "Risk avoidance": Eliminate the risk by either countering the | ||||
| threat or removing the vulnerability. (Compare: "avoidance" | ||||
| under "security".) | ||||
| - "Risk transference": Shift the risk to another system or | ||||
| entity; e.g., buy insurance to compensate for potential loss. | ||||
| - "Risk limitation": Limit the risk by implementing controls that | ||||
| minimize resulting loss. | ||||
| - "Risk assumption": Accept the potential for loss and continue | ||||
| operating the system. | ||||
| $ risk analysis | $ risk analysis | |||
| (I) An assessment process that systematically (a) identifies | (I) An assessment process that systematically (a) identifies | |||
| valuable system resources and threats to those resources, (b) | valuable system resources and threats to those resources, (b) | |||
| quantifies loss exposures (i.e., loss potential) based on | quantifies loss exposures (i.e., loss potential) based on | |||
| estimated frequencies and costs of occurrence, and (c) | estimated frequencies and costs of occurrence, and (c) | |||
| (optionally) recommends how to allocate resources to | (optionally) recommends how to allocate available resources to | |||
| countermeasures so as to minimize total exposure. (See: risk | countermeasures so as to minimize total exposure. (See: risk | |||
| management.) | management, business case analysis. Compare: threat analysis.) | |||
| Tutorial: There are four basic options for dealing with a risk | Tutorial: Usually, it is financially and technically infeasible to | |||
| [SP30]: | avoid or transfer all risks (see: "first corollary" of "second | |||
| - Risk avoidance: Eliminate the risk either by countering the | law" under "Courtney's laws"), and some residual risks will | |||
| threat or removing the vulnerability. | remain, even after all available countermeasures have been | |||
| - Risk transference: Shift the risk to another system or system | deployed (see: "second corollary" of "second law" under | |||
| entity, such as by buying insurance to compensate for loss. | "Courtney's laws"). Thus, a risk analysis typically lists risks in | |||
| - Risk limitation: Limit the risk by implementing controls that | order of cost and criticality, thereby determining where | |||
| minimize the resulting loss. | countermeasures should be applied first. [FP031, R2196] | |||
| - Risk assumption: Accept the potential for loss and continue | ||||
| operating the system. | ||||
| Usually, it is financially and technically infeasible to avoid or | In some contexts, it is infeasible or inadvisable to attempt a | |||
| transfer all risks (see: (first corollary of second law under) | complete or quantitative risk analysis because needed data, time, | |||
| Courtney's laws), and so some residual risk will remain, even | and expertise are not available. Instead, basic answers to | |||
| after all available countermeasures have been deployed (see: | questions about threats and risks may be already built into | |||
| institutional security policies. For example, U.S. DoD policies | ||||
| for data confidentiality "do not explicitly itemize the range of | ||||
| expected threats" but instead "reflect an operational approach ... | ||||
| by stating the particular management controls that must be used to | ||||
| achieve [confidentiality] ... Thus, they avoid listing threats, | ||||
| which would represent a severe risk in itself, and avoid the risk | ||||
| of poor security design implicit in taking a fresh approach to | ||||
| each new problem". [NRC91] | ||||
| (second corollary of second law under) Courtney's laws). Thus, a | $ risk assumption | |||
| risk analysis typically lists risks in order of cost and | (I) See: secondary definition under "risk". | |||
| criticality, thereby determining where countermeasures should be | ||||
| applied first. [FP031, R2196] | ||||
| In some contexts, it is infeasible to do a risk analysis because | $ risk avoidance | |||
| needed data and resources are not available, or it is inadvisable. | (I) See: secondary definition under "risk". | |||
| Instead, answers to questions about threats and risks may be | ||||
| already built into basic institutional security policies. For | $ risk limitation | |||
| example, U.S. DoD policies for data confidentiality "do not | (I) See: secondary definition under "risk". | |||
| explicitly itemize the range of expected threats" but instead | ||||
| "reflect an operational approach ... by stating the particular | ||||
| management controls that must be used to achieve [confidentiality] | ||||
| severe risk in itself, and avoid the risk of poor security design | ||||
| implicit in taking a fresh approach to each new problem". [NRC91] | ||||
| $ risk management | $ risk management | |||
| 1. (I) The process of identifying, measuring, and controlling | 1. (I) The process of identifying, measuring, and controlling | |||
| (i.e., mitigating) risks in information systems so as to reduce | (i.e., mitigating) risks in information systems so as to reduce | |||
| the risks to a level commensurate with the value of the assets | the risks to a level commensurate with the value of the assets | |||
| protected. (See: risk analysis.) | protected. (See: risk analysis.) | |||
| 2. (I) The process of controlling uncertain events that may affect | 2. (I) The process of controlling uncertain events that may affect | |||
| information system resources. | information system resources. | |||
| 3. (O) "The total process of identifying, controlling, and | 3. (O) "The total process of identifying, controlling, and | |||
| mitigating information system-Drelated risks. It includes risk | mitigating information system- Drelated risks. It includes risk | |||
| assessment; cost-benefit analysis; and the selection, | assessment; cost-benefit analysis; and the selection, | |||
| implementation, test, and security evaluation of safeguards. This | implementation, test, and security evaluation of safeguards. This | |||
| overall system security review considers both effectiveness and | overall system security review considers both effectiveness and | |||
| efficiency, including impact on the mission and constraints due to | efficiency, including impact on the mission and constraints due to | |||
| policy, regulations, and laws." [SP30] | policy, regulations, and laws." [SP30] | |||
| $ risk transference | ||||
| (I) See: secondary definition under "risk". | ||||
| $ Rivest Cipher #2 (RC2) | $ Rivest Cipher #2 (RC2) | |||
| (N) A proprietary, variable-key-length block cipher invented by | (N) A proprietary, variable-key-length block cipher invented by | |||
| Ron Rivest for RSA Data Security, Inc. | Ron Rivest for RSA Data Security, Inc. | |||
| $ Rivest Cipher #4 (RC4) | $ Rivest Cipher #4 (RC4) | |||
| (N) A proprietary, variable-key-length stream cipher invented by | (N) A proprietary, variable-key-length stream cipher invented by | |||
| Ron Rivest for RSA Data Security, Inc. | Ron Rivest for RSA Data Security, Inc. | |||
| $ Rivest Cipher #6 (RC6) | $ Rivest Cipher #6 (RC6) | |||
| (N) A block cipher with 128-bit or higher key size; invented by | (N) A symmetric, block cipher with 128-bit or longer key length, | |||
| Ron Rivest for RSA Data Security, Inc. A finalist in the | developed by Ron Rivest for RSA Data Security, Inc. as a candidate | |||
| competition for AES. | for the AES. | |||
| $ Rivest-Shamir-Adleman (RSA) | $ Rivest-Shamir-Adleman (RSA) | |||
| (N) An algorithm for asymmetric cryptography, invented in 1977 by | (N) An algorithm for asymmetric cryptography, invented in 1977 by | |||
| Ron Rivest, Adi Shamir, and Leonard Adleman [RSA78]. | Ron Rivest, Adi Shamir, and Leonard Adleman [RSA78]. | |||
| Tutorial: RSA uses exponentiation modulo the product of two large | Tutorial: RSA uses exponentiation modulo the product of two large | |||
| prime numbers. The difficulty of breaking RSA is believed to be | prime numbers. The difficulty of breaking RSA is believed to be | |||
| equivalent to the difficulty of factoring integers that are the | equivalent to the difficulty of factoring integers that are the | |||
| product of two large prime numbers of approximately equal size. | product of two large prime numbers of approximately equal size. | |||
| skipping to change at page 205, line 48 ¶ | skipping to change at page 220, line 27 ¶ | |||
| private key to get s. She sends m and s. Bob receives m' and s', | 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 | 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 | 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 | 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. | assured that m' is the same m that Alice sent. | |||
| $ robustness | $ robustness | |||
| (N) See: level of robustness. | (N) See: level of robustness. | |||
| $ role | $ role | |||
| 1. (I) A job function (or a job title that implies a set of | 1. (I) A job function (or a job title that implies a function) to | |||
| functions) to which people or other system entities are assigned, | which people or other system entities may be assigned in a system. | |||
| within an organization or other system. (Compare: duty, billet, | (See: role-based access control. Compare: duty, billet, principal, | |||
| principal, user. See: role-based access control.) | user.) | |||
| 2. (O) /Common Criteria/ A pre-defined set of rules establishing | 2. (O) /Common Criteria/ A pre-defined set of rules establishing | |||
| the allowed interactions between a user and the TOE. | the allowed interactions between a user and the TOE. | |||
| $ role-based access control | $ role-based access control | |||
| (I) A form of identity-based access control wherein the system | (I) A form of identity-based access control wherein the system | |||
| entities that are identified and controlled are functional | entities that are identified and controlled are functional | |||
| positions in an organization or process. [Sand] (See: | positions in an organization or process. [Sand] (See: | |||
| authorization, constraint, identity, principal, role.) | authorization, constraint, identity, principal, role.) | |||
| Tutorial: Administrators assign permissions to roles as needed to | Tutorial: Administrators assign permissions to roles as needed to | |||
| perform functions in the system. Administrators separately assign | perform functions in the system. Administrators separately assign | |||
| user identities to roles. When a user accesses the system in an | user identities to roles. When a user accesses the system in an | |||
| identity (for which the user has been registered) and initiates a | identity (for which the user has been registered) and initiates a | |||
| session using a role (to which the user has been assigned), then | session using a role (to which the user has been assigned), then | |||
| the permissions that have been assigned to the role are available | the permissions that have been assigned to the role are available | |||
| to be exercised by the user. | to be exercised by the user. | |||
| The following diagram shows that role-based access control | The following diagram shows that role-based access control | |||
| involves five types relationships. Administrators assign (a) | involves five different relationships: (1) administrators assign | |||
| identities to roles, (b) permissions to roles, and (c) roles to | identities to roles, (2) administrators assign permissions to | |||
| roles; and users select (d) identities in sessions, and (e) roles | roles, (3) administrators assign roles to roles, (4) users select | |||
| in sessions. Security policies may define constraints on these | identities in sessions, and (5) users select roles in sessions. | |||
| assignments and selections. | Security policies may define constraints on these assignments and | |||
| selections. | ||||
| (c) Permission Inheritance Assignments (i.e., Role Hierarchy) | (3) Permission Inheritance Assignments (i.e., Role Hierarchy) | |||
| [Constraints] | [Constraints] | |||
| +=====+ | +=====+ | |||
| | | | | | | |||
| (a) Identity v v (b) Permission | (1) Identity v v (2) Permission | |||
| +----------+ Assignments +-------+ Assignments +----------+ | +----------+ Assignments +-------+ Assignments +----------+ | |||
| |Identities|<=============>| Roles |<=============>|Permissions| | |Identities|<=============>| Roles |<=============>|Permissions| | |||
| +----------+ [Constraints] +-------+ [Constraints] +----------+ | +----------+ [Constraints] +-------+ [Constraints] +----------+ | |||
| | | ^ ^ | | | ^ ^ | |||
| | | +-----------+ | | +---------------------+ | | | +-----------+ | | +---------------------+ | |||
| | | | +-------+ | | | | Legend | | | | | +-------+ | | | | Legend | | |||
| | +====>|Session|=====+ | | | | | +====>|Session|=====+ | | | | |||
| | | +-------+ | | | One-to-One | | | | +-------+ | | | One-to-One | | |||
| | | ... | | | =================== | | | | ... | | | =================== | | |||
| | | +-------+ | | | | | | | +-------+ | | | | | |||
| +========>|Session|=========+ | One-to-Many | | +========>|Session|=========+ | One-to-Many | | |||
| (d) Identity | +-------+ | (e) Role | ==================> | | (4) Identity | +-------+ | (5) Role | ==================> | | |||
| Selections | | Selections | | | Selections | | Selections | | | |||
| [Constraints]| Access |[Constraints] | Many-to-Many | | [Constraints]| Access |[Constraints] | Many-to-Many | | |||
| | Sessions | | <=================> | | | Sessions | | <=================> | | |||
| +-----------+ +---------------------+ | +-----------+ +---------------------+ | |||
| $ role certificate | $ role certificate | |||
| (I) An organizational certificate that is issued to a system | (I) An organizational certificate that is issued to a system | |||
| entity that is a member of the set of users that have identities | entity that is a member of the set of users that have identities | |||
| that are assigned to a particular role. (See: role-based access | that are assigned to the same role. (See: role-based access | |||
| control.) | control.) | |||
| $ root | $ root, root CA | |||
| 1. (I) A CA that is directly trusted by an end entity. | 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 | 2. (I) /hierarchical PKI/ The CA that is the highest level (most | |||
| trusted) CA in a certification hierarchy; i.e., the authority upon | trusted) CA in a certification hierarchy; i.e., the authority upon | |||
| whose public key all certificate users base their validation of | whose public key all certificate users base their validation of | |||
| certificates, CRLs, certification paths, and other constructs. | certificates, CRLs, certification paths, and other constructs. | |||
| (See: top CA.) | (See: top CA.) | |||
| Tutorial: The root CA in a certification hierarchy issues public- | Tutorial: The root CA in a certification hierarchy issues public- | |||
| key certificates to one or more additional CAs that form the | key certificates to one or more additional CAs that form the | |||
| second highest level. Each of these CAs may issue certificates to | second highest level. Each of these CAs may issue certificates to | |||
| skipping to change at page 207, line 26 ¶ | skipping to change at page 222, line 6 ¶ | |||
| securely distributed to all certificate users in a way that does | securely distributed to all certificate users in a way that does | |||
| not depend on the PKI's certification relationships, i.e., by an | not depend on the PKI's certification relationships, i.e., by an | |||
| out-of-band procedure. The root's public key may be distributed | out-of-band procedure. The root's public key may be distributed | |||
| simply as a numerical value, but typically is distributed in a | simply as a numerical value, but typically is distributed in a | |||
| self-signed certificate in which the root is the subject. The | self-signed certificate in which the root is the subject. The | |||
| root's certificate is signed by the root itself because there is | root's certificate is signed by the root itself because there is | |||
| no higher authority in a certification hierarchy. The root's | no higher authority in a certification hierarchy. The root's | |||
| certificate is then the first certificate in every certification | certificate is then the first certificate in every certification | |||
| path. | path. | |||
| 3. (O) /MISSI/ A name previously used for a MISSI policy creation | 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, | authority, which is not a root as defined above for general usage, | |||
| but is a CA at the second level of the MISSI hierarchy, | but is a CA at the second level of the MISSI hierarchy, | |||
| immediately subordinate to a MISSI policy approving authority. | immediately subordinate to a MISSI policy approving authority. | |||
| 4. (O) /UNIX/ A user account (also called "superuser") that has | 5. (O) /UNIX/ A user account (also called "superuser") that has | |||
| all privileges (including all security-related privileges) and | all privileges (including all security-related privileges) and | |||
| thus can manage the system and its other user accounts. | thus can manage the system and its other user accounts. | |||
| 5. (O) /DNS/ The base of the tree structure that defines the name | ||||
| space for the Internet DNS. (See: domain name.) | ||||
| $ root certificate | $ root certificate | |||
| 1. (I) A certificate for which the subject is a root. | 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 | 2. (I) /hierarchical PKI/ The self-signed public-key certificate | |||
| at the top of a certification hierarchy. | at the top of a certification hierarchy. | |||
| $ root key | $ root key | |||
| (I) A public key for which the matching private key is held by a | (I) /PKI/ A public key for which the matching private key is held | |||
| root. | by a root. (See: trust anchor key, trusted key.) | |||
| $ root registry | $ root registry | |||
| (O) /MISSI/ A name previously used for a MISSI PAA. | (O) /MISSI/ A name previously used for a MISSI PAA. | |||
| $ ROT13 | $ ROT13 | |||
| (I) See: Caeser cipher. | (I) See: secondary definition under "Caesar cipher". | |||
| $ router | $ router | |||
| 1. (I) /IP/ A networked computer that forwards IP packets that are | 1a. (I) /IP/ A networked computer that forwards IP packets that | |||
| not addressed to the computer itself. (Compare: host.) | are not addressed to the computer itself. (Compare: host.) | |||
| 2. (I) /OSIRM/ A computer that is a gateway between two networks | ||||
| at OSIRM layer 3 and that relays and directs data packets through | 1b. (I) /IPS/ A gateway that operates in the IPS Internet Layer to | |||
| that internetwork. The most common form of router operates on IP | connect two or more subnetworks. | |||
| packets. (Compare: bridge, proxy.) | ||||
| 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 | $ RSA | |||
| (N) See: Rivest-Shamir-Adleman. | (N) See: Rivest-Shamir-Adleman. | |||
| $ rule | $ rule | |||
| See: security rule. | See: policy rule. | |||
| $ rule-based security policy | $ rule-based security policy | |||
| (I) "A security policy based on global rules imposed for all | (I) "A security policy based on global rules [i.e., policy rules] | |||
| users. These rules usually rely on comparison of the sensitivity | imposed for all users. These rules usually rely on comparison of | |||
| of the resource being accessed and the possession of corresponding | the sensitivity of the resource being accessed and the possession | |||
| attributes of users, a group of users, or entities acting on | of corresponding attributes of users, a group of users, or | |||
| behalf of users." [I7498 Part 2] (Compare: identity-based security | entities acting on behalf of users." [I7498 Part 2] (Compare: | |||
| policy, RBAC.) | identity-based security policy, policy rule, RBAC.) | |||
| $ rules of behavior | $ rules of behavior | |||
| (I) A body of security policy that has been established and | (I) A body of security policy that has been established and | |||
| implemented concerning the responsibilities and expected behavior | implemented concerning the responsibilities and expected behavior | |||
| of entities that have access to a system. (Compare: [R1281].) | of entities that have access to a system. (Compare: [R1281].) | |||
| Tutorial: For persons employed by a corporation or government, the | Tutorial: For persons employed by a corporation or government, the | |||
| rules might cover such matters as working at home, remote access, | rules might cover such matters as working at home, remote access, | |||
| use of the Internet, use of copyrighted works, use of system | use of the Internet, use of copyrighted works, use of system | |||
| resources for unofficial purpose, assignment and limitation of | resources for unofficial purpose, assignment and limitation of | |||
| skipping to change at page 209, line 46 ¶ | skipping to change at page 224, line 30 ¶ | |||
| $ SAML | $ SAML | |||
| (N) See: Security Assertion Markup Language (SAML). | (N) See: Security Assertion Markup Language (SAML). | |||
| $ sandbox | $ sandbox | |||
| (I) A restricted, controlled execution environment that prevents | (I) A restricted, controlled execution environment that prevents | |||
| potentially malicious software, such as mobile code, from | potentially malicious software, such as mobile code, from | |||
| accessing any system resources except those for which the software | accessing any system resources except those for which the software | |||
| is authorized. | is authorized. | |||
| $ sanitize | $ sanitize | |||
| (I) Delete sensitive data from a file, a device, or a system; or | 1. (I) Delete sensitive data from a file, device, or system. | |||
| modify data so as to be able to downgrade its classification | ||||
| level. | 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 | $ SAP | |||
| (O) See: special access program. | (O) See: special access program. | |||
| $ SASL | $ SASL | |||
| (I) See: Simple Authentication and Security Layer. | (I) See: Simple Authentication and Security Layer. | |||
| $ SCA | $ SCA | |||
| (I) See: subordinate certification authority. | (I) See: subordinate certification authority. | |||
| $ scavenging | $ scavenging | |||
| (I) See: (secondary definition under) threat consequence. | (I) See: secondary definition under "threat consequence". | |||
| $ SCI | $ SCI | |||
| (O) See: sensitive compartmented information. | (O) See: sensitive compartmented information. | |||
| $ SCIF | $ SCIF | |||
| (O) See: sensitive compartmented information facility. | (O) See: sensitive compartmented information facility. | |||
| $ SCOMP | $ SCOMP | |||
| (N) Secure COMmunications Processor; an enhanced, MLS version of | (N) Secure COMmunications Processor; an enhanced, MLS version of | |||
| the Honeywell Level 6 minicomputer. It was the first system to be | the Honeywell Level 6 minicomputer. It was the first system to be | |||
| rated in TCSEC Class A1. (See: KSOS.) | rated in TCSEC Class A1. (See: KSOS.) | |||
| $ screen room | $ screen room | |||
| (I) /slang/ Synonym for "shielded enclosure". | (D) /slang/ Synonym for "shielded enclosure" in the context of | |||
| electromagnetic emanations. (See: EMSEC, TEMPEST.) | ||||
| Deprecated Term: To avoid international misunderstanding, ISDs | ||||
| SHOULD NOT use this term. | ||||
| $ screening router | $ screening router | |||
| (I) Synonym for "filtering router". | (I) Synonym for "filtering router". | |||
| $ script kiddy | $ script kiddy | |||
| (D) /slang/ A cracker who is able to use existing attack | (D) /slang/ A cracker who is able to use existing attack | |||
| techniques (i.e., to read scripts) and execute existing attack | techniques (i.e., to read scripts) and execute existing attack | |||
| software, but is unable to invent new exploits or manufacture the | software, but is unable to invent new exploits or manufacture the | |||
| tools to perform them; pejoratively, an immature or novice | tools to perform them; pejoratively, an immature or novice | |||
| cracker. (See: packet monkey.) | cracker. | |||
| Deprecated Term: It is likely that other cultures have different | Deprecated Term: It is likely that other cultures use different | |||
| metaphors for this concept. Therefore, to ensure international | metaphors for this concept. Therefore, to avoid international | |||
| understanding, ISDs SHOULD NOT use this term. (See: (Deprecated | misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated | |||
| Usage under) Green Book.) | Usage under "Green Book".) | |||
| $ SDE | $ SDE | |||
| (N) See: Secure Data Exchange. | (N) See: Secure Data Exchange. | |||
| $ SDNS | $ SDNS | |||
| (O) See: Secure Data Network System. | (O) See: Secure Data Network System. | |||
| $ SDU | ||||
| (N) See: "service data unit" under "protocol data unit". | ||||
| $ seal | $ seal | |||
| 1. (I) To use asymmetric cryptography to encrypt plain text with a | 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 | public key in such a way that only the holder of the matching | |||
| private key can learn what was the plain text. [Chau] | private key can learn what was the plain text. [Chau] | |||
| Usage: The definition is not widely known; therefore, ISDs that | Usage: ISDs that use this term SHOULD state a definition for it | |||
| use this term SHOULD state a definition for it. | because this definition is not widely known. | |||
| Tutorial: The definition does *not* say "only the holder of the | Tutorial: The definition does *not* say "only the holder of the | |||
| matching private key can decrypt the ciphertext to learn what was | matching private key can decrypt the ciphertext to learn what was | |||
| the plaintext"; sealing is stronger than that. If Alice simply | the plaintext"; sealing is stronger than that. If Alice simply | |||
| encrypts a plaintext P with a public key K to produce ciphertext C | 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 | = 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 | 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 | 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 | 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. | P = X, Bob can only test the guess by also guessing R. | |||
| 2. (D) To use cryptography to provide data integrity service for a | 2. (D) To use cryptography to provide data integrity service for a | |||
| data object. (See: sign.) | data object. (See: sign.) | |||
| Deprecated Definition: ISDs SHOULD NOT use this term with this | Deprecated Definition: ISDs SHOULD NOT use this term with this | |||
| definition. Instead, use a term that is more specific with regard | definition. Instead, use a term that is more specific with regard | |||
| to the mechanism(s) used to provide the data integrity service; | to the mechanism used to provide the data integrity service; e.g., | |||
| e.g., use "sign" when the mechanism is digital signature. | use "sign" when the mechanism is digital signature. | |||
| $ secret | $ secret | |||
| 1a. (I) /adjective/ The condition of information being protected | 1a. (I) /adjective/ The condition of information being protected | |||
| from being known by any system entities except those that are | from being known by any system entities except those that are | |||
| intended to know it. | intended to know it. | |||
| 1b. (I) /noun/ An item of information that is protected thusly. | 1b. (I) /noun/ An item of information that is protected thusly. | |||
| Usage: This term applies to symmetric keys, private keys, and | Usage: This term applies to symmetric keys, private keys, and | |||
| passwords. | passwords. | |||
| $ secret key | ||||
| (D) A key that is kept secret or needs to be kept secret. | ||||
| Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | ||||
| in a potentially misleading way. In the context of asymmetric | ||||
| cryptography, ISDs 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 | $ secret-key cryptography | |||
| (D) Synonym for "symmetric cryptography". | (D) Synonym for "symmetric cryptography". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it could be | Deprecated Term: ISDs SHOULD NOT use this term; it could be | |||
| confused with asymmetric cryptography, in which the private key is | confused with asymmetric cryptography, in which the private key is | |||
| secret. | kept secret. | |||
| Derivation: Symmetric cryptography is sometimes called "secret-key | Derivation: Symmetric cryptography is sometimes called "secret-key | |||
| cryptography" because entities that share the key, such as the | cryptography" because entities that share the key, such as the | |||
| originator and the recipient of a message, need to keep the key | originator and the recipient of a message, need to keep the key | |||
| secret from other entities. | secret from other entities. | |||
| $ Secure BGP (S-BGP) | $ Secure BGP (S-BGP) | |||
| (I) A project of BBN Technologies, sponsored by the U.S. DoD's | (I) A project of BBN Technologies, sponsored by the U.S. DoD's | |||
| Defense Advanced Research Projects Agency, to design and | Defense Advanced Research Projects Agency, to design and | |||
| demonstrate an architecture to secure the Border Gateway Protocol | demonstrate an architecture to secure the Border Gateway Protocol | |||
| (RFC 1771) and to promote deployment of that architecture in the | (RFC 1771) and to promote deployment of that architecture in the | |||
| Internet. | Internet. | |||
| Tutorial: S-BGP incorporates three security mechanisms: | Tutorial: S-BGP incorporates three security mechanisms: | |||
| - A PKI supports authentication of ownership of IP address | - A PKI supports authentication of ownership of IP address | |||
| blocks, autonomous system (AS) numbers, an AS's identity, and a | blocks, autonomous system (AS) numbers, an AS's identity, and a | |||
| BGP router's identity and its authorization to represent an AS. | BGP router's identity and its authorization to represent an AS. | |||
| This PKI parallels and takes advantage of the Internet's | This PKI parallels and takes advantage of the Internet's | |||
| existing IP address and AS number assignment system. | existing IP address and AS number assignment system. | |||
| - A new, optional, BGP transitive path attribute carries digital | ||||
| - A new, optional, BGP transitive path attribute carries digital | ||||
| signatures (in "attestations") covering the routing information | signatures (in "attestations") covering the routing information | |||
| in a BGP UPDATE. These signatures along with certificates from | in a BGP UPDATE. These signatures along with certificates from | |||
| the S-BGP PKI enable the receiver of a BGP routing UPDATE to | the S-BGP PKI enable the receiver of a BGP routing UPDATE to | |||
| verify the address prefixes and path information that it | validate the attribute and gain trust in the address prefixes | |||
| contains. | and path information that it contains. | |||
| - IPsec provides data and partial sequence integrity, and enables | - IPsec provides data and partial sequence integrity, and enables | |||
| BGP routers to authenticate each other for exchanges of BGP | BGP routers to authenticate each other for exchanges of BGP | |||
| control traffic. | control traffic. | |||
| $ Secure Data Exchange (SDE) | $ Secure Data Exchange (SDE) | |||
| (N) A LAN security protocol defined by the IEEE 802.10 standard. | (N) A LAN security protocol defined by the IEEE 802.10 standard. | |||
| $ Secure Data Network System (SDNS) | $ Secure Data Network System (SDNS) | |||
| (O) An NSA program that developed security protocols for | (O) An NSA program that developed security protocols for | |||
| electronic mail (see: MSP), OSIRM layer 3 (see: SP3), OSIRM layer | electronic mail (see: MSP), OSIRM Layer 3 (see: SP3), OSIRM Layer | |||
| 4 (see: SP4), and key management (see: KMP). | 4 (see: SP4), and key establishment (see: KMP). | |||
| $ Secure Hash Algorithm (SHA) | $ Secure Hash Algorithm (SHA) | |||
| (N) A cryptographic hash function (specified in SHS) that produces | (N) A cryptographic hash function (specified in SHS) that produces | |||
| a 160-bit output (hash result) for input data of any length < | a 160-bit output (hash result) for input data of any length < | |||
| 2**64 bits. | 2**64 bits. | |||
| $ Secure Hash Standard (SHS) | $ Secure Hash Standard (SHS) | |||
| (N) The U.S. Government standard [FP180] that specifies SHA. | (N) The U.S. Government standard [FP180] that specifies SHA. | |||
| $ Secure Hypertext Transfer Protocol (S-HTTP) | $ Secure Hypertext Transfer Protocol (S-HTTP) | |||
| (I) A Internet protocol (RFC 2660) for providing client-server | (I) A Internet protocol [R2660] for providing client-server | |||
| security services for HTTP communications. (Compare: https.) | security services for HTTP communications. (Compare: https.) | |||
| Tutorial: S-HTTP was originally specified by CommerceNet, a | Tutorial: S-HTTP was originally specified by CommerceNet, a | |||
| coalition of businesses interested in developing the Internet for | coalition of businesses interested in developing the Internet for | |||
| commercial uses. Several message formats may be incorporated into | commercial uses. Several message formats may be incorporated into | |||
| S-HTTP clients and servers, particularly CMS and MOSS. S-HTTP | S-HTTP clients and servers, particularly CMS and MOSS. S-HTTP | |||
| supports choice of security policies, key management mechanisms, | supports choice of security policies, key management mechanisms, | |||
| and cryptographic algorithms through option negotiation between | and cryptographic algorithms through option negotiation between | |||
| parties for each transaction. S-HTTP supports modes of operation | parties for each transaction. S-HTTP supports modes of operation | |||
| for both asymmetric and symmetric cryptography. S-HTTP attempts to | for both asymmetric and symmetric cryptography. S-HTTP attempts to | |||
| avoid presuming a particular trust model, but it attempts to | avoid presuming a particular trust model, but it attempts to | |||
| facilitate multiply-rooted hierarchical trust and anticipates that | facilitate multiply rooted, hierarchical trust and anticipates | |||
| principals may have many public-key certificates. | that principals may have many public-key certificates. | |||
| $ Secure/MIME (S/MIME) | $ Secure/MIME (S/MIME) | |||
| (I) Secure/Multipurpose Internet Mail Extensions, an Internet | (I) Secure/Multipurpose Internet Mail Extensions, an Internet | |||
| protocol (RFC 3851) to provide encryption and digital signatures | protocol [R3851] to provide encryption and digital signatures for | |||
| for Internet mail messages. | Internet mail messages. | |||
| $ secure multicast | $ secure multicast | |||
| (I) Refers generally to providing security services for 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 | groups of various types (e.g., 1-to-N and M-to-N) and to classes | |||
| of protocols used to protect multicast packets. | of protocols used to protect multicast packets. | |||
| Tutorial: Multicast applications include video broadcast and | Tutorial: Multicast applications include video broadcast and | |||
| multicast file transfer, and many of these applications require | multicast file transfer, and many of these applications require | |||
| network security services. The Multicast Security Reference | network security services. The Multicast Security Reference | |||
| Framework [R3740] covers three functional areas: | Framework [R3740] covers three functional areas: | |||
| - Multicast data handling: Security-related treatment of | - Multicast data handling: Security-related treatment of | |||
| multicast data by the sender and the receiver. | multicast data by the sender and the receiver. | |||
| - Group key management: Secure distribution and refreshment of | - Group key management: Secure distribution and refreshment of | |||
| keying material. (See: Group Domain of Interpretation.) | keying material. (See: Group Domain of Interpretation.) | |||
| - Multicast security policy: Policy translation and | - Multicast security policy: Policy translation and | |||
| interpretation across the multiple administrative domains that | interpretation across the multiple administrative domains that | |||
| typically are spanned by a multicast application. | typically are spanned by a multicast application. | |||
| $ Secure Shell(trademark) (SSH(trademark)) | $ Secure Shell(trademark) (SSH(trademark)) | |||
| (N) Trademarks of SSH Communications Security Corp. that refer to | (N) Trademarks of SSH Communications Security Corp. that refer to | |||
| a protocol for secure remote login and other secure network | a protocol for secure remote login and other secure network | |||
| services. | services. | |||
| Tutorial: SSH has three main parts: | Tutorial: SSH has three main parts: | |||
| - Transport layer protocol: Provides server authentication, | - Transport layer protocol: Provides server authentication, | |||
| confidentiality, and integrity; and can optionally provide | confidentiality, and integrity; and can optionally provide | |||
| compression. This layer typically runs over a TCP/IP | compression. This layer typically runs over a TCP connection, | |||
| connection, but might also run on top of any other reliable | but might also run on top of any other reliable data stream. | |||
| data stream. | - User authentication protocol: Authenticates the client-side | |||
| - User authentication protocol: Authenticates the client-side | ||||
| user to the server. It runs over the transport layer protocol. | user to the server. It runs over the transport layer protocol. | |||
| - Connection protocol: Multiplexes the encrypted tunnel into | - Connection protocol: Multiplexes the encrypted tunnel into | |||
| several logical channels. It runs over the user authentication | several logical channels. It runs over the user authentication | |||
| protocol. | protocol. | |||
| $ Secure Sockets Layer (SSL) | $ Secure Sockets Layer (SSL) | |||
| (N) An Internet protocol (originally developed by Netscape | (N) An Internet protocol (originally developed by Netscape | |||
| Communications, Inc.) that uses connection-oriented end-to-end | Communications, Inc.) that uses connection-oriented end-to-end | |||
| encryption to provide data confidentiality service and data | encryption to provide data confidentiality service and data | |||
| integrity service for traffic between a client (often a web | integrity service for traffic between a client (often a web | |||
| browser) and a server, and that can optionally provide peer entity | browser) and a server, and that can optionally provide peer entity | |||
| authentication between the client and the server. (See: Transport | authentication between the client and the server. (See: Transport | |||
| Layer Security.) | Layer Security.) | |||
| Tutorial: The name misleadingly suggests that SSL is situated in | Tutorial: SSL has two layers; SSL's lower layer, the SSL Record | |||
| the IPS transport layer, but SSL is layered above a reliable | Protocol, is layered on top of an IPS Transport-Layer protocol and | |||
| transport protocol (usually TCP) and below an application protocol | encapsulates protocols that run in the upper layer. The upper | |||
| (often HTTP). SSL is independent of the application it | layer protocols are the three SSL management protocols -- SSL | |||
| encapsulates, and any higher level protocol can layer on top of | Handshake Protocol, SSL Change Cipher Spec Protocol, or SSL Alert | |||
| SSL transparently. However, many Internet applications might be | Protocol -- and some Application-Layer protocol (e.g., HTTP). | |||
| better served by IPsec. | ||||
| SSL has two layers: (a) SSL's lower layer, the SSL Record | The SSL management protocols provide asymmetric cryptography for | |||
| Protocol, is layered on top of the transport protocol and | server authentication (verifying the server's identity to the | |||
| encapsulates higher level protocols. One such encapsulated | client) and optional client authentication (verifying the client's | |||
| protocol is SSL Handshake Protocol. (b) SSL's upper layer provides | identity to the server), and also enable them, before the | |||
| asymmetric cryptography for server authentication (verifying the | application protocol transmits or receives data, to negotiate a | |||
| server's identity to the client) and optional client | symmetric encryption algorithm and secret session key (to use for | |||
| authentication (verifying the client's identity to the server), | data confidentiality service) and a keyed hash (to use for data | |||
| and also enables them, before the application protocol transmits | integrity service). | |||
| or receives data, to negotiate a symmetric encryption algorithm | ||||
| and secret session key (to use for data confidentiality service) | SSL is independent of the application it encapsulates, and any | |||
| and a keyed hash (to use for data integrity service). | application can layer on top of SSL transparently. However, many | |||
| Internet applications might be better served by IPsec. | ||||
| $ secure state | $ secure state | |||
| 1a. (I) A system condition in which the system is in conformance | 1a. (I) A system condition in which the system is in conformance | |||
| with the applicable security policy. (Compare: clean system, | with the applicable security policy. (Compare: clean system, | |||
| transaction.) | transaction.) | |||
| 1b. (I) /formal model/ A system condition in which no subject can | 1b. (I) /formal model/ A system condition in which no subject can | |||
| access any object in an unauthorized manner. (See: (secondary | access any object in an unauthorized manner. (See: secondary | |||
| definition under) Bell-LaPadula model.) | definition under "Bell-LaPadula model".) | |||
| $ security | $ security | |||
| 1a. (I) A system condition that results from the establishment and | 1a. (I) A system condition that results from the establishment and | |||
| maintenance of measures to protect the system. | maintenance of measures to protect the system. | |||
| 1b. (I) A system condition in which system resources are free from | 1b. (I) A system condition in which system resources are free from | |||
| unauthorized access and from unauthorized or accidental change, | unauthorized access and from unauthorized or accidental change, | |||
| destruction, or loss. (Compare: safety.) | destruction, or loss. (Compare: safety.) | |||
| 2. (I) Measures taken to protect a system. | 2. (I) Measures taken to protect a system. | |||
| Tutorial: Providing a condition of system security may involve the | Tutorial: Parker suggests that providing a condition of system | |||
| following six basic functions [Park]: | security may involve the following six basic functions [Park]; | |||
| - "Avoidance": Reducing a risk by either reducing the value of | however, these functions overlap to some extent: | |||
| the potential loss or reducing the probability that the loss | - "Deterrence": Reducing an intelligent threat by discouraging | |||
| will occur. (See: risk, risk analysis.) | ||||
| - "Deterrence": Reducing an intelligent threat by discouraging | ||||
| action, such as by fear or doubt. (See: attack, threat action.) | action, such as by fear or doubt. (See: attack, threat action.) | |||
| - "Prevention": Impeding a security violation by using a | - "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 a security violation by using a | ||||
| countermeasure. | countermeasure. | |||
| - "Detection": Determining that a security violation is | - "Detection": Determining that a security violation is | |||
| impending, is in progress, or has recently occurred, and thus | impending, is in progress, or has recently occurred, and thus | |||
| make it possible to reduce the potential loss. (See: intrusion | make it possible to reduce the potential loss. (See: intrusion | |||
| detection.) | detection.) | |||
| - "Recovery": Restoring a normal state of system operation by | - "Recovery": Restoring a normal state of system operation by | |||
| compensating for a security violation, possibly by eliminating | compensating for a security violation, possibly by eliminating | |||
| or repairing its effects. (See: contingency plan.) | or repairing its effects. (See: contingency plan, main entry | |||
| - "Correction": Changing a security architecture to eliminate or | for "recovery".) | |||
| - "Correction": Changing a security architecture to eliminate or | ||||
| reduce the risk of reoccurrence of a security violation or | reduce the risk of reoccurrence of a security violation or | |||
| threat consequence. | threat consequence, such as by eliminating a vulnerability. | |||
| $ security architecture | $ security architecture | |||
| (I) A plan and set of principles that describe (a) the security | (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 | services that a system is required to provide to meet the needs of | |||
| its users, (b) the system components required to implement the | its users, (b) the system components required to implement the | |||
| services, and (c) the performance levels required in the | services, and (c) the performance levels required in the | |||
| components to deal with the threat environment. (See: defense in | components to deal with the threat environment (e.g., [R2179]). | |||
| depth, IATF, (Tutorial under) security policy. Compare: system | (See: defense in depth, IATF, security controls, Tutorial under | |||
| architecture.) | "security policy". Compare: OSIRM System Architecture.) | |||
| Tutorial: A security architecture is the result of applying the | Tutorial: A security architecture is the result of applying the | |||
| system engineering process. A complete system security | system engineering process. A complete system security | |||
| architecture includes administrative security, communication | architecture includes administrative security, communication | |||
| security, computer security, emanations security, personnel | security, computer security, emanations security, personnel | |||
| security, and physical security (e.g., see: [R2179]). A complete | security, and physical security. A complete security architecture | |||
| security architecture needs to deal with both intentional, | needs to deal with both intentional, intelligent threats and | |||
| intelligent threats and accidental threats. | accidental threats. | |||
| $ Security Assertion Markup Language (SAML) | $ Security Assertion Markup Language (SAML) | |||
| (N) A protocol consisting of XML-based request and response | (N) A protocol consisting of XML-based request and response | |||
| message formats for exchanging security information, expressed in | message formats for exchanging security information, expressed in | |||
| the form of assertions about subjects, between online business | the form of assertions about subjects, between online business | |||
| partners. [SAML] | partners. [SAML] | |||
| $ security association | $ security association | |||
| 1. (I) A relationship established between two or more entities to | 1. (I) A relationship established between two or more entities to | |||
| enable them to protect data they exchange. (See: association, | enable them to protect data they exchange. (See: association, | |||
| ISAKMP, SAD. Compare: session.) | ISAKMP, SAD. Compare: session.) | |||
| Tutorial: The relationship is represented by a set of data that is | Tutorial: The relationship is represented by a set of data that is | |||
| shared between the entities and is agreed upon and considered a | shared between the entities and is agreed upon and considered a | |||
| contract between them. The data describes how the associated | contract between them. The data describes how the associated | |||
| entities jointly use security services. The relationship is used | entities jointly use security services. The relationship is used | |||
| to negotiate characteristics of security mechanisms, but the | to negotiate characteristics of security mechanisms, but the | |||
| relationship is usually understood to exclude the mechanisms | relationship is usually understood to exclude the mechanisms | |||
| themselves. | themselves. | |||
| 2. (O) "A set of policy and cryptographic keys that provide | 2. (I) /IPsec/ A simplex (uni-directional) logical connection | |||
| security services to network traffic that matches that policy". | ||||
| [R3740] (See: cryptographic association, group security | ||||
| association.) | ||||
| 3. (O) /IPsec/ A simplex (uni-directional) logical connection | ||||
| created for security purposes and implemented with either AH or | created for security purposes and implemented with either AH or | |||
| ESP (but not both). The security services offered by a security | ESP (but not both). The security services offered by a security | |||
| association depend on the protocol (AH or ESP), the IPsec mode | association depend on the protocol (AH or ESP), the IPsec mode | |||
| (transport or tunnel), the endpoints, and the election of optional | (transport or tunnel), the endpoints, and the election of optional | |||
| services within the protocol. A security association is identified | services within the protocol. A security association is identified | |||
| by a triple consisting of (a) a destination IP address, (b) a | by a triple consisting of (a) a destination IP address, (b) a | |||
| protocol (AH or ESP) identifier, and (c) a Security Parameter | protocol (AH or ESP) identifier, and (c) a Security Parameter | |||
| Index. | 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 | 4. (O) "The totality of communications and security mechanisms and | |||
| functions (e.g., communications protocols, security protocols, | functions (e.g., communications protocols, security protocols, | |||
| security mechanisms and functions) that securely binds together | security mechanisms and functions) that securely binds together | |||
| two security contexts in different end systems or relay systems | two security contexts in different end systems or relay systems | |||
| supporting the same information domain." [DGSA] | supporting the same information domain." [DGSA] | |||
| $ Security Association Database (SAD) | $ Security Association Database (SAD) | |||
| (I) In an IPsec implementation operating in a network node, a | (I) /IPsec/ In an IPsec implementation that operates in a network | |||
| database that contains parameters to describe the status and | node, a database that contains parameters to describe the status | |||
| operation of each of the active security associations that the | and operation of each of the active security associations that the | |||
| node has established with other nodes. Separate inbound and | node has established with other nodes. Separate inbound and | |||
| outbound SADs are needed because of the directionality of IPsec | outbound SADs are needed because of the directionality of IPsec | |||
| security associations. [R2401] (Compare: SPD.) | security associations. [R2401] (Compare: SPD.) | |||
| $ security association identifier (SAID) | $ security association identifier (SAID) | |||
| (I) A data field in a security protocol (such as NLSP or SDE), | (I) A data field in a security protocol (such as NLSP or SDE), | |||
| used to identify the security association to which a protocol data | used to identify the security association to which a PDU is bound. | |||
| unit is bound. The SAID value is usually used to select a key for | The SAID value is usually used to select a key for decryption or | |||
| decryption or authentication at the destination. (See: Security | authentication at the destination. (See: Security Parameter | |||
| Parameter Index.) | Index.) | |||
| $ security assurance | $ security assurance | |||
| 1. (I) An attribute of an information system that provides grounds | 1. (I) An attribute of an information system that provides grounds | |||
| for having confidence that the system operates such that the | for having confidence that the system operates such that the | |||
| system security policy is enforced. (Compare: trust.) | system's security policy is enforced. (Compare: trust.) | |||
| 2. (I) A procedure that ensures a system is developed and operated | 2. (I) A procedure that ensures a system is developed and operated | |||
| as intended by the system's security policy. | as intended by the system's security policy. | |||
| 3. (D) "The degree of confidence one has that the security | 3. (D) "The degree of confidence one has that the security | |||
| controls operate correctly and protect the system as intended." | controls operate correctly and protect the system as intended." | |||
| [SP12] | [SP12] | |||
| Deprecated Definition: ISDs SHOULD NOT use definition 3; it is a | Deprecated Definition: ISDs SHOULD NOT use definition 3; it is a | |||
| definition for "assurance level" rather than for "assurance". | definition for "assurance level" rather than for "assurance". | |||
| skipping to change at page 216, line 41 ¶ | skipping to change at page 231, line 46 ¶ | |||
| of confidence in the vetting process used to establish the | of confidence in the vetting process used to establish the | |||
| identity of the individual to whom the [identity] credential was | identity of the individual to whom the [identity] credential was | |||
| issued" and (b) "the degree of confidence that the individual who | issued" and (b) "the degree of confidence that the individual who | |||
| uses the credential is the individual to whom the credential was | uses the credential is the individual to whom the credential was | |||
| issued". [M0404] | issued". [M0404] | |||
| Deprecated Definition: ISDs SHOULD NOT use definition 4; it mixes | Deprecated Definition: ISDs SHOULD NOT use definition 4; it mixes | |||
| concepts in a potentially misleading way. Part "a" is a definition | concepts in a potentially misleading way. Part "a" is a definition | |||
| for "assurance level" (rather than "security assurance") of an | for "assurance level" (rather than "security assurance") of an | |||
| identity registration process; and part "b" is a definition for | identity registration process; and part "b" is a definition for | |||
| "assurance level" (rather than "security assurance") of such a | "assurance level" (rather than "security assurance") of an | |||
| process. Also, the processes of registration and authentication | identity authentication process. Also, the processes of | |||
| should be defined and designed separately to ensure clarity in | registration and authentication should be defined and designed | |||
| certification. | separately to ensure clarity in certification. | |||
| $ security audit | $ security audit | |||
| (I) An independent review and examination of a system's records | (I) An independent review and examination of a system's records | |||
| and activities to determine the adequacy of system controls, | and activities to determine the adequacy of system controls, | |||
| ensure compliance with established security policy and procedures, | ensure compliance with established security policy and procedures, | |||
| detect breaches in security services, and recommend any changes | detect breaches in security services, and recommend any changes | |||
| that are indicated for countermeasures. [I7498 Part 2, NCS01] | that are indicated for countermeasures. [I7498 Part 2, NCS01] | |||
| (Compare: accounting, intrusion detection.) | (Compare: accounting, intrusion detection.) | |||
| Tutorial: The basic audit objective is to establish accountability | Tutorial: The basic audit objective is to establish accountability | |||
| for system entities that initiate or participate in security- | for system entities that initiate or participate in security- | |||
| relevant events and actions. Thus, means are needed to generate | relevant events and actions. Thus, means are needed to generate | |||
| and record a security audit trail and to review and analyze the | and record a security audit trail and to review and analyze the | |||
| audit trail to discover and investigate attacks and security | audit trail to discover and investigate security violations. | |||
| compromises. | ||||
| $ security audit trail | $ security audit trail | |||
| (I) A chronological record of system activities that is sufficient | (I) A chronological record of system activities that is sufficient | |||
| to enable the reconstruction and examination of the sequence of | to enable the reconstruction and examination of the sequence of | |||
| environments and activities surrounding or leading to an | environments and activities surrounding or leading to an | |||
| operation, procedure, or event in a security-relevant transaction | operation, procedure, or event in a security-relevant transaction | |||
| from inception to final results. [NCS04] (See: security audit.) | from inception to final results. [NCS04] (See: security audit.) | |||
| $ security by obscurity | $ security by obscurity | |||
| (O) Attempting to maintain or increase security of a system by | (O) Attempting to maintain or increase security of a system by | |||
| skipping to change at page 217, line 34 ¶ | skipping to change at page 232, line 37 ¶ | |||
| will be lost or stolen and, therefore, that the algorithms will be | will be lost or stolen and, therefore, that the algorithms will be | |||
| reverse engineered and become known to the adversary. Thus, one | reverse engineered and become known to the adversary. Thus, one | |||
| should rely only on algorithms and protocols that are strong | should rely only on algorithms and protocols that are strong | |||
| enough to have been published widely, and have been peer reviewed | enough to have been published widely, and have been peer reviewed | |||
| for long enough that their flaws have been found and removed. For | for long enough that their flaws have been found and removed. For | |||
| example, NIST used a long, public process to select AES to replace | example, NIST used a long, public process to select AES to replace | |||
| DES. | DES. | |||
| In computer and network security, the principle of "no security by | In computer and network security, the principle of "no security by | |||
| obscurity" also applies to security mechanisms other than | obscurity" also applies to security mechanisms other than | |||
| cryptography. For example, if a protocol for access control, or | cryptography. For example, if the design and implementation of a | |||
| for identification and authentication, is really good, than | protocol for access control are strong, than reading the | |||
| reading the protocol's source code should not enable you to find a | protocol's source code should not enable you to find a way to | |||
| way to evade the protection and penetrate the system. | evade the protection and penetrate the system. | |||
| $ security class | $ security class | |||
| (D) Synonym for "security level". | (D) Synonym for "security level". | |||
| Deprecated Term: ISDs SHOULD NOT use this term. Instead, use | Deprecated Term: ISDs SHOULD NOT use this term. Instead, use | |||
| "security level", which is more widely established and understood. | "security level", which is more widely established and understood. | |||
| $ security clearance | $ security clearance | |||
| (I) A determination that a person is eligible, under the standards | (I) A determination that a person is eligible, under the standards | |||
| of a specific security policy, for authorization to access | of a specific security policy, for authorization to access | |||
| sensitive information or other system resources. (See: clearance | sensitive information or other system resources. (See: clearance | |||
| level.) | level.) | |||
| $ security compromise | $ security compromise | |||
| (I) A security violation in which a system resource is exposed, or | (I) A security violation in which a system resource is exposed, or | |||
| is potentially exposed, to unauthorized access. (Compare: data | is potentially exposed, to unauthorized access. (Compare: data | |||
| compromise, exposure, violation.) | 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 | $ security doctrine | |||
| 1. (I) A specified set of procedures or practices that direct or | 1. (I) A specified set of procedures or practices that direct or | |||
| provide guidance for how to comply with security policy. (Compare: | provide guidance for how to comply with security policy. (Compare: | |||
| security mechanism, security policy.) | security mechanism, security policy.) | |||
| Tutorial: Security policy and security doctrine are relative | Tutorial: Security policy and security doctrine are closely | |||
| terms: policy deals mainly with strategy, and doctrine deals with | related. However, policy deals mainly with strategy, and doctrine | |||
| tactics. | deals with tactics. | |||
| Security doctrine is often understood to refer mainly to | Security doctrine is often understood to refer mainly to | |||
| administrative security, personnel security, and physical | administrative security, personnel security, and physical | |||
| security. For example, security mechanisms and devices that | security. For example, security mechanisms and devices that | |||
| implement them are normally designed to operate in a limited range | implement them are normally designed to operate in a limited range | |||
| of environmental and administrative conditions, and these | of environmental and administrative conditions, and these | |||
| conditions must be met to complement and ensure the technical | conditions must be met to complement and ensure the technical | |||
| protection afforded by the hardware, firmware, and software in the | protection afforded by the hardware, firmware, and software in the | |||
| devices. Security doctrine specifies how to achieve those | devices. Security doctrine specifies how to achieve those | |||
| conditions. (See: (first law under) Courtney's laws.) | conditions. (See: "first law" under "Courtney's laws".) | |||
| $ security domain | $ security domain | |||
| (I) See: domain. | (I) See: domain. | |||
| $ security environment | $ security environment | |||
| (I) The set of external entities, procedures, and conditions that | (I) The set of external entities, procedures, and conditions that | |||
| affect secure development, operation, and maintenance of a system. | affect secure development, operation, and maintenance of a system. | |||
| (See: (first law under) Courtney's laws.) | (See: "first law" under "Courtney's laws".) | |||
| $ security event | $ security event | |||
| (I) A occurrence in a system that is relevant to the security of | (I) An occurrence in a system that is relevant to the security of | |||
| the system. (See: security incident.) | the system. (See: security incident.) | |||
| Tutorial: The term covers both events that are security incidents | Tutorial: The term covers both events that are security incidents | |||
| and those that are not. In a CA workstation, for example, a list | and those that are not. In a CA workstation, for example, a list | |||
| of security events might include the following: | of security events might include the following: | |||
| - Logging the operator in or out. | - Logging an operator into or out of the system. | |||
| - Performing a cryptographic operation, e.g., signing a digital | - Performing a cryptographic operation, e.g., signing a digital | |||
| certificate or CRL. | certificate or CRL. | |||
| - Performing a cryptographic card operation: creation, insertion, | - Performing a cryptographic card operation: creation, insertion, | |||
| removal, or backup. | removal, or backup. | |||
| - Performing a digital certificate lifecycle operation: rekey, | - Performing a digital certificate lifecycle operation: rekey, | |||
| renewal, revocation, or update. | renewal, revocation, or update. | |||
| - Posting information to an X.500 Directory. | ||||
| - Receiving a key compromise notification. | - Posting a digital certificate to an X.500 Directory. | |||
| - Receiving an improper certification request. | - Receiving a key compromise notification. | |||
| - Detecting an alarm condition reported by a cryptographic | - Receiving an improper certification request. | |||
| - Detecting an alarm condition reported by a cryptographic | ||||
| module. | module. | |||
| - Failing a built-in hardware self-test or a software system | - Failing a built-in hardware self-test or a software system | |||
| integrity check. | integrity check. | |||
| $ security fault analysis | $ security fault analysis | |||
| (I) A security analysis, usually performed on hardware at a logic | (I) A security analysis, usually performed on hardware at the | |||
| gate level, gate-by-gate, to determine the security properties of | level of gate logic, gate-by-gate, to determine the security | |||
| a device when a hardware fault is encountered. | properties of a device when a hardware fault is encountered. | |||
| $ security gateway | $ security gateway | |||
| 1. (I) An internetwork gateway that separates trusted (or | 1. (I) An internetwork gateway that separates trusted (or | |||
| relatively more trusted) hosts on one side from untrusted (or less | relatively more trusted) hosts on one side from untrusted (or less | |||
| trusted) hosts on the other side. (See: firewall and guard.) | trusted) hosts on the other side. (See: firewall and guard.) | |||
| 2. (O) /IPsec/ "An intermediate system that implements IPsec | 2. (O) /IPsec/ "An intermediate system that implements IPsec | |||
| protocols." [R2401] | protocols." [R2401] | |||
| Tutorial: IPsec's AH or ESP can be implemented on a gateway | Tutorial: IPsec's AH or ESP can be implemented on a gateway | |||
| between a protected network and an unprotected network, in order | between a protected network and an unprotected network, in order | |||
| to provide security services to the protected network's hosts when | to provide security services to the protected network's hosts when | |||
| they communicate across the unprotected network to other hosts and | they communicate across the unprotected network to other hosts and | |||
| gateways. | gateways. | |||
| $ security incident | $ security incident | |||
| 1. (I) A security event that involves a security violation. (See: | 1. (I) A security event that involves a security violation. (See: | |||
| CERT, GRIP, security event, security intrusion. See: security | CERT, GRIP, security event, security intrusion, security | |||
| violation.) | violation.) | |||
| Tutorial: In other words, a security-relevant system event in | Tutorial: In other words, a security-relevant system event in | |||
| which the system's security policy is disobeyed or otherwise | which the system's security policy is disobeyed or otherwise | |||
| breached. | breached. | |||
| 2. (O) "Any adverse event [that] compromises some aspect of | 2. (D) "Any adverse event [that] compromises some aspect of | |||
| computer or network security." [R2350] | computer or network security." [R2350] | |||
| Deprecated Definition: ISDs SHOULD NOT use this "O" definition, | Deprecated Definition: ISDs SHOULD NOT use this definition, | |||
| because (a) a security incident may occur without actually being | because (a) a security incident may occur without actually being | |||
| harmful (i.e., adverse) and (b) this Glossary defines "compromise" | harmful (i.e., adverse) and (b) this Glossary defines "compromise" | |||
| more narrowly in relation to unauthorized access. | more narrowly in relation to unauthorized access. | |||
| 3. (O) "A violation or imminent threat of violation of computer | 3. (D) "A violation or imminent threat of violation of computer | |||
| security policies, acceptable use policies, or standard computer | security policies, acceptable use policies, or standard computer | |||
| security practices." [SP61] | security practices." [SP61] | |||
| Deprecated Definition: ISDs SHOULD NOT use this "O" definition, | Deprecated Definition: ISDs SHOULD NOT use this definition because | |||
| because mixes concepts in way that does not agree with common | mixes concepts in way that does not agree with common usage; a | |||
| usage; a security incident is commonly thought of as involving a | security incident is commonly thought of as involving a | |||
| realization of a threat (see: threat action), not just a threat. | realization of a threat (see: threat action), not just a threat. | |||
| $ security intrusion | $ security intrusion | |||
| (I) A security event, or a combination of multiple security | (I) A security event, or a combination of multiple security | |||
| events, that constitutes a security incident in which an intruder | events, that constitutes a security incident in which an intruder | |||
| gains, or attempts to gain, access to a system (or system | gains, or attempts to gain, access to a system or system resource | |||
| resource) without having authorization to do so. | without having authorization to do so. | |||
| $ security kernel | $ security kernel | |||
| (I) "The hardware, firmware, and software elements of a trusted | (I) "The hardware, firmware, and software elements of a trusted | |||
| computing base that implement the reference monitor concept. It | computing base that implement the reference monitor concept. It | |||
| must mediate all accesses, be protected from modification, and be | must mediate all accesses, be protected from modification, and be | |||
| verifiable as correct." [NCS04] (See: kernel, TCB.) | verifiable as correct." [NCS04] (See: kernel, TCB.) | |||
| Tutorial: A security kernel is an implementation of a reference | Tutorial: A security kernel is an implementation of a reference | |||
| monitor for a given hardware base. [Huff] | monitor for a given hardware base. [Huff] | |||
| $ security label | $ security label | |||
| (I) An item of meta-data that designates the value of one or more | (I) An item of meta-data that designates the value of one or more | |||
| security-relevant attributes (e.g., security level) of a system | security-relevant attributes (e.g., security level) of a system | |||
| resource. (Compare: security marking. See: [R1457].) | resource. (See: [R1457]. Compare: security marking.) | |||
| Deprecated usage: To avoid confusion, ISDs SHOULD NOT use | Deprecated usage: To avoid confusion, ISDs SHOULD NOT use | |||
| "security label" for "security marking", or vice versa, even | "security label" for "security marking", or vice versa, even | |||
| though that is commonly done (including in some national and | though that is commonly done (including in some national and | |||
| international standards that should know better). | international standards that should know better). | |||
| Tutorial: Humans and automated security mechanisms use a security | Tutorial: Humans and automated security mechanisms use a security | |||
| label of a system resource to determine, according to applicable | label of a system resource to determine, according to applicable | |||
| security policy, how to control access to the resource (and they | security policy, how to control access to the resource (and they | |||
| affix appropriate, matching security markings to physical | affix appropriate, matching security markings to physical | |||
| skipping to change at page 220, line 45 ¶ | skipping to change at page 236, line 4 ¶ | |||
| implicit label that is determined at the time the connection is | implicit label that is determined at the time the connection is | |||
| established. | established. | |||
| Both classified and unclassified system resources may require a | Both classified and unclassified system resources may require a | |||
| security label. (See: FOUO.) | security label. (See: FOUO.) | |||
| $ security level | $ security level | |||
| (I) The combination of a hierarchical classification level and a | (I) The combination of a hierarchical classification level and a | |||
| set of non-hierarchical category designations that represents how | set of non-hierarchical category designations that represents how | |||
| sensitive a specified type or item of information is. (See: | sensitive a specified type or item of information is. (See: | |||
| (Deprecated Usage note under) classification level, dominate, | ||||
| lattice model.) | ||||
| Usage: The term is usually understood to refer to sensitivity to | dominate, lattice model. Compare: classification level.) | |||
| disclosure, but also is used in many other ways and could easily | ||||
| be misunderstood; therefore, ISDs that use this term SHOULD state | Usage: ISDs that use this term SHOULD state a definition for it. | |||
| 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 | $ Security Level field | |||
| (I) A 16-bit field (the "S field") that specifies a security level | (I) A 16-bit field that specifies a security level value in the | |||
| value in the security option (option type 130) of version 4 IP's | security option (option type 130) of version 4 IP's datagram | |||
| datagram header format. | header format. | |||
| Deprecated Abbreviation: ISDs SHOULD NOT use the abbreviation "S | Deprecated Abbreviation: ISDs SHOULD NOT use the abbreviation "S | |||
| field", which is potentially ambiguous. Instead, use "Security | field", which is potentially ambiguous. | |||
| Level field". | ||||
| $ security management infrastructure (SMI) | $ security management infrastructure (SMI) | |||
| (I) System components and activities that support security policy | (I) System components and activities that support security policy | |||
| by monitoring and controlling security services and mechanisms, | by monitoring and controlling security services and mechanisms, | |||
| distributing security information, and reporting security events. | distributing security information, and reporting security events. | |||
| Tutorial: The associated functions are as follows [I7498-4]: | Tutorial: The associated functions are as follows [I7498-4]: | |||
| - Controlling (granting or restricting) access to system | - Controlling (granting or restricting) access to system | |||
| resources: This includes verifying authorizations and | resources: This includes verifying authorizations and | |||
| identities, controlling access to sensitive security data, and | identities, controlling access to sensitive security data, and | |||
| modifying access priorities and procedures in the event of | modifying access priorities and procedures in the event of | |||
| attacks. | attacks. | |||
| - Retrieving (gathering) and archiving (storing) security | - Retrieving (gathering) and archiving (storing) security | |||
| information: This includes logging security events and | information: This includes logging security events and | |||
| analyzing the log, monitoring and profiling usage, and | analyzing the log, monitoring and profiling usage, and | |||
| reporting security violations. | reporting security violations. | |||
| - Managing and controlling the encryption process: This includes | - Managing and controlling the encryption process: This includes | |||
| performing the functions of key management and reporting on key | performing the functions of key management and reporting on key | |||
| management problems. (See: PKI.) | management problems. (See: PKI.) | |||
| $ security marking | $ security marking | |||
| (I) A physical marking that is bound to an instance of a system | (I) A physical marking that is bound to an instance of a system | |||
| resource and that represents a security label of the resource, | resource and that represents a security label of the resource, | |||
| i.e., that names or designates the value of one or more security- | i.e., that names or designates the value of one or more security- | |||
| relevant attributes of the resource. (Compare: security label.) | relevant attributes of the resource. (Compare: security label.) | |||
| Tutorial: A security label may be represented by various | Tutorial: A security label may be represented by various | |||
| equivalent markings depending on the physical form taken by the | equivalent markings depending on the physical form taken by the | |||
| labeled resource. For example, a document could have a marking | labeled resource. For example, a document could have a marking | |||
| composed of a bit pattern [FP188] when the document is stored | composed of a bit pattern [FP188] when the document is stored | |||
| electronically as a file in a computer, and also a marking of | electronically as a file in a computer, and also a marking of | |||
| printed alphabetic characters when the document is in paper form. | printed alphabetic characters when the document is in paper form. | |||
| $ security mechanism | $ security mechanism | |||
| (I) A process (or a device incorporating such a process) that can | (I) A process (or a device incorporating such a process) that can | |||
| be used in a system to implement a security service that is | be used in a system to implement a security service that is | |||
| provided by or within the system. (See: (discussion under) | provided by or within the system. (See: Tutorial under "security | |||
| security policy. Compare: security doctrine.) | policy". Compare: security doctrine.) | |||
| Usage: Usually understood to refer primarily to components of | Usage: Usually understood to refer primarily to components of | |||
| communication security, computer security, and emanation security. | communication security, computer security, and emanation security. | |||
| Examples: Authentication exchange, checksum, digital signature, | Examples: Authentication exchange, checksum, digital signature, | |||
| encryption, and traffic padding. | encryption, and traffic padding. | |||
| $ security model | $ security model | |||
| (I) A schematic description of a set of entities and relationships | (I) A schematic description of a set of entities and relationships | |||
| by which a specified set of security services are provided by or | by which a specified set of security services are provided by or | |||
| within a system. Example: Bell-LaPadula model. (See: (discussion | within a system. Example: Bell-LaPadula model, OSIRM . (See: | |||
| under) security policy.) | Tutorial under "security policy".) | |||
| $ security parameters index (SPI) | $ security parameters index (SPI) | |||
| (I) /IPsec/ A 32-bit identifier used to distinguish among security | (I) /IPsec/ A 32-bit identifier used to distinguish among security | |||
| associations that terminate at the same destination (IP address) | associations that terminate at the same destination (IP address) | |||
| and use the same security protocol (AH or ESP). Carried in AH and | and use the same security protocol (AH or ESP). Carried in AH and | |||
| ESP to enable the receiving system to determine under which | ESP to enable the receiving system to determine under which | |||
| security association to process a received packet. | security association to process a received packet. | |||
| (I) /mobile IP/ A 32-bit index identifying a security association | (I) /mobile IP/ A 32-bit index identifying a security association | |||
| between a pair of nodes, from among the collection of associations | from among the collection of associations that are available | |||
| between them that are available for application to mobile IP | between a pair of nodes, for application to mobile IP protocol | |||
| protocol messages that they exchange. | messages that the nodes exchange. | |||
| $ security perimeter | $ security perimeter | |||
| (I) A physical or logical boundary that is defined for a domain or | (I) A physical or logical boundary that is defined for a domain or | |||
| enclave and within which a particular security policy or security | enclave and within which a particular security policy or security | |||
| architecture applies. (See: insider, outsider.) | architecture applies. (See: insider, outsider.) | |||
| $ security policy | $ security policy | |||
| 1a. (I) A set of security principles or rules that direct how a | 1. (I) A definite goal, course, or method of action to guide and | |||
| system or organization provides security services to protect | determine present and future decisions concerning security in a | |||
| system. [R3198] | ||||
| 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 | sensitive and critical system resources. (See: identity-based | |||
| security policy, policy rule, rule-based security policy, rules of | security policy, policy rule, rule-based security policy, rules of | |||
| behavior. Compare: security architecture, security doctrine, | behavior. Compare: security architecture, security doctrine, | |||
| security mechanism, security model, [R1281].) | security mechanism, security model, [R1281].) | |||
| 1b. (O) /X.509/ A set of security rules laid down by an authority | 2b. (O) A set of rules to administer, manage, and control access | |||
| to govern the use and provision of security services and | to network resources. [R3060, R3198] | |||
| facilities. | ||||
| 2. (O) /Common Criteria/ A set of rules that regulate how assets | 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. | are managed, protected, and distributed within a TOE. | |||
| Tutorial: Ravi Sandhu notes that security policy is one of four | Tutorial: Ravi Sandhu suggests that security policy is one of four | |||
| layers of the security engineering process (as shown in the | layers of the security engineering process (as shown in the | |||
| following diagram). Each layer provides a different view of | following diagram). Each layer provides a different view of | |||
| security, ranging from what services are needed to how services | security, ranging from what services are needed to how services | |||
| are implemented. From a security architect~Os perspective, a | are implemented. | |||
| security policy is the requirements specification for designing an | ||||
| adequately secure system. | ||||
| What Security Services Should Be Provided? | What Security Services | |||
| ^ | Should Be Provided? +- - - - - - - - - - - - -+ | |||
| | + - - - - - - - - - - - + | ^ +- - - - - - - - - - - -| Mission Functions View | | |||
| | | Security Policy | | | | Security Policy |- - - - - - - - - - - - -+ | |||
| | + - - - - - - - - - - - + + - - - - - - - - - - - - - - + | | +- - - - - - - - - - - -| Domain Practices View | | |||
| | | Security Model | | A "top-level specification" | | | | Security Model |- - - - - - - - - - - - -+ | |||
| | + - - - - - - - - - - - + <- | is at a level below "model" | | | +- - - - - - - - - - - -| Enclave Services View | | |||
| | | Security Architecture | | but above "architecture". | | | | Security Architecture |- - - - - - - - - - - - -+ | |||
| | + - - - - - - - - - - - + + - - - - - - - - - - - - - - + | | +- - - - - - - - - - - -| Agent Mechanisms View | | |||
| | | Security Mechanism | | | | Security Mechanism |- - - - - - - - - - - - -+ | |||
| | + - - - - - - - - - - - + | v +- - - - - - - - - - - -| Platform Devices View | | |||
| v | How Are Security +- - - - - - - - - - - - -+ | |||
| How Are Security Services Implemented? | Services Implemented? | |||
| Rob Shirey suggests that another way to think about Sandhu's | We suggest that each of Sandhu's four layers is a mapping between | |||
| layers is to say that statements of security policy vary in their | two points of view that differ in their degree of abstraction, | |||
| degree of abstraction according to the perspectives of the | according to the perspectives of various participants in system | |||
| participants in system design, development, and operation | design, development, and operation activities, as follows:. | |||
| activities: | - Mission functions view: The perspective of a user of system | |||
| - Mission functions view: Has perspective of user of information | resources. States time-phased protection needs for resources | |||
| system resources. States time-phased protection needs for | and identifies sensitive and critical resources -- networks, | |||
| system resources and identifies sensitive and critical | hosts, applications, and databases. Independent of rules and | |||
| resources -- networks, hosts, applications, and databases. | practices used to achieve protection. | |||
| Independent of rules and practices used to achieve protection. | - Domain practices view: The perspective of an enterprise manager | |||
| - Domain practices view: Has perspective of enterprise manager | ||||
| who sets protection standards for resources. States rules and | who sets protection standards for resources. States rules and | |||
| practices for protection. Identifies domain members; i.e., | practices for protection. Identifies domain members; i.e., | |||
| entities (users/providers) and resources (including data | entities (users/providers) and resources (including data | |||
| objects). Independent of system topology. Not required to be | objects). Independent of system topology. Not required to be | |||
| hierarchical. | hierarchical. | |||
| - Enclave services view: Has perspective of system designer who | - Enclave services view: The perspective of a system designer who | |||
| allocates security functions to major components. Assigns | allocates security functions to major components. Assigns | |||
| security services to system topology structures and their | security services to system topology structures and their | |||
| contents. Independent of security mechanisms. Hierarchical | contents. Independent of security mechanisms. Hierarchical | |||
| across all domains. | across all domains. | |||
| - Agent mechanisms view: Has perspective of system engineer who | - Agent mechanisms view: The perspective of a system engineer who | |||
| specifies security mechanisms to implement security services. | specifies security mechanisms to implement security services. | |||
| Specifies mechanisms to be used by protocol, database, and | Specifies mechanisms to be used by protocol, database, and | |||
| application engines. Independent of type and manufacture of | application engines. Independent of type and manufacture of | |||
| platforms and other physical devices. | platforms and other physical devices. | |||
| - Platform devices view: Has perspective of as-built description | - Platform devices view: The perspective of an as-built | |||
| of the system in operation. Specifies exactly how to build or | description of the system in operation. Specifies exactly how | |||
| assemble the system, and also specifies procedures for | to build or assemble the system, and also specifies procedures | |||
| operating the system. | for operating the system. | |||
| $ Security Policy Database (SPD) | $ Security Policy Database (SPD) | |||
| (I) In an IPsec implementation operating in a network node, a | (I) /IPsec/ In an IPsec implementation operating in a network | |||
| database that contains parameters that specify policies set by a | node, a database that contains parameters that specify policies | |||
| user or administrator to determine what IPsec services, if any, | set by a user or administrator to determine what IPsec services, | |||
| are to be provided to IP datagrams sent or received by the node, | if any, are to be provided to IP datagrams sent or received by the | |||
| and in what fashion they are provided. For each datagram, the SPD | node, and in what fashion they are provided. For each datagram, | |||
| specifies one of three choices: discard the datagram, apply IPsec | the SPD specifies one of three choices: discard the datagram, | |||
| services (e.g., AH or ESP), or bypass IPsec. Separate inbound and | apply IPsec services (e.g., AH or ESP), or bypass IPsec. Separate | |||
| outbound SPDs are needed because of the directionality of IPsec | inbound and outbound SPDs are needed because of the directionality | |||
| security associations. [R2401] (Compare: SAD.) | of IPsec security associations. [R2401] (Compare: SAD.) | |||
| $ Security Protocol 3 (SP3) | $ Security Protocol 3 (SP3) | |||
| (O) A protocol [SDNS3] developed by SDNS to provide connectionless | (O) A protocol [SDNS3] developed by SDNS to provide connectionless | |||
| data security at the top of OSIRM layer 3. (Compare: IPsec, NLSP.) | data security at the top of OSIRM Layer 3. (Compare: IPsec, NLSP.) | |||
| $ Security Protocol 4 (SP4) | $ Security Protocol 4 (SP4) | |||
| (O) A protocol [SDNS4] developed by SDNS to provide either | (O) A protocol [SDNS4] developed by SDNS to provide either | |||
| connectionless or end-to-end connection-oriented data security at | connectionless or end-to-end connection-oriented data security at | |||
| the bottom of OSIRM layer 4. (See: TLSP.) | the bottom of OSIRM Layer 4. (See: TLSP.) | |||
| $ security-relevant event | $ security-relevant event | |||
| (D) See: security event. | (D) See: security event. | |||
| $ security rule | ||||
| (I) A building block of a security policy; it defines (a) a set of | ||||
| system conditions and (b) a set of system actions that are to be | ||||
| performed if those conditions occur. [R3198] | ||||
| $ security service | $ security service | |||
| 1. (I) A processing or communication service that is provided by a | 1. (I) A processing or communication service that is provided by a | |||
| system to give a specific kind of protection to system resources. | system to give a specific kind of protection to system resources. | |||
| (See: access control service, audit service, availability service, | (See: access control service, audit service, availability service, | |||
| data confidentiality service, data integrity service, data origin | data confidentiality service, data integrity service, data origin | |||
| authentication service, non-repudiation service, peer entity | authentication service, non-repudiation service, peer entity | |||
| authentication service, system integrity service.) | authentication service, system integrity service.) | |||
| Tutorial: Security services implement security policies, and are | Tutorial: Security services implement security policies, and are | |||
| implemented by security mechanisms. | implemented by security mechanisms. | |||
| 2. (O) "A service, provided by a layer of communicating open | 2. (O) "A service, provided by a layer of communicating open | |||
| systems, which ensures adequate security of the systems or the | systems, which ensures adequate security of the systems or the | |||
| data transfers." [I7498 Part 2] | data transfers." [I7498 Part 2] | |||
| $ security situation | $ security situation | |||
| (I) ISAKMP usage: The set of all security-relevant information -- | (I) /ISAKMP/ The set of all security-relevant information -- e.g., | |||
| e.g., network addresses, security classifications, manner of | network addresses, security classifications, manner of operation | |||
| operation (normal or emergency) -- that is needed to decide the | (normal or emergency) -- that is needed to decide the security | |||
| security services that are required to protect the association | services that are required to protect the association that is | |||
| that is being negotiated. | being negotiated. | |||
| $ security target | $ security target | |||
| (N) /Common Criteria/ A set of security requirements and | (N) /Common Criteria/ A set of security requirements and | |||
| specifications to be used as the basis for evaluation of an | specifications to be used as the basis for evaluation of an | |||
| identified TOE. | identified TOE. | |||
| Tutorial: An security target (ST) is a statement of security | Tutorial: An security target (ST) is a statement of security | |||
| claims for a particular information technology security product or | claims for a particular information technology security product or | |||
| system, and is the basis for agreement among all parties as to | system, and is the basis for agreement among all parties as to | |||
| what security the product or system offers. An ST parallels the | what security the product or system offers. An ST parallels the | |||
| skipping to change at page 225, line 19 ¶ | skipping to change at page 240, line 18 ¶ | |||
| $ security token | $ security token | |||
| (I) See: token. | (I) See: token. | |||
| $ security violation | $ security violation | |||
| (I) An act or event that disobeys or otherwise breaches security | (I) An act or event that disobeys or otherwise breaches security | |||
| policy. (See: compromise, penetration, security incident.) | policy. (See: compromise, penetration, security incident.) | |||
| $ seed | $ seed | |||
| (I) A value that is an input to a pseudorandom number generator. | (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 personal | ||||
| identification number (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 | $ self-signed certificate | |||
| (I) A public-key certificate for which the public key bound by the | (I) A public-key certificate for which the public key bound by the | |||
| certificate and the private key used to sign the certificate are | certificate and the private key used to sign the certificate are | |||
| components of the same key pair, which belongs to the signer. | components of the same key pair, which belongs to the signer. | |||
| (Compare: root certificate.) | (Compare: root certificate.) | |||
| Tutorial: In a self-signed X.509 public-key certificate, the | Tutorial: In a self-signed X.509 public-key certificate, the | |||
| issuer's DN is the same as the subject's DN. | issuer's DN is the same as the subject's DN. | |||
| $ semantic security | $ semantic security | |||
| skipping to change at page 225, line 40 ¶ | skipping to change at page 241, line 33 ¶ | |||
| of the notion that the algorithm not only hides the plain text but | of the notion that the algorithm not only hides the plain text but | |||
| also reveals no partial information about the plain text; i.e., | also reveals no partial information about the plain text; i.e., | |||
| whatever is computable about the plain text when given the cipher | whatever is computable about the plain text when given the cipher | |||
| text, is also computable without the cipher text. (Compare: | text, is also computable without the cipher text. (Compare: | |||
| indistinguishability.) | indistinguishability.) | |||
| $ semiformal | $ semiformal | |||
| (I) Expressed in a restricted syntax language with defined | (I) Expressed in a restricted syntax language with defined | |||
| semantics. [CCIB] (Compare: formal, informal.) | 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) | $ sensitive compartmented information (SCI) | |||
| (O) /U.S. Government/ Classified information concerning or derived | (O) /U.S. Government/ Classified information concerning or derived | |||
| from intelligence sources, methods, or analytical processes, which | from intelligence sources, methods, or analytical processes, which | |||
| is required to be handled within formal control systems | is required to be handled within formal control systems | |||
| established by the Director of Central Intelligence. [DC6/9] (See: | established by the Director of Central Intelligence. [DC6/9] (See: | |||
| SCIF) | compartment, SCIF) | |||
| $ sensitive compartmented information facility (SCIF) | $ sensitive compartmented information facility (SCIF) | |||
| (O) /U.S. Government/ An accredited area, room, group of rooms, | (O) /U.S. Government/ An accredited area, room, group of rooms, | |||
| building, or installation where SCI may be stored, used, | building, or installation where SCI may be stored, used, | |||
| discussed, or electronically processed. [DC6/9] | discussed, or electronically processed. [DC6/9] (See: SCI. | |||
| Compare: shielded enclosure.) | ||||
| $ sensitive information | $ sensitive information | |||
| (I) Information for which (a) disclosure, (b) alteration, or (c) | (I) Information for which (a) disclosure, (b) alteration, or (c) | |||
| destruction or loss could adversely affect the interests or | destruction or loss could adversely affect the interests or | |||
| business of its owner or user. (See: data confidentiality, data | business of its owner or user. (See: data confidentiality, data | |||
| integrity. Compare: classified, critical.) | integrity, sensitive. Compare: classified, critical.) | |||
| (O) /U.S. Government/ Information for which (a) loss, (b) misuse, | (O) /U.S. Government/ Information for which (a) loss, (b) misuse, | |||
| (c) unauthorized access, or (d) unauthorized modification could | (c) unauthorized access, or (d) unauthorized modification could | |||
| adversely affect the national interest or the conduct of federal | adversely affect the national interest or the conduct of federal | |||
| programs, or the privacy to which individuals are entitled under | programs, or the privacy to which individuals are entitled under | |||
| the Privacy Act of 1974, but that has not been specifically | the Privacy Act of 1974, but that has not been specifically | |||
| authorized under criteria established by an Executive Order or an | authorized under criteria established by an Executive Order or an | |||
| Act of Congress to be kept classified in the interest of national | Act of Congress to be kept classified in the interest of national | |||
| defense or foreign policy. | defense or foreign policy. | |||
| Tutorial: Systems that are not U.S. national security systems, but | Tutorial: Systems that are not U.S. national security systems, but | |||
| contain sensitive U.S. Federal Government information, must be | contain sensitive U.S. Federal Government information, must be | |||
| protected according to the Computer Security Act of 1987 (Public | protected according to the Computer Security Act of 1987 (Public | |||
| Law 100-235). | Law 100-235). | |||
| $ sensitivity label | $ sensitivity label | |||
| (D) Synonym for "classification label". | (D) Synonym for "classification label". | |||
| Deprecated term: ISDs should not use this term because the | Deprecated term: ISDs SHOULD NOT use this term because the | |||
| definition of "sensitive" involves not only data confidentiality, | definition of "sensitive" involves not only data confidentiality, | |||
| but also data integrity. | but also data integrity. | |||
| $ sensitivity level | $ sensitivity level | |||
| (D) Synonym for "classification level". | (D) Synonym for "classification level". | |||
| Deprecated term: ISDs should not use this term because the | Deprecated term: ISDs SHOULD NOT use this term because the | |||
| definition of "sensitive" involves not only data confidentiality, | definition of "sensitive" involves not only data confidentiality, | |||
| but also data integrity. | but also data integrity. | |||
| $ separation of duties | $ separation of duties | |||
| (I) The practice of dividing the steps in a system function among | (I) The practice of dividing the steps in a system process among | |||
| different individual entities (i.e., different users or different | different individual entities (i.e., different users or different | |||
| roles) so as to keep a single entity from subverting the process. | roles) so as to prevent a single entity acting alone from being | |||
| Sometimes called "separation of privilege". (See: administrative | able to subvert the process. Usage: a.k.a. "separation of | |||
| security, dual control.) | privilege". (See: administrative security, dual control.) | |||
| $ serial number | $ serial number | |||
| See: certificate 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 | $ server | |||
| (I) A system entity that provides a service in response to | (I) A system entity that provides a service in response to | |||
| requests from other system entities called clients. | requests from other system entities called clients. | |||
| $ service data unit (SDU) | ||||
| (N) See: secondary definition under "protocol data unit". | ||||
| $ session | $ session | |||
| 1a. (I) /computer usage/ A continuous period of time, usually | 1a. (I) /computer usage/ A continuous period of time, usually | |||
| initiated by a login, during which a user accesses a computer | initiated by a login, during which a user accesses a computer | |||
| system. | system. | |||
| 1b. (I) /computer activity/ The set of transactions or other | 1b. (I) /computer activity/ The set of transactions or other | |||
| computer activities that are performed by or for a user during a | computer activities that are performed by or for a user during a | |||
| period of computer usage. | period of computer usage. | |||
| 2. (I) /access control/ A temporary mapping of a principal to one | 2. (I) /access control/ A temporary mapping of a principal to one | |||
| or more roles. (See: role-based access control.) | or more roles. (See: role-based access control.) | |||
| Tutorial: A user establishes a session as a principal and | Tutorial: A user establishes a session as a principal and | |||
| activates some subset of roles to which the principal has been | activates some subset of roles to which the principal has been | |||
| assigned. The authorizations available to the principal in the | assigned. The authorizations available to the principal in the | |||
| session are the union of permissions from all the roles activated | session are the union of the permissions of all the roles | |||
| in the session. Each session is associated with a single principal | activated in the session. Each session is associated with a single | |||
| and, therefore, with a single user. A principal may have multiple, | principal and, therefore, with a single user. A principal may have | |||
| concurrent sessions and may activate a different set of roles in | multiple, concurrent sessions and may activate a different set of | |||
| each session. | roles in each session. | |||
| 3. (I) /computer network/ A persistent but (normally) temporary | 3. (I) /computer network/ A persistent but (normally) temporary | |||
| association between a user agent (typically a client) and a second | association between a user agent (typically a client) and a second | |||
| process (typically a server). The association may persist across | process (typically a server). The association may persist across | |||
| multiple exchanges of data, including multiple connections. | multiple exchanges of data, including multiple connections. | |||
| (Compare: security association.) | (Compare: security association.) | |||
| $ session key | $ session key | |||
| (I) In the context of symmetric encryption, a key that is | (I) In the context of symmetric encryption, a key that is | |||
| temporary or is used for a relatively short period of time. (See: | temporary or is used for a relatively short period of time. (See: | |||
| ephemeral key, KDC, session. Compare: master key.) | ephemeral, KDC, session. Compare: master key.) | |||
| Tutorial: A session key is used for a defined period of | Tutorial: A session key is used for a defined period of | |||
| communication between two system entities or components, such as | communication between two system entities or components, such as | |||
| for the duration of a single connection or transaction set; or the | for the duration of a single connection or transaction set; or the | |||
| key is used in an application that protects relatively large | key is used in an application that protects relatively large | |||
| amounts of data and, therefore, needs to be rekeyed frequently. | amounts of data and, therefore, needs to be rekeyed frequently. | |||
| $ SET | $ SET(trademark) | |||
| (O) See: SET Secure Electronic Transaction(trademark). | (O) See: SET Secure Electronic Transaction(trademark). | |||
| $ SET private extension | $ SET private extension | |||
| (O) One of the private extensions defined by SET for X.509 | (O) One of the private extensions defined by SET for X.509 | |||
| certificates. Carries information about hashed root key, | certificates. Carries information about hashed root key, | |||
| certificate type, merchant data, cardholder certificate | certificate type, merchant data, cardholder certificate | |||
| requirements, encryption support for tunneling, or message support | requirements, encryption support for tunneling, or message support | |||
| for payment instructions. | for payment instructions. | |||
| $ SET qualifier | $ SET qualifier | |||
| skipping to change at page 228, line 21 ¶ | skipping to change at page 244, line 30 ¶ | |||
| confidentiality of transaction information, payment integrity, and | confidentiality of transaction information, payment integrity, and | |||
| authentication of transaction participants for payment card | authentication of transaction participants for payment card | |||
| transactions over unsecured networks, such as the Internet. [SET1] | transactions over unsecured networks, such as the Internet. [SET1] | |||
| (See: acquirer, brand, cardholder, dual signature, electronic | (See: acquirer, brand, cardholder, dual signature, electronic | |||
| commerce, IOTP, issuer, merchant, payment gateway, third party.) | commerce, IOTP, issuer, merchant, payment gateway, third party.) | |||
| Tutorial: This term and acronym are trademarks of SETCo. | Tutorial: This term and acronym are trademarks of SETCo. | |||
| MasterCard and Visa announced the SET standard on 1 February 1996. | MasterCard and Visa announced the SET standard on 1 February 1996. | |||
| $ SETCo | $ SETCo | |||
| (O) Abbreviation for "SET Secure Electronic Transaction LLC", | (O) Abbreviation of "SET Secure Electronic Transaction LLC", | |||
| formed on 19 December 1997 by MasterCard and Visa for the purpose | formed on 19 December 1997 by MasterCard and Visa for the purpose | |||
| of implementing the SET Secure Electronic Transaction" standard. | of implementing the SET Secure Electronic Transaction(trademark) | |||
| A memorandum of understanding adds American Express and JCB Credit | standard. A later memorandum of understanding added American | |||
| Card Company as co-owners of SETCo. | Express and JCB Credit Card Company as co-owners of SETCo. | |||
| $ SHA, SHA-1, SHA-2 | $ SHA, SHA-1, SHA-2 | |||
| (N) See: Secure Hash Algorithm. | (N) See: Secure Hash Algorithm. | |||
| $ shared identity | $ shared identity | |||
| (I) See: (secondary definition under) identity. | (I) See: secondary definition under "identity". | |||
| $ shared secret | $ shared secret | |||
| (D) A synonym for "cryptographic key" or "password". | (D) A synonym for "cryptographic key" or "password". | |||
| Deprecated Usage: The term is used in many ways and could easily | Deprecated Usage: ISDs that use this term SHOULD state a | |||
| be misunderstood; therefore, ISDs that use this term SHOULD state | definition for it because the term is used in many ways and could | |||
| a definition for it. | easily be misunderstood. | |||
| $ shielded enclosure | $ shielded enclosure | |||
| (O) "Room or container designed to attenuate electromagnetic | (O) "Room or container designed to attenuate electromagnetic | |||
| radiation." [C4009] (See: emanation.) | radiation." [C4009] (See: emanation. Compare: SCIF.) | |||
| $ short title | $ short title | |||
| (O) "Identifying combination of letters and numbers assigned to | (O) "Identifying combination of letters and numbers assigned to | |||
| certain items of COMSEC material to facilitate handling, | certain items of COMSEC material to facilitate handling, | |||
| accounting, and controlling." [C4009] (Compare: KMID, long title.) | accounting, and controlling." [C4009] (Compare: KMID, long title.) | |||
| $ SHS | $ SHS | |||
| (N) See: Secure Hash Standard. | (N) See: Secure Hash Standard. | |||
| $ sign | $ sign | |||
| skipping to change at page 229, line 19 ¶ | skipping to change at page 245, line 25 ¶ | |||
| data. (See: emanation. Compare: traffic analysis.) | data. (See: emanation. Compare: traffic analysis.) | |||
| $ signal intelligence | $ signal intelligence | |||
| (I) The science and practice of extracting information from | (I) The science and practice of extracting information from | |||
| signals. (See: signal security.) | signals. (See: signal security.) | |||
| $ signal security | $ signal security | |||
| (N) (I) The science and practice of protecting signals. (See: | (N) (I) The science and practice of protecting signals. (See: | |||
| cryptology, security.) | cryptology, security.) | |||
| Tutorial: The term "signal" denotes communication in almost any | Tutorial: The term "signal" denotes (a) communication in almost | |||
| form and also impulses emitted for other purposes, such as radar. | any form and also (b) emanations for other purposes, such as | |||
| Signal security is opposed by signal intelligence, and each | radar. Signal security is opposed by signal intelligence, and each | |||
| discipline includes opposed sub-disciplines as follows [Kahn]: | discipline includes opposed sub-disciplines as follows [Kahn]: | |||
| Signal Security Signal Intelligence | Signal Security Signal Intelligence | |||
| ------------------------------ --------------------------------- | ------------------------------ --------------------------------- | |||
| 1. Communication Security 1. Communication Intelligence | 1. Communication Security 1. Communication Intelligence | |||
| 1a. Cryptography 1a. Cryptanalysis | 1a. Cryptography 1a. Cryptanalysis | |||
| 1b. Traffic Security 1b. Traffic Analysis | 1b. Traffic Security 1b. Traffic Analysis | |||
| 1c. Steganography 1c. Detection and Interception | 1c. Steganography 1c. Detection and Interception | |||
| 2. Electronic Security 2. Electronic Intelligence | 2. Electronic Security 2. Electronic Intelligence | |||
| 2a. Emission Security 2a. Electronic Reconnaissance | 2a. Emission Security 2a. Electronic Reconnaissance | |||
| skipping to change at page 230, line 36 ¶ | skipping to change at page 246, line 44 ¶ | |||
| service to connection-based protocols. | service to connection-based protocols. | |||
| Tutorial: To use SASL, a protocol includes a command for | Tutorial: To use SASL, a protocol includes a command for | |||
| authenticating a user to a server and for optionally negotiating | authenticating a user to a server and for optionally negotiating | |||
| protection of subsequent protocol interactions. The command names | protection of subsequent protocol interactions. The command names | |||
| a registered security mechanism. SASL mechanisms include Kerberos, | a registered security mechanism. SASL mechanisms include Kerberos, | |||
| GSSAPI, S/KEY, and others. Some protocols that use SASL are IMAP4 | GSSAPI, S/KEY, and others. Some protocols that use SASL are IMAP4 | |||
| and POP3. | and POP3. | |||
| $ Simple Key Management for Internet Protocols (SKIP) | $ Simple Key Management for Internet Protocols (SKIP) | |||
| (I) A key distribution protocol that uses hybrid encryption to | (I) A key-distribution protocol that uses hybrid encryption to | |||
| convey session keys that are used to encrypt data in IP packets. | convey session keys that are used to encrypt data in IP packets. | |||
| Tutorial: SKIP was designed by Ashar Aziz and Whitfield Diffie at | Tutorial: SKIP was designed by Ashar Aziz and Whitfield Diffie at | |||
| Sun Microsystems and proposed as the standard key management | Sun Microsystems and proposed as the standard key management | |||
| protocol for IPsec, but IKE was chosen instead. Although IKE is | protocol for IPsec, but IKE was chosen instead. Although IKE is | |||
| mandatory for an IPsec implementation, the use of SKIP is not | mandatory for an IPsec implementation, the use of SKIP is not | |||
| excluded. | excluded. | |||
| SKIP uses the Diffie-Hellman algorithm (or could use another key | SKIP uses the Diffie-Hellman algorithm (or could use another key- | |||
| agreement algorithm) to generate a key-encrypting key for use | agreement algorithm) to generate a key-encrypting key for use | |||
| between two entities. A session key is used with a symmetric | between two entities. A session key is used with a symmetric | |||
| algorithm to encrypt data in one or more IP packets that are to be | algorithm to encrypt data in one or more IP packets that are to be | |||
| sent from one entity to the other. A symmetric KEK is established | sent from one entity to the other. A symmetric KEK is established | |||
| and used to encrypt the session key, and the encrypted session key | and used to encrypt the session key, and the encrypted session key | |||
| is placed in a SKIP header that is added to each IP packet that is | is placed in a SKIP header that is added to each IP packet that is | |||
| encrypted with that session key. | encrypted with that session key. | |||
| $ Simple Mail Transfer Protocol (SMTP) | $ Simple Mail Transfer Protocol (SMTP) | |||
| (I) A TCP-based, application-level, Internet Standard protocol | (I) A TCP-based, Application-Layer, Internet Standard protocol | |||
| (RFC 821) for moving electronic mail messages from one computer to | (RFC 821) for moving electronic mail messages from one computer to | |||
| another. | another. | |||
| $ Simple Network Management Protocol (SNMP) | $ Simple Network Management Protocol (SNMP) | |||
| (I) A TCP-based, application-level, Internet Standard protocol | (I) A TCP-based, Application-Layer, Internet Standard protocol | |||
| [R2570, R2574] for conveying management information between | [R3410, R3414] for conveying management information between system | |||
| managers and agents. | components that act as managers and agents. | |||
| $ Simple Public Key Infrastructure (SPKI) | $ Simple Public Key Infrastructure (SPKI) | |||
| (I) A set of experimental concepts (RFCs 2692, 2693) that were | (I) A set of experimental concepts (RFCs 2692, 2693) that were | |||
| proposed as alternatives to the concepts standardized in PKIX. | proposed as alternatives to the concepts standardized in PKIX. | |||
| $ simple security property | $ simple security property | |||
| (N) /formal model/ Property of a system whereby a subject has | (N) /formal model/ Property of a system whereby a subject has | |||
| read access to an object only if the clearance of the subject | read access to an object only if the clearance of the subject | |||
| dominates the classification of the object. See: Bell-LaPadula | dominates the classification of the object. See: Bell-LaPadula | |||
| model. | model. | |||
| skipping to change at page 231, line 38 ¶ | skipping to change at page 247, line 45 ¶ | |||
| Tutorial: In a single sign-on system, a user typically logs in | Tutorial: In a single sign-on system, a user typically logs in | |||
| just once, and then is transparently granted access to a set of | just once, and then is transparently granted access to a set of | |||
| system resources with no further login being required (unless, of | system resources with no further login being required (unless, of | |||
| course, the user logs out). Such a system has the advantages of | course, the user logs out). Such a system has the advantages of | |||
| being user friendly and enabling authentication to be managed | being user friendly and enabling authentication to be managed | |||
| consistently across an entire enterprise. Such a system also has | consistently across an entire enterprise. Such a system also has | |||
| the disadvantage of requiring all hosts and applications to trust | the disadvantage of requiring all hosts and applications to trust | |||
| the same authentication information. | the same authentication information. | |||
| $ singular identity | $ singular identity | |||
| (I) See: (secondary definition under) identity. | (I) See: secondary definition under "identity". | |||
| $ site | $ site | |||
| (I) A facility--i.e., a physical space, room, or building together | (I) A facility -- i.e., a physical space, room, or building | |||
| with its physical, personnel, administrative, and other | together with its physical, personnel, administrative, and other | |||
| safeguards--in which system functions are performed. (See: node.) | safeguards -- in which system functions are performed. (See: | |||
| node.) | ||||
| $ situation | $ situation | |||
| See: security situation. | (I) See: security situation. | |||
| $ SKEME | $ SKEME | |||
| (I) A key distribution protocol from which features were adapted | (I) A key-distribution protocol from which features were adapted | |||
| for IKE. [SKEME] | for IKE. [SKEME] | |||
| $ SKIP | $ SKIP | |||
| (I) See: Simple Key-management for IP. | (I) See: Simple Key Management for Internet Protocols. | |||
| $ SKIPJACK | $ SKIPJACK | |||
| (N) A type 2 block cipher [SKIP, R2773] with a block size of 64 | (N) A type 2, 64-bit block cipher [SKIP, R2773] with a key size of | |||
| bits and a key size of 80 bits. (See: CAPSTONE, CLIPPER, FORTEZZA, | 80 bits. (See: CAPSTONE, CLIPPER, FORTEZZA, Key Exchange | |||
| Key Exchange Algorithm.) | Algorithm.) | |||
| Tutorial: SKIPJACK was developed by NSA and formerly classified at | Tutorial: SKIPJACK was developed by NSA and formerly classified at | |||
| the U.S. DoD "Secret" level. On 23 June 1998, NSA announced that | the U.S. DoD "Secret" level. On 23 June 1998, NSA announced that | |||
| SKIPJACK had been declassified. | SKIPJACK had been declassified. | |||
| $ slot | $ slot | |||
| (O) /MISSI/ One of the FORTEZZA PC card storage areas that are | (O) /MISSI/ One of the FORTEZZA PC card storage areas that are | |||
| each able to hold an X.509 certificate plus other data, such as | each able to hold an X.509 certificate plus other data, including | |||
| the private key that is associated with a public-key certificate. | the private key that is associated with a public-key certificate. | |||
| $ smart card | $ smart card | |||
| (I) A credit-card sized device containing one or more integrated | (I) A credit-card sized device containing one or more integrated | |||
| circuit chips, which perform the functions of a computer's central | circuit chips, which perform the functions of a computer's central | |||
| processor, memory, and input/output interface. (See: PC card.) | processor, memory, and input/output interface. (See: PC card, | |||
| smart token.) | ||||
| Usage: Sometimes this term is used rather strictly to mean a card | Usage: Sometimes this term is used rather strictly to mean a card | |||
| that closely conforms to the dimensions and appearance of the kind | that closely conforms to the dimensions and appearance of the kind | |||
| of plastic credit card issued by banks and merchants. At other | of plastic credit card issued by banks and merchants. At other | |||
| times, the term is used loosely to include cards that are larger | times, the term is used loosely to include cards that are larger | |||
| than credit cards, especially cards that are thicker, such as PC | than credit cards, especially cards that are thicker, such as PC | |||
| cards. | cards. | |||
| Tutorial: A "smart token" is a device that conforms to the | ||||
| definition of smart card except that rather than having standard | ||||
| credit card dimensions, the token is packaged in some other form, | ||||
| such as a dog tag or door key shape. | ||||
| $ smart token | $ smart token | |||
| See: (secondary definition under) smart card. | (I) A device that conforms to the definition of "smart card" | |||
| except that rather than having the standard dimensions of a credit | ||||
| card, the token is packaged in some other form, such as a military | ||||
| dog tag or a door key. (See: smart card, cryptographic token.) | ||||
| $ SMI | $ SMI | |||
| (I) See: security management infrastructure. | (I) See: security management infrastructure. | |||
| $ SMTP | $ SMTP | |||
| (I) See: Simple Mail Transfer Protocol. | (I) See: Simple Mail Transfer Protocol. | |||
| $ smurf attack | $ smurf attack | |||
| (D) A denial-of-service attack that uses IP broadcast addressing | (D) /slang/ A denial-of-service attack that uses IP broadcast | |||
| to send ICMP ping packets with the intent of flooding a system. | addressing to send ICMP ping packets with the intent of flooding a | |||
| (See: ICMP flood.) | system. (See: ICMP flood.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term. It is not listed | Deprecated Term: ISDs SHOULD NOT use this term. It is not listed | |||
| in most dictionaries, and it is likely that other cultures have | in most English dictionaries, and other cultures are likely to use | |||
| different metaphors for this concept. (The Smurfs are a fictional | different metaphors for this concept. | |||
| race of many small blue creatures that were created by a | ||||
| cartoonist. Perhaps the inventor of this attack thought that a | Derivation: The Smurfs are a fictional race of many small, blue | |||
| swarm of ping packets resembled a group of smurfs.) (See: | creatures that were created by a cartoonist. Perhaps the inventor | |||
| (Deprecated Usage under) Green Book.) | of this attack thought that a swarm of ping packets resembled a | |||
| gang of smurfs. (See: Deprecated Usage under "Green Book".) | ||||
| Tutorial: The attacker sends ICMP echo request ("ping") packets | Tutorial: The attacker sends ICMP echo request ("ping") packets | |||
| that appear to originate not from the attacker's own IP address, | that appear to originate not from the attacker's own IP address, | |||
| but from the address of the host or router that is target of the | but from the address of the host or router that is the target of | |||
| attack. Each packet is addressed to an IP broadcast address, e.g., | the attack. Each packet is addressed to an IP broadcast address, | |||
| to all IP addresses in a given network. Thus, each echo request | e.g., to all IP addresses in a given network. Thus, each echo | |||
| that is sent by the attacker results in many echo responses being | request that is sent by the attacker results in many echo | |||
| sent to the target address. This attack can disrupt service at a | responses being sent to the target address. This attack can | |||
| particular host, at the hosts that depend on a particular router, | disrupt service at a particular host, at the hosts that depend on | |||
| or in an entire network. | a particular router, or in an entire network. | |||
| $ sneaker net | $ sneaker net | |||
| (D) A process that transfers data between systems only manually, | (D) /slang/ A process that transfers data between systems only | |||
| under human control; i.e., a data transfer process that involves | manually, under human control; i.e., a data transfer process that | |||
| an air gap. | involves an air gap. | |||
| Deprecated Term: ISDs SHOULD NOT use this term. It is not listed | Deprecated Term: ISDs SHOULD NOT use this term. It is not listed | |||
| in most dictionaries, and it is likely that other cultures have | in most English dictionaries, and other cultures are likely to use | |||
| different metaphors for this concept. | different metaphors for this concept. | |||
| $ Snefru | $ Snefru | |||
| (N) A public-domain, cryptographic hash function (also called "The | (N) A public-domain, cryptographic hash function (also called "The | |||
| Xerox Secure Hash Function") designed by Ralph C. Merkle at Xerox | Xerox Secure Hash Function") designed by Ralph C. Merkle at Xerox | |||
| Corporation. Snefru can produce either a 128-bit or 256-bit output | Corporation. Snefru can produce either a 128-bit or 256-bit output | |||
| (i.e., hash result). [Schn] (See: Khafre, Khufu.) | (i.e., hash result). [Schn] (See: Khafre, Khufu.) | |||
| $ sniffing | $ sniffing | |||
| (D) Synonym for "passive wiretapping". (See: password sniffing.) | (D) /slang/ Synonym for "passive wiretapping". (See: password | |||
| sniffing.) | ||||
| Deprecated Term: ISDs SHOULD NOT use this term; it unnecessarily | Deprecated Term: ISDs SHOULD NOT use this term; it unnecessarily | |||
| duplicates the meaning of a term that is better established. (See: | duplicates the meaning of a term that is better established. (See: | |||
| (Deprecated Usage under) Green Book. | Deprecated Usage under "Green Book". | |||
| $ SNMP | $ SNMP | |||
| (I) See: Simple Network Management Protocol. | (I) See: Simple Network Management Protocol. | |||
| $ social engineering | $ social engineering | |||
| (D) A euphemism for non-technical or low-technology methods used | (D) A euphemism for non-technical or low-technology methods, often | |||
| to attack information systems. | involving trickery or fraud, that are used to attack information | |||
| systems. | ||||
| Deprecated Term: ISDs SHOULD NOT use this term; it is too vague. | Deprecated Term: ISDs SHOULD NOT use this term; it is too vague. | |||
| Instead, use a term that is specific with regard to the means of | Instead, use a term that is specific with regard to the means of | |||
| attack, e.g., lies, impersonation, tricks, bribes, blackmail, and | attack, e.g., blackmail, bribery, coercion, impersonation, | |||
| threats. | intimidation, lying, or theft. | |||
| $ SOCKS | $ SOCKS | |||
| (I) An Internet protocol [R1928] that provides a generalized proxy | (I) An Internet protocol [R1928] that provides a generalized proxy | |||
| server that enables client-server applications -- such as TELNET, | server that enables client-server applications (e.g., TELNET, FTP, | |||
| FTP, and HTTP; running over either TCP or UDP -- to use the | or HTTP; running over either TCP or UDP) to use the services of a | |||
| services of a firewall. | firewall. | |||
| Tutorial: SOCKS is layered under the IPS application layer and | Tutorial: SOCKS is layered under the IPS Application Layer and | |||
| above the transport layer. When a client inside a firewall wishes | above the Transport Layer. When a client inside a firewall wishes | |||
| to establish a connection to an object that is reachable only | to establish a connection to an object that is reachable only | |||
| through the firewall, it uses TCP to connect to the SOCKS server, | through the firewall, it uses TCP to connect to the SOCKS server, | |||
| negotiates with the server for the authentication method to be | negotiates with the server for the authentication method to be | |||
| used, authenticates with the chosen method, and then sends a relay | used, authenticates with the chosen method, and then sends a relay | |||
| request. The SOCKS server evaluates the request, typically based | request. The SOCKS server evaluates the request, typically based | |||
| on source and destination addresses, and either establishes the | on source and destination addresses, and either establishes the | |||
| appropriate connection or denies it. | appropriate connection or denies it. | |||
| $ soft TEMPEST | $ soft TEMPEST | |||
| (O) The use of software techniques to reduce the radio frequency | (O) The use of software techniques to reduce the radio frequency | |||
| information leakage from computer displays and keyboards. [Kuhn] | information leakage from computer displays and keyboards. [Kuhn] | |||
| (See: TEMPEST.) | (See: TEMPEST.) | |||
| $ software | $ software | |||
| (I) Computer programs (which are stored in and executed by | (I) Computer programs (which are stored in and executed by | |||
| computer hardware) and associated data (which also is stored in | computer hardware) and associated data (which also is stored in | |||
| the hardware) that may be dynamically written or modified during | the hardware) that may be dynamically written or modified during | |||
| execution. (See: firmware, hardware.) | execution. (Compare: firmware.) | |||
| $ SORA | $ SORA | |||
| (O) See: SSO-PIN ORA. | (O) See: SSO-PIN ORA. | |||
| $ source authentication | $ source authentication | |||
| (D) Deprecated Term: ISDs SHOULD NOT use this term; it is | (D) Synonym for "data origin authentication" or "peer entity | |||
| ambiguous. If the intent is to authenticate the original creator | authentication". (See: data origin authentication, peer entity | |||
| or packager of data received, then say "data origin | authentication). | |||
| authentication". If the intent is to authenticate the identity of | ||||
| the sender of data, then say "peer entity authentication". (See: | Deprecated Term: ISDs SHOULD NOT use this term because it is | |||
| data origin authentication, peer entity authentication). | ambiguous and, in either meaning, duplicates the meaning of | |||
| internationally standardized terms. If the intent is to | ||||
| authenticate the original creator or packager of data received, | ||||
| then use "data origin authentication". If the intent is to | ||||
| authenticate the identity of the sender of data in the current | ||||
| instance, then use "peer entity authentication". | ||||
| $ source integrity | $ source integrity | |||
| (I) The degree of confidence that can be placed in information | (I) The property that data is trustworthy (i.e., worthy of | |||
| based on the trustworthiness of its sources. (See: integrity.) | reliance or trust), based on the trustworthiness of its sources | |||
| and the trustworthiness of any procedures used for handling data | ||||
| in the system. Usage: a.k.a. Biba integrity. (See: integrity. | ||||
| Compare: correctness integrity, data integrity.) | ||||
| Tutorial: For this kind of integrity, there are formal models of | ||||
| unauthorized modification (see: Biba model) that logically | ||||
| complement the more familiar models of unauthorized disclosure | ||||
| (see: Bell-LaPadula model). In these models, objects are labeled | ||||
| to indicate the credibility of the data they contain, and there | ||||
| are rules for access control that depend on the labels. | ||||
| $ SP3 | $ SP3 | |||
| (O) See: Security Protocol 3. | (O) See: Security Protocol 3. | |||
| $ SP4 | $ SP4 | |||
| (O) See: Security Protocol 4. | (O) See: Security Protocol 4. | |||
| $ spam, SPAM(trademark) | $ spam | |||
| 1a. (I) /verb/ To indiscriminately send unsolicited, unwanted, | 1a. (I) /slang verb/ To indiscriminately send unsolicited, | |||
| irrelevant, or inappropriate messages, especially commercial | unwanted, irrelevant, or inappropriate messages, especially | |||
| advertising in mass quantities. | commercial advertising in mass quantities. | |||
| 1b. (I) /noun/ Electronic "junk mail". [R2635] | 1b. (I) /slang noun/ Electronic "junk mail". [R2635] | |||
| Deprecated Usage: ISDs SHOULD NOT use this term in upper-case | Deprecated Usage: ISDs SHOULD NOT use this term in upper-case | |||
| letters, because SPAM(trademark) is a trademark of Hormel Foods | letters, because SPAM(trademark) is a trademark of Hormel Foods | |||
| Corporation. Hormel says, "We do not object to use of this slang | Corporation. Hormel says, "We do not object to use of this slang | |||
| term [spam] to describe [unsolicited advertising email], although | term [spam] to describe [unsolicited advertising email], although | |||
| we do object to the use of our product image in association with | we do object to the use of our product image in association with | |||
| that term. Also, if the term is to be used, it should be used in | that term. Also, if the term is to be used, it SHOULD be used in | |||
| all lower-case letters to distinguish it from our trademark SPAM, | all lower-case letters to distinguish it from our trademark SPAM, | |||
| which should be used with all uppercase letters." (See: metadata.) | which SHOULD be used with all uppercase letters." (See: metadata.) | |||
| Tutorial: In sufficient volume, spam can cause denial of service. | Tutorial: In sufficient volume, spam can cause denial of service. | |||
| (See: flooding.) According to Hormel, the term was adopted as a | (See: flooding.) According to Hormel, the term was adopted as a | |||
| result of a Monty Python skit in which a group of Vikings sang a | result of a Monty Python skit in which a group of Vikings sang a | |||
| chorus of 'SPAM, SPAM, SPAM ...' in an increasing crescendo, | chorus of 'SPAM, SPAM, SPAM ...' in an increasing crescendo, | |||
| drowning out other conversation. This lyric became a metaphor for | drowning out other conversation. This lyric became a metaphor for | |||
| the unsolicited advertising messages that threaten to overwhelm | the unsolicited advertising messages that threaten to overwhelm | |||
| other discourse on the Internet. | other discourse on the Internet. | |||
| $ SPD | $ SPD | |||
| (I) See: Security Policy Database. | (I) See: Security Policy Database. | |||
| $ special access program (SAP) | $ special access program (SAP) | |||
| (O) /U.S. Government/ "[A kind of p]rogram [that is] established | (O) /U.S. Government/ "[A kind of p]rogram [that is] established | |||
| for a specific class of classified information [and] that imposes | for a specific class of classified information [and] that imposes | |||
| safeguarding and access requirements that exceed those normally | safeguarding and access requirements that exceed those normally | |||
| required for information at the same classified level." [C4009] | required for information at the same classified level." [C4009] | |||
| (See: formal access approval, SCI.) | ||||
| $ SPI | $ SPI | |||
| (I) See: Security Parameters Index. | (I) See: Security Parameters Index. | |||
| $ SPKI | $ SPKI | |||
| (I) See: Simple Public Key Infrastructure. | (I) See: Simple Public Key Infrastructure. | |||
| $ split key | $ split key | |||
| (I) A cryptographic key that is divided into two or more separate | (I) A cryptographic key that is generated and distributed as two | |||
| data items that individually convey no knowledge of the whole key | or more separate data items that individually convey no knowledge | |||
| that results from combining the items. (See: dual control, split | of the whole key that results from combining the items. (See: dual | |||
| knowledge.) | control, split knowledge.) | |||
| $ split knowledge | $ split knowledge | |||
| 1. (I) A security technique in which two or more entities | 1. (I) A security technique in which two or more entities | |||
| separately hold data items that individually convey no knowledge | separately hold data items that individually do not convey | |||
| of the information that results from combining the items. (See: | knowledge of the information that results from combining the | |||
| dual control, split key.) | items. (See: dual control, split key.) | |||
| 2. (O) "A condition under which two or more entities separately | 2. (O) "A condition under which two or more entities separately | |||
| have key components which individually convey no knowledge of the | have key components which individually convey no knowledge of the | |||
| plaintext key which will be produced when the key components are | plaintext key which will be produced when the key components are | |||
| combined in the cryptographic module." [FP140] | combined in the cryptographic module." [FP140] | |||
| $ spoofing attack | $ spoofing attack | |||
| (I) Synonym for "masquerade attack". | (I) Synonym for "masquerade attack". | |||
| $ spread spectrum | $ spread spectrum | |||
| 1. (N) A TRANSEC technique that transmits a signal in a bandwidth | (N) A TRANSEC technique that transmits a signal in a bandwidth | |||
| much greater than the transmitted information needs. [F1037] | much greater than the transmitted information needs. [F1037] | |||
| Example: frequency hopping. | Example: frequency hopping. | |||
| Tutorial: Usually uses a sequential noise-like signal structure to | Tutorial: Usually uses a sequential, noise-like signal structure | |||
| spread the normally narrowband information signal over a | to spread the normally narrowband information signal over a | |||
| relatively wide band of frequencies. The receiver correlates the | relatively wide band of frequencies. The receiver correlates the | |||
| signals to retrieve the original information signal. This | signals to retrieve the original information signal. This | |||
| technique decreases potential interference to other receivers, | technique decreases potential interference to other receivers, | |||
| while achieving data confidentiality and increasing immunity of | while achieving data confidentiality and increasing immunity of | |||
| spread spectrum receivers to noise and interference. | spread spectrum receivers to noise and interference. | |||
| $ spyware | $ spyware | |||
| (I) Software that an intruder has installed surreptitiously on a | (D) /slang/ Software that an intruder has installed | |||
| networked computer to gather data from that computer and send it | surreptitiously on a networked computer to gather data from that | |||
| through the network to the intruder or some other interested | computer and send it through the network to the intruder or some | |||
| party. (See: malicious logic, Trojan horse.) | other interested party. (See: malicious logic, Trojan horse.) | |||
| Deprecated Usage: The term is used in many ways and could easily | Deprecated Usage: ISDs that use this term SHOULD state a | |||
| be misunderstood; therefore, ISDs that use this term SHOULD state | definition for it because the term is used in many ways and could | |||
| a definition for it. | easily be misunderstood. | |||
| Tutorial: Some examples of the types of data that might be | Tutorial: Some examples of the types of data that might be | |||
| gathered by spyware are application files, passwords, email | gathered by spyware are application files, passwords, email | |||
| addresses, usage histories, and keystrokes. Some examples of | addresses, usage histories, and keystrokes. Some examples of | |||
| motivations for gathering the data are blackmail, financial fraud, | motivations for gathering the data are blackmail, financial fraud, | |||
| identity theft, industrial espionage, market research, and | identity theft, industrial espionage, market research, and | |||
| voyeurism. | voyeurism. | |||
| $ SSH(trademark) | $ SSH(trademark) | |||
| (N) See: Secure Shell(trademark). | (N) See: Secure Shell(trademark). | |||
| skipping to change at page 237, line 14 ¶ | skipping to change at page 253, line 41 ¶ | |||
| including security management, (b) Secure Data Exchange protocol, | including security management, (b) Secure Data Exchange protocol, | |||
| (c) Key Management, (d) [has been incorporated in (a)], (e) SDE | (c) Key Management, (d) [has been incorporated in (a)], (e) SDE | |||
| Over Ethernet 2.0, (f) SDE Sublayer Management, (g) SDE Security | Over Ethernet 2.0, (f) SDE Sublayer Management, (g) SDE Security | |||
| Labels, and (h) SDE PICS Conformance. Parts b, e, f, g, and h are | Labels, and (h) SDE PICS Conformance. Parts b, e, f, g, and h are | |||
| incorporated in IEEE Standard 802.10-1998. | incorporated in IEEE Standard 802.10-1998. | |||
| $ star property | $ star property | |||
| (N) See: *-property. | (N) See: *-property. | |||
| $ Star Trek attack | $ Star Trek attack | |||
| (D) An attack that penetrates your system where no attack has ever | (D) /slang/ An attack that penetrates your system where no attack | |||
| gone before. | has ever gone before. | |||
| Deprecated Usage: This is a joke for Trekkies. (See: (Deprecated | Deprecated Usage: This is a joke for Trekkies. (See: Deprecated | |||
| Usage under) Green Book.) | Usage under "Green Book".) | |||
| $ static | $ static | |||
| (I) /adjective/ Refers to a cryptographic key or other parameter | (I) /adjective/ Refers to a cryptographic key or other parameter | |||
| that is relatively long-lived. (Compare: ephemeral.) | that is relatively long-lived. (Compare: ephemeral.) | |||
| $ steganography | $ steganography | |||
| (I) Methods of hiding the existence of a message or other data. | (I) Methods of hiding the existence of a message or other data. | |||
| This is different than cryptography, which hides the meaning in a | This is different than cryptography, which hides the meaning of a | |||
| message but does not hide the message itself. Example: "Invisible" | message but does not hide the message itself. Examples: For | |||
| ink. (See: cryptology. Compare: digital watermarking.) | classic, physical methods, see [Kahn]; for modern, digital | |||
| methods, see [John]. (See: cryptology. Compare: digital | ||||
| watermarking.) | ||||
| $ storage channel | $ storage channel | |||
| See: covert storage channel. | (I) See: covert storage channel. | |||
| $ storage key | ||||
| (I) A cryptographic key used by a device for protecting | ||||
| information that is being maintained in the device, as opposed to | ||||
| protecting information that is being transmitted between devices. | ||||
| (See: cryptographic token, token copy. Compare: traffic key.) | ||||
| $ stream cipher | $ stream cipher | |||
| (I) An encryption algorithm that breaks plain text into a stream | (I) An encryption algorithm that breaks plain text into a stream | |||
| of successive elements (usually, bits) and encrypts the n-th | of successive elements (usually, bits) and encrypts the n-th | |||
| plaintext element with the n-th element of a parallel key stream, | plaintext element with the n-th element of a parallel key stream, | |||
| thus converting the plaintext stream into a ciphertext stream. | thus converting the plaintext stream into a ciphertext stream. | |||
| [Schn] (See: block cipher.) | [Schn] (See: block cipher.) | |||
| $ stream integrity service | ||||
| (I) A data integrity service that preserves integrity for a | ||||
| sequence of data packets, including both (a) bit-by-bit datagram | ||||
| integrity of each individual packet in the set and (b) packet-by- | ||||
| packet sequential integrity of the set as a whole. (See: data | ||||
| integrity. Compare: datagram integrity service.) | ||||
| Tutorial: Some internet applications need only datagram integrity, | ||||
| but others require that an entire stream of packets be protected | ||||
| against insertion, reordering, deletion, and delay: | ||||
| - "Insertion": The destination receives an additional packet that | ||||
| was not sent by the source. | ||||
| - "Reordering": The destination receives packets in a different | ||||
| order than that in which they were sent by the source. | ||||
| - "Deletion": A packet sent by the source is not ever delivered | ||||
| to the intended destination. | ||||
| - "Delay": A packet is detained for some period of time at a | ||||
| relay, thus hampering and postponing the packet's normal timely | ||||
| delivery from source to destination. | ||||
| $ strength | $ strength | |||
| (I) /COMPUSEC/ A rating of effectiveness of a security mechanism, | 1. (I) /cryptography/ A cryptographic mechanism's level of | |||
| stated in terms of the minimum effort believed to be needed to | resistance to attacks [R3776]. | |||
| defeat the mechanism. (See: entropy, strong, work factor.) | ||||
| $ strength of function | 2. (N) /Common Criteria/ "Strength of function" is a | |||
| (N) /Common Criteria/ "A qualification of a TOE security function | "qualification of a TOE security function expressing the minimum | |||
| expressing the minimum efforts assumed necessary to defeat its | efforts assumed necessary to defeat its expected security behavior | |||
| expected security behavior by directly attacking its underlying | by directly attacking its underlying security mechanisms": (See: | |||
| security mechanisms": (See: strength, strong.) | strong.) | |||
| - Basic: "A level of the TOE strength of function where analysis | - Basic: "A level of the TOE strength of function where analysis | |||
| shows that the function provides adequate protection against | shows that the function provides adequate protection against | |||
| casual breach of TOE security by attackers possessing a low | casual breach of TOE security by attackers possessing a low | |||
| attack potential." | attack potential." | |||
| - Medium: "... against straightforward or intentional breach ... | - Medium: "... against straightforward or intentional breach ... | |||
| by attackers possessing a moderate attack potential. | by attackers possessing a moderate attack potential. | |||
| - High: "... against deliberately planned or organized breach ... | - High: "... against deliberately planned or organized breach ... | |||
| by attackers possessing a high attack potential." | by attackers possessing a high attack potential." | |||
| $ strong | $ strong | |||
| 1. (I) /COMPUSEC/ Used to describe a security mechanism that would | 1. (I) /cryptography/ Used to describe a cryptographic algorithm | |||
| be difficult to defeat. (See: strength.) | ||||
| 2. (I) /cryptography/ Used to describe a cryptographic algorithm | ||||
| that would require a large amount of computational power to defeat | that would require a large amount of computational power to defeat | |||
| it. (See: work factor.) | it. (See: work factor, strength.) | |||
| 2. (I) /COMPUSEC/ Used to describe a security mechanism that would | ||||
| be difficult to defeat. (See: strength.) | ||||
| $ strong authentication | $ strong authentication | |||
| 1. (I) An authentication process that uses a cryptographic | 1. (I) An authentication process that uses a cryptographic | |||
| security mechanism -- particularly public-key certificates -- to | security mechanism -- particularly public-key certificates -- to | |||
| verify the identity claimed for an entity. (Compare: simple | verify the identity claimed for an entity. (Compare: simple | |||
| authentication.) | authentication.) | |||
| 2. (O) "Authentication by means of cryptographically derived | 2. (O) "Authentication by means of cryptographically derived | |||
| credentials." [X509] | credentials." [X509] | |||
| skipping to change at page 239, line 36 ¶ | skipping to change at page 256, line 36 ¶ | |||
| OU=Treasurer, CN=DukePinchpenny> is subordinate to the DN | OU=Treasurer, CN=DukePinchpenny> is subordinate to the DN | |||
| <C=FooLand, O=Gov, CN=KingFooCA>. | <C=FooLand, O=Gov, CN=KingFooCA>. | |||
| $ subscriber | $ subscriber | |||
| (I) /PKI/ A user that is registered in a PKI and, therefore, can | (I) /PKI/ A user that is registered in a PKI and, therefore, can | |||
| be named in the "subject" field of a certificate issued by a CA in | be named in the "subject" field of a certificate issued by a CA in | |||
| that PKI. (See: registration, user.) | that PKI. (See: registration, user.) | |||
| Usage: This term is needed to distinguish registered users from | Usage: This term is needed to distinguish registered users from | |||
| two other kinds of PKI users: | two other kinds of PKI users: | |||
| - Users that access the PKI but are not identified to it. For | - Users that access the PKI but are not identified to it: For | |||
| example a relying party may access a PKI repository to obtain | example a relying party may access a PKI repository to obtain | |||
| the certificate of some other party. (See: access) | the certificate of some other party. (See: access.) | |||
| - Users that does not access the PKI. For example, a relying | - Users that do not access the PKI: For example, a relying party | |||
| party (see: certificate user) may use a digital certificate | (see: certificate user) may use a digital certificate that was | |||
| that was obtained from a database that is not part of the PKI | obtained from a database that is not part of the PKI that | |||
| that issued the certificate. | issued the certificate. | |||
| $ substitution | $ substitution | |||
| (I) /cryptography/ A method of encryption in which elements of the | (I) /cryptography/ A method of encryption in which elements of the | |||
| plain text retain their original sequence but are replaced by | plain text retain their original sequence but are replaced by | |||
| other elements. (Compare: transposition.) | other elements. (Compare: transposition.) | |||
| $ subsystem | $ subsystem | |||
| (I) A collection of related system components that together | (I) A collection of related system components that together | |||
| perform a system function or deliver a system service. | perform a system function or deliver a system service. | |||
| $ superuser | ||||
| (I) /UNIX/ Synonym for "root". | ||||
| $ superencryption | $ superencryption | |||
| (I) An encryption operation for which the plaintext input to be | (I) An encryption operation for which the plaintext input to be | |||
| transformed is the ciphertext output of a previous encryption | transformed is the ciphertext output of a previous encryption | |||
| operation. (Compare: hybrid encryption.) | operation. (Compare: hybrid encryption.) | |||
| $ survivability | $ survivability | |||
| (I) The ability of a system to remain in operation or existence | (I) The ability of a system to remain in operation or existence | |||
| despite adverse conditions, including both natural occurrences, | despite adverse conditions, including natural occurrences, | |||
| accidental actions, and attacks on the system. (Compare: | accidental actions, and attacks. (Compare: availability, | |||
| availability, reliability.) | reliability.) | |||
| $ swIPe | $ swIPe | |||
| (I) An encryption protocol for IP that provides confidentiality, | (I) An encryption protocol for IP that provides confidentiality, | |||
| integrity, and authentication and can be used for both end-to-end | integrity, and authentication and can be used for both end-to-end | |||
| and intermediate-hop security. [Ioan] (Compare: IPsec.) | and intermediate-hop security. [Ioan] (Compare: IPsec.) | |||
| Tutorial: The swIPe protocol is an IP predecessor that is | Tutorial: The swIPe protocol is an IP predecessor that is | |||
| concerned only with encryption mechanisms; policy and key | concerned only with encryption mechanisms; policy and key | |||
| management are handled outside the protocol. | management are handled outside the protocol. | |||
| skipping to change at page 240, line 42 ¶ | skipping to change at page 257, line 47 ¶ | |||
| Tutorial: Symmetric cryptography has been used for thousands of | Tutorial: Symmetric cryptography has been used for thousands of | |||
| years [Kahn]. A modern example is AES. | years [Kahn]. A modern example is AES. | |||
| Symmetric cryptography has a disadvantage compared to asymmetric | Symmetric cryptography has a disadvantage compared to asymmetric | |||
| cryptography with regard to key distribution. For example, when | cryptography with regard to key distribution. For example, when | |||
| Alice wants to ensure confidentiality for data she sends to Bob, | Alice wants to ensure confidentiality for data she sends to Bob, | |||
| she encrypts the data with a key, and Bob uses the same key to | she encrypts the data with a key, and Bob uses the same key to | |||
| decrypt. However, keeping the shared key secret entails both cost | decrypt. However, keeping the shared key secret entails both cost | |||
| and risk when the key is distributed to both Alice and Bob. (See: | and risk when the key is distributed to both Alice and Bob. (See: | |||
| key management system.) | key distribution, key management.) | |||
| $ symmetric key | $ symmetric key | |||
| (I) A cryptographic key that is used in a symmetric cryptographic | (I) A cryptographic key that is used in a symmetric cryptographic | |||
| algorithm. (See: symmetric cryptography.) | algorithm. (See: symmetric cryptography.) | |||
| $ SYN flood | $ SYN flood | |||
| (I) A denial-of-service attack that sends a large number of TCP | (I) A denial-of-service attack that sends a large number of TCP | |||
| SYN (synchronize) packets to a host with the intent of disrupting | SYN (synchronize) packets to a host with the intent of disrupting | |||
| the operation of that host. (See: flooding.) | the operation of that host. (See: flooding.) | |||
| Tutorial: This attack seeks to exploit a vulnerability in the TCP | Tutorial: This attack seeks to exploit a vulnerability in the TCP | |||
| specification or in a TCP implementation. Normally, two hosts use | specification or in a TCP implementation. Normally, two hosts use | |||
| a three-way exchange of packets to establish a TCP connection: (a) | a three-way exchange of packets to establish a TCP connection: (a) | |||
| host 1 requests a connection by sending a SYN packet to host 2; | host 1 requests a connection by sending a SYN packet to host 2; | |||
| (b) host 2 replies by sending a SYN-ACK (acknowledgement) packet | (b) host 2 replies by sending a SYN-ACK (acknowledgement) packet | |||
| to host 1; and (c) host 1 completes the connection by sending an | to host 1; and (c) host 1 completes the connection by sending an | |||
| ACK packet to host 2. To attack host 2, host 1 can send a series | ACK packet to host 2. To attack host 2, host 1 can send a series | |||
| of TCP SYNs, each with a different phony source address. ([R2267] | of TCP SYNs, each with a different phony source address. ([R2827] | |||
| discusses how to use packet filtering to prevent such attacks from | discusses how to use packet filtering to prevent such attacks from | |||
| being launched from behind an Internet service provider's | being launched from behind an Internet service provider's | |||
| aggregation point.) Host 2 treats each SYN as a request from a | aggregation point.) Host 2 treats each SYN as a request from a | |||
| separate host, replies to each with a SYN-ACK, and waits to | separate host, replies to each with a SYN-ACK, and waits to | |||
| receive the matching ACKs. (The attacker can use random or | receive the matching ACKs. (The attacker can use random or | |||
| unreachable sources addresses in the SYN packets, or can use | unreachable sources addresses in the SYN packets, or can use | |||
| source addresses that belong to third parties, that then become | source addresses that belong to third parties, that then become | |||
| secondary victims.) | secondary victims.) | |||
| For each SYN-ACK that is sent, the TCP process in host 2 needs | For each SYN-ACK that is sent, the TCP process in host 2 needs | |||
| some memory space to store state information while waiting for the | some memory space to store state information while waiting for the | |||
| matching ACK to be returned. If the matching ACK never arrives at | matching ACK to be returned. If the matching ACK never arrives at | |||
| host 2, a timer associated with the pending SYN-ACK will | host 2, a timer associated with the pending SYN-ACK will | |||
| eventually expire and release the space. But if host 1 (or a | eventually expire and release the space. But if host 1 (or a | |||
| cooperating group of hosts) can rapidly send many SYNs to host 2, | cooperating group of hosts) can rapidly send many SYNs to host 2, | |||
| host 2 will need to store state information for many pending SYN- | host 2 will need to store state information for many pending SYN- | |||
| ACKs and may run out of space. This can prevent host 2 from | ACKs and may run out of space. This can prevent host 2 from | |||
| responding to legitimate connection requests from other hosts or | responding to legitimate connection requests from other hosts or | |||
| even, if there are flaws in host 2's TCP implementation, crash | even, if there are flaws in host 2's TCP implementation, crash | |||
| when the space is exhausted. | when the available space is exhausted. | |||
| $ synchronization | $ synchronization | |||
| (I) Any technique by which a receiving (decrypting) cryptographic | (I) Any technique by which a receiving (decrypting) cryptographic | |||
| process attains an internal state that matches the transmitting | process attains an internal state that matches the transmitting | |||
| (encrypting) process, i.e., has the appropriate keying material to | (encrypting) process, i.e., has the appropriate keying material to | |||
| process the cipher text and is correctly initialized to do so. | process the cipher text and is correctly initialized to do so. | |||
| $ system | $ system | |||
| Usage: In this Glossary, the term is mainly used as an | Usage: In this Glossary, the term is mainly used as an | |||
| abbreviation for "information system". (See: subsystem.) | abbreviation of "information system". (See: subsystem.) | |||
| $ system architecture | $ system architecture | |||
| (N) The structure of system components, their relationships, and | (N) The structure of system components, their relationships, and | |||
| the principles and guidelines governing their design and evolution | the principles and guidelines governing their design and evolution | |||
| over time. [DoDAF1] (Compare: security architecture.) | over time. [DoDAF1] (Compare: security architecture.) | |||
| $ system component | $ system component | |||
| 1. (I) A collection of system resources that (a) forms a physical | 1. (I) A collection of system resources that (a) forms a physical | |||
| or logical part of the system, (b) has specified functions and | or logical part of the system, (b) has specified functions and | |||
| interfaces, and (c) is treated (e.g., by policies or requirement | interfaces, and (c) is treated (e.g., by policies or | |||
| statements) as existing independently of other parts of the | specifications) as existing independently of other parts of the | |||
| system. (See: subsystem.) | system. (See: subsystem.) | |||
| 2. (O) /ITSEC/ An identifiable and self-contained part of a TOE. | 2. (O) /ITSEC/ An identifiable and self-contained part of a TOE. | |||
| Usage: Component is a relative term because components may be | Usage: Component is a relative term because components may be | |||
| nested; i.e., one component of system may be a part of another | nested; i.e., one component of system may be a part of another | |||
| component of that system. | component of that system. | |||
| Tutorial: Components can be characterized as follows: | Tutorial: Components can be characterized as follows: | |||
| - A "physical component" has mass and takes up space. | - A "physical component" has mass and takes up space. | |||
| - A "logical component" is an abstraction used to manage and | - A "logical component" is an abstraction used to manage and | |||
| coordinate aspects of the physical environment, and typically | coordinate aspects of the physical environment, and typically | |||
| represents a set of states or capabilities of the system. | represents a set of states or capabilities of the system. | |||
| $ system entity | $ system entity | |||
| (I) An active component of a system -- e.g., an automated process | (I) An active component of a system -- e.g., an automated process | |||
| or set of processes (see: subsystem), or a person or set of | or set of processes (see: subsystem), or a person or set of | |||
| persons (e.g., an organization) -- that incorporates a specific | persons (e.g., an organization) -- that incorporates a specific | |||
| set of capabilities. (Compare: subject, user.) | set of capabilities. (Compare: subject, user.) | |||
| $ system high | $ system high | |||
| (I) The highest security level at which a system operates, or is | (I) The highest security level at which a system operates, or is | |||
| capable of operating, at a particular time or in a particular | capable of operating, at a particular time or in a particular | |||
| environment. (See: system high security mode.) | environment. (See: system-high security mode.) | |||
| $ system high security mode | $ system-high security mode | |||
| (I) A mode of operation of an information system, wherein all | (I) A mode of system operation wherein all users having access to | |||
| users having access to the system possess a security clearance or | the system possess all necessary authorizations (both security | |||
| authorization, but not necessarily a need-to-know, for all data | clearance and formal access approval) for all data handled by the | |||
| handled by the system. (See: (system operation) mode.) | system, but some users might not have need-to-know for all the | |||
| data. (See: /system operation/ under "mode", formal access | ||||
| approval, protection level, security clearance.) | ||||
| Usage: This mode was defined formally in U.S. DoD policy that | Usage: Usually abbreviated as "system-high mode". This mode was | |||
| applied to system accreditation [DoD2], but the term is widely | defined in U.S. DoD policy that applied to system accreditation, | |||
| used outside the Defense Department and outside the Government. | but the term is widely used outside the Government. | |||
| $ system integrity | $ system integrity | |||
| (I) "The quality that a system has when it can perform its | (I) "The quality that a system has when it can perform its | |||
| intended function in a unimpaired manner, free from deliberate or | intended function in a unimpaired manner, free from deliberate or | |||
| inadvertent unauthorized manipulation." [NCS04] (See: recovery, | inadvertent unauthorized manipulation." [NCS04] (See: recovery, | |||
| system integrity service.) | system integrity service.) | |||
| $ system integrity service | $ system integrity service | |||
| (I) A security service that protects system resources in a | (I) A security service that protects system resources in a | |||
| verifiable manner against unauthorized or accidental change, loss, | verifiable manner against unauthorized or accidental change, loss, | |||
| or destruction. (See: system integrity.) | or destruction. (See: system integrity.) | |||
| $ system low | $ system low | |||
| (I) The lowest security level supported by a system at a | (I) The lowest security level supported by a system at a | |||
| particular time or in a particular environment. (See: system | particular time or in a particular environment. (Compare: system | |||
| high.) | high.) | |||
| $ system resource | $ system resource | |||
| (I) Data contained in an information system; or a service provided | (I) Data contained in an information system; or a service provided | |||
| by a system; or a system capability, such as processing power or | by a system; or a system capacity, such as processing power or | |||
| communication bandwidth; or an item of system equipment (i.e., | communication bandwidth; or an item of system equipment (i.e., | |||
| hardware, firmware, software, or documentation); or a facility | hardware, firmware, software, or documentation); or a facility | |||
| that houses system operations and equipment. (See: system | that houses system operations and equipment. (See: system | |||
| component.) | component.) | |||
| $ system security officer (SSO) | $ system security officer (SSO) | |||
| (I) A person responsible for enforcement or administration of the | (I) A person responsible for enforcement or administration of the | |||
| security policy that applies to the system. | security policy that applies to a system. | |||
| $ TACACS | $ TACACS | |||
| (I) See: Terminal Access Controller (TAC) Access Control System. | (I) See: Terminal Access Controller (TAC) Access Control System. | |||
| $ TACACS+ | $ TACACS+ | |||
| (I) A TCP-based protocol that improves on TACACS and XTACACS by | (I) A TCP-based protocol that improves on TACACS and XTACACS by | |||
| separating the functions of authentication, authorization, and | separating the functions of authentication, authorization, and | |||
| accounting and by encrypting all traffic between the network | accounting and by encrypting all traffic between the network | |||
| access server and authentication server. TACACS+ is extensible to | access server and authentication server. TACACS+ is extensible to | |||
| allow any authentication mechanism to be used with TACACS+ | allow any authentication mechanism to be used with TACACS+ | |||
| clients. (See: TACACS, XTACACS.) | clients. (See: TACACS, XTACACS.) | |||
| $ tamper | $ tamper | |||
| (I) Make an unauthorized modification in a system that alters the | (I) Make an unauthorized modification in a system that alters the | |||
| system's functioning in a way that degrades the security services | system's functioning in a way that degrades the security services | |||
| that the system was intended to provide. (See: QUADRANT. Compare: | that the system was intended to provide. (See: QUADRANT. Compare: | |||
| (secondary definitions under) "corruption" and "misuse".) | secondary definitions under "corruption" and "misuse".) | |||
| $ tamper-evident | $ tamper-evident | |||
| (I) A characteristic of a system component that provides evidence | (I) A characteristic of a system component that provides evidence | |||
| that an attack has been attempted on that component or system. | that an attack has been attempted on that component or system. | |||
| Usage: Normally refers to physical evidence. (See: tamper.) | Usage: Usually involves physical evidence. (See: tamper.) | |||
| $ tamper-resistant | $ tamper-resistant | |||
| (I) A characteristic of a system component that provides passive | (I) A characteristic of a system component that provides passive | |||
| protection against an attack. (See: tamper.) | protection against an attack. (See: tamper.) | |||
| Usage: Normally refers to physical means of protection. | Usage: Usually involves physical means of protection. | |||
| $ target of evaluation (TOE) | $ target of evaluation (TOE) | |||
| (N) /Common Criteria/ An information technology product or system | (N) /Common Criteria/ An information technology product or system | |||
| that is the subject of a security evaluation, together with the | that is the subject of a security evaluation, together with the | |||
| product's associated administrator and user documentation. | product's associated administrator and user documentation. | |||
| (Compare: protection profile.) | ||||
| Tutorial: The security characteristics of the target of evaluation | Tutorial: The security characteristics of the target of evaluation | |||
| (TOE) are described in specific terms by a corresponding security | (TOE) are described in specific terms by a corresponding security | |||
| target, or in more general terms by a protection profile. In | target, or in more general terms by a protection profile. In | |||
| Common Criteria philosophy, it is important that a TOE be | Common Criteria philosophy, it is important that a TOE be | |||
| evaluated against the specific set of criteria expressed in the | evaluated against the specific set of criteria expressed in the | |||
| security target (ST). This evaluation consists of rigorous | target. This evaluation consists of rigorous analysis and testing | |||
| analysis and testing performed by an accredited, independent | performed by an accredited, independent laboratory. The scope of a | |||
| laboratory. The scope of a TOE evaluation is set by the EAL and | TOE evaluation is set by the EAL and other requirements specified | |||
| other requirements specified in the ST. Part of this process is an | in the target. Part of this process is an evaluation of the target | |||
| evaluation of the ST itself, to ensure that it is correct, | itself, to ensure that it is correct, complete, and internally | |||
| complete, and internally consistent and can be used as the | consistent and can be used as the baseline for the TOE evaluation. | |||
| baseline for the TOE evaluation. | ||||
| $ TCB | $ TCB | |||
| (N) See: trusted computing base. | (N) See: trusted computing base. | |||
| $ TCC field | $ TCC field | |||
| (I) See: Transmission Control Code field. | (I) See: Transmission Control Code field. | |||
| $ TCP | $ TCP | |||
| (I) See: Transmission Control Protocol. | (I) See: Transmission Control Protocol. | |||
| $ TCP/IP | $ TCP/IP | |||
| (I) Synonym for "Internet Protocol Suite", in which the | (I) Synonym for "Internet Protocol Suite". | |||
| Transmission Control Protocol (TCP) and the Internet Protocol (IP) | ||||
| are important parts. | ||||
| $ TCSEC | $ TCSEC | |||
| (N) See: Trusted Computer System Evaluation Criteria. (Compare: | (N) See: Trusted Computer System Evaluation Criteria. (Compare: | |||
| TSEC.) | TSEC.) | |||
| $ TDEA | $ TDEA | |||
| (I) See: Triple Data Encryption Algorithm. | (I) See: Triple Data Encryption Algorithm. | |||
| $ teardrop attack | $ teardrop attack | |||
| (D) An denial-of-service attack that sends improperly formed IP | (D) /slang/ An denial-of-service attack that sends improperly | |||
| packet fragments with the intent of causing the destination system | formed IP packet fragments with the intent of causing the | |||
| to fail. | destination system to fail. | |||
| Deprecated Term: The term is often used imprecisely and could | Deprecated Term: ISDs that use this term SHOULD state a definition | |||
| easily be misunderstood; therefore, ISDs that use this term SHOULD | for it because the term is often used imprecisely and could easily | |||
| state a definition for it. (See: (Deprecated Usage under) Green | be misunderstood. (See: Deprecated Usage under "Green Book".) | |||
| Book.) | ||||
| $ technical non-repudiation | $ technical non-repudiation | |||
| (I) See: (secondary definition under) non-repudiation. | (I) See: (secondary definition under) non-repudiation. | |||
| $ technical security | $ technical security | |||
| (I) Security mechanisms and procedures that are implemented in and | (I) Security mechanisms and procedures that are implemented in and | |||
| executed by hardware, software, or firmware (rather than by | executed by computer hardware, firmware, or software to provide | |||
| people) to provide automated protection for a system. (See: | automated protection for a system. (See: security architecture. | |||
| security architecture. Compare: administrative security.) | Compare: administrative security.) | |||
| $ Telecommunications Security Nomenclature System (TSEC) | $ Telecommunications Security Word System (TSEC) | |||
| (O) An NSA designation system for telecommunication security | (O) /U.S. Government/ A terminology for designating | |||
| equipment. (Compare: TCSEC.) | telecommunication security equipment. (Compare: TCSEC.) | |||
| Tutorial: A TSEC designator has the following parts: | Tutorial: A TSEC designator has the following parts: | |||
| - Prefix "TSEC/" for items and systems, or suffix "/TSEC" for | - Prefix "TSEC/" for items and systems, or suffix "/TSEC" for | |||
| assemblies. (Often omitted when the context is clear.) | assemblies. (Often omitted when the context is clear.) | |||
| - First letter, for function: "C" COMSEC equipment system, "G" | - First letter, for function: "C" COMSEC equipment system, "G" | |||
| general purpose, "K" cryptographic, "H" crypto-ancillary, "M" | general purpose, "K" cryptographic, "H" crypto-ancillary, "M" | |||
| manufacturing, "N" noncryptographic, "S" special purpose. | manufacturing, "N" noncryptographic, "S" special purpose. | |||
| - Second letter, for type or purpose: "G" key generation, "I" | - Second letter, for type or purpose: "G" key generation, "I" | |||
| data transmission, "L" literal conversion, "N" signal | data transmission, "L" literal conversion, "N" signal | |||
| conversion, "O" multipurpose, "P" materials production, "S" | conversion, "O" multipurpose, "P" materials production, "S" | |||
| special purpose, "T" testing or checking, "U" television, "W" | special purpose, "T" testing or checking, "U" television, "W" | |||
| teletypewriter, "X" facsimile, "Y" speech. | teletypewriter, "X" facsimile, "Y" speech. | |||
| - Optional third letter, used only in designations of assemblies, | - Optional third letter, used only in designations of assemblies, | |||
| for type or purpose: "A" advancing, "B" base or cabinet, "C" | for type or purpose: "A" advancing, "B" base or cabinet, "C" | |||
| combining, "D" drawer or panel, "E" strip or chassis, "F" frame | combining, "D" drawer or panel, "E" strip or chassis, "F" frame | |||
| or rack, "G" key generator, "H" keyboard, "I" translator or | or rack, "G" key generator, "H" keyboard, "I" translator or | |||
| reader, "J" speech processing, "K" keying or permuting, "L" | reader, "J" speech processing, "K" keying or permuting, "L" | |||
| repeater, "M" memory or storage, "O" observation, "P" power | repeater, "M" memory or storage, "O" observation, "P" power | |||
| supply or converter, "R" receiver, "S" synchronizing, "T" | supply or converter, "R" receiver, "S" synchronizing, "T" | |||
| transmitter, "U" printer, "V" removable COMSEC component, "W" | transmitter, "U" printer, "V" removable COMSEC component, "W" | |||
| logic programmer/programming, "X" special purpose. | logic programmer/programming, "X" special purpose. | |||
| - Model number, usually two or 3 digits, assigned sequentially | - Model number, usually two or 3 digits, assigned sequentially | |||
| within each letter combination (e.g., KG-34, KG-84). | within each letter combination (e.g., KG-34, KG-84). | |||
| - Optional suffix letter, used to designate a version. First | - Optional suffix letter, used to designate a version. First | |||
| version has no letter, next version has "A" (e.g., KG-84, KG- | version has no letter, next version has "A" (e.g., KG-84, KG- | |||
| 84A), etc. | 84A), etc. | |||
| $ TELNET | $ TELNET | |||
| (I) A TCP-based, application-level, Internet Standard protocol | (I) A TCP-based, Application-Layer, Internet Standard protocol | |||
| (RFC 854) for remote login from one host to another. | (RFC 854) for remote login from one host to another. | |||
| $ TEMPEST | $ TEMPEST | |||
| (N) Short name for technology and methods for protecting against | (N) Short name for technology and methods for protecting against | |||
| data compromise due to electromagnetic emanations from electrical | data compromise due to electromagnetic emanations from electrical | |||
| and electronic equipment. [Russ] (See: inspectable space, soft | and electronic equipment. [Russ] (See: inspectable space, soft | |||
| TEMPEST, TEMPEST zone. Compare: QUADRANT) | TEMPEST, TEMPEST zone. Compare: QUADRANT) | |||
| (O) /U.S. Government/ "Short name referring to investigation, | (O) /U.S. Government/ "Short name referring to investigation, | |||
| study, and control of compromising emanations from IS equipment." | study, and control of compromising emanations from IS equipment." | |||
| [N4009] | [N4009] | |||
| Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for | Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for | |||
| "electromagnetic emanations security"; instead, use EMSEC. Also, | "electromagnetic emanations security"; instead, use EMSEC. Also, | |||
| the term is NOT an acronym for Transient Electromagnetic Pulse | the term is NOT an acronym for Transient Electromagnetic Pulse | |||
| Surveillance Technology. | Surveillance Technology. | |||
| Tutorial: U.S. Government security policy states (a) | Tutorial: The U.S. Federal Government issues security policies | |||
| specifications and standards for techniques to reduce the | that (a) state specifications and standards for techniques to | |||
| strength of emanations from systems and reduce the ability of | reduce the strength of emanations from systems and reduce the | |||
| unauthorized parties to receive and make use of emanations, and | ability of unauthorized parties to receive and make use of | |||
| (b) rules for applying those techniques. Other nations presumably | emanations and (b) state rules for applying those techniques. | |||
| do the same. | Other nations presumably do the same. | |||
| $ TEMPEST zone | $ TEMPEST zone | |||
| (O) "Designated area [i.e., a physical volume] within a facility | (O) "Designated area [i.e., a physical volume] within a facility | |||
| where equipment that has appropriate TEMPEST characteristics ... | where equipment that has appropriate TEMPEST characteristics ... | |||
| may be operated." [C4009] (See: emanation security, TEMPEST. | may be operated." [C4009] (See: emanation security, TEMPEST. | |||
| Compare: inspectable space.) | Compare: inspectable space.) | |||
| Tutorial: The strength of an electromagnetic signal decreases in | Tutorial: The strength of an electromagnetic signal decreases in | |||
| proportion to the square of the distance between the source and | proportion to the square of the distance between the source and | |||
| the receiver. Therefore, EMSEC for electromagnetic signals can be | the receiver. Therefore, EMSEC for electromagnetic signals can be | |||
| achieved by a combination of (a) reducing the strength of | achieved by a combination of (a) reducing the strength of | |||
| emanations to a defined level and (b) establishing around that | emanations to a defined level and (b) establishing around that | |||
| equipment an appropriately sized physical buffer zone from which | equipment an appropriately sized physical buffer zone from which | |||
| unauthorized entities are excluded. By making the zone large | unauthorized entities are excluded. By making the zone large | |||
| enough, it is possible to limit the signal strength available to | enough, it is possible to limit the signal strength available to | |||
| skipping to change at page 246, line 51 ¶ | skipping to change at page 264, line 4 ¶ | |||
| 1a. (I) A potential for violation of security, which exists when | 1a. (I) A potential for violation of security, which exists when | |||
| there is an entity, circumstance, capability, action, or event | there is an entity, circumstance, capability, action, or event | |||
| that could cause harm. (See: dangling threat, INFOCON level, | that could cause harm. (See: dangling threat, INFOCON level, | |||
| threat action, threat agent, threat consequence. Compare: attack, | threat action, threat agent, threat consequence. Compare: attack, | |||
| vulnerability.) | vulnerability.) | |||
| 1b. (N) Any circumstance or event with the potential to adversely | 1b. (N) Any circumstance or event with the potential to adversely | |||
| affect a system through unauthorized access, destruction, | affect a system through unauthorized access, destruction, | |||
| disclosure, or modification of data, or denial of service. [C4009] | disclosure, or modification of data, or denial of service. [C4009] | |||
| (See: sensitive information.) | (See: sensitive information.) | |||
| Usage: (a) Frequently misused with the meaning of either "threat | Usage: (a) Frequently misused with the meaning of either "threat | |||
| action" or "vulnerability". (b) In some contexts, "threat" is used | action" or "vulnerability". (b) In some contexts, "threat" is used | |||
| more narrowly to refer only to intelligent threats; for example, | more narrowly to refer only to intelligent threats; for example, | |||
| see definition 2 below. (c) In some contexts, "threat" is used | see definition 2 below. (c) In some contexts, "threat" is used | |||
| more broadly to cover both definition 1 and other concepts, such | more broadly to cover both definition 1 and other concepts, such | |||
| as in definition 3 below. | as in definition 3 below. | |||
| Tutorial: A threat is a possible danger that might exploit a | Tutorial: A threat is a possible danger that might exploit a | |||
| vulnerability. | vulnerability. Thus, a threat may be intentional or not: | |||
| - "Intentional threat": A possibility of an attack by an | - "Intentional threat": A possibility of an attack by an | |||
| intelligent entity (e.g., an individual cracker or a criminal | intelligent entity (e.g., an individual cracker or a criminal | |||
| organization). | organization). | |||
| - "Accidental threat": A possibility of human error or omission, | - "Accidental threat": A possibility of human error or omission, | |||
| unintended equipment malfunction, or natural disaster (e.g., | unintended equipment malfunction, or natural disaster (e.g., | |||
| fire, flood, earthquake, or windstorm). (See list in [FP031].) | fire, flood, earthquake, windstorm, and other causes listed in | |||
| [FP031]). | ||||
| The Common Criteria characterizes a threat in terms of (a) a | The Common Criteria characterizes a threat in terms of (a) a | |||
| threat agent, (b) a presumed method of attack, (c) any | threat agent, (b) a presumed method of attack, (c) any | |||
| vulnerabilities that are the foundation for the attack, and (d) | vulnerabilities that are the foundation for the attack, and (d) | |||
| the system resource that is attacked. | the system resource that is attacked. That characterization agrees | |||
| with the definitions in this Glossary (see: diagram under | ||||
| "attack"). | ||||
| 2. (O) The technical and operational capability of a hostile | 2. (O) The technical and operational ability of a hostile entity | |||
| entity to detect, exploit, or subvert a friendly system and the | to detect, exploit, or subvert a friendly system and the | |||
| demonstrated, presumed, or inferred intent of that entity to | demonstrated, presumed, or inferred intent of that entity to | |||
| conduct such activity. | conduct such activity. | |||
| Tutorial: To be likely to launch an attack, an adversary must have | Tutorial: To be likely to launch an attack, an adversary must have | |||
| (a) a motive to attack, (b) a method or technical capability to | (a) a motive to attack, (b) a method or technical ability to make | |||
| make the attack, and (c) an opportunity to appropriately access | the attack, and (c) an opportunity to appropriately access the | |||
| the targeted system. | targeted system. | |||
| 3. (O) "An indication of an impending undesirable event." [Park] | 3. (O) "An indication of an impending undesirable event." [Park] | |||
| Tutorial: Definition 3 was intended to include these meanings: | Tutorial: Definition 3 was intended to include these meanings: | |||
| - "Potential threat": A possible security violation; i.e., the | - "Potential threat": A possible security violation; i.e., the | |||
| same as definition 1. | same as definition 1. | |||
| - "Active threat": An expression of intent to violate security. | - "Active threat": An expression of intent to violate security. | |||
| (Context usually distinguishes this meaning from the previous | (Context usually distinguishes this meaning from the previous | |||
| one.) | one.) | |||
| - "Accomplished threat" or "actualized threat": That is, an | - "Accomplished threat" or "actualized threat": That is, a threat | |||
| attack. Deprecated Usage: ISDs SHOULD NOT use the term "threat" | action. Deprecated Usage: ISDs SHOULD NOT use the term "threat" | |||
| with this meaning; instead, use "threat action". | with this meaning; instead, use "threat action". | |||
| $ threat action | $ threat action | |||
| (I) A realization of a threat, i.e., an occurrence in which system | (I) A realization of a threat, i.e., an occurrence in which system | |||
| security is assaulted as the result of either an accidental event | security is assaulted as the result of either an accidental event | |||
| or an intentional act. (See: attack, threat, threat consequence.) | or an intentional act. (See: attack, threat, threat consequence.) | |||
| Tutorial: A complete security architecture deals with both | Tutorial: A complete security architecture deals with both | |||
| intentional acts (i.e. attacks) and accidental events [FIPS31]. | intentional acts (i.e. attacks) and accidental events [FIPS31]. | |||
| (See: (various kinds of threat actions defined as subentries | (See: various kinds of threat actions defined under the four kinds | |||
| under) threat consequence.) | of "threat consequence".) | |||
| $ threat agent | $ threat agent | |||
| (I) A system entity that performs a threat action, or an event | (I) A system entity that performs a threat action, or an event | |||
| that results in a threat action. | that results in a threat action. | |||
| $ threat analysis | $ threat analysis | |||
| (I) An analysis of the probability of occurrences and consequences | (I) An analysis of the threat actions that might affect a system, | |||
| of damaging actions to a system. | primarily emphasizing their probability of occurrence but also | |||
| considering their resulting threat consequences. (Compare: risk | ||||
| analysis.) | ||||
| $ threat consequence | $ threat consequence | |||
| (I) A security violation that results from a threat action. | (I) A security violation that results from a threat action. | |||
| Tutorial: The four basic types of threat consequence are | Tutorial: The four basic types of threat consequence are | |||
| "unauthorized disclosure", "deception", "disruption", and | "unauthorized disclosure", "deception", "disruption", and | |||
| "usurpation" (see definitions of these four terms for discussion | "usurpation". (See main Glossary entries of each of these four | |||
| of the types of threat actions that can these consequences). | terms for lists of the types of threat actions that can result in | |||
| these consequences.) | ||||
| $ thumbprint | $ thumbprint | |||
| (I) A pattern of curves formed by the ridges on the tip of a | 1. (I) A pattern of curves formed by the ridges on the tip of a | |||
| thumb. (See: biometric authentication, fingerprint.) | thumb. (See: biometric authentication, fingerprint.) | |||
| 2. (D) Synonym for some type of "hash result". (See: biometric | ||||
| authentication. Compare: fingerprint.) | ||||
| Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for | Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for | |||
| "hash result" because that meaning mixes concepts in a potentially | "hash result" because that meaning mixes concepts in a potentially | |||
| misleading way. | misleading way. | |||
| $ ticket | $ ticket | |||
| (I) Synonym for "capability". | (I) Synonym for "capability token". | |||
| Tutorial: A ticket is usually granted by a centralized access | Tutorial: A ticket is usually granted by a centralized access | |||
| control server (ticket-granting agent) to authorize access to a | control server (ticket-granting agent) to authorize access to a | |||
| system resource for a limited time. Tickets can be implemented | system resource for a limited time. Tickets can be implemented | |||
| with either symmetric cryptography (see: Kerberos) or asymmetric | with either symmetric cryptography (see: Kerberos) or asymmetric | |||
| cryptography (see: attribute certificate). | cryptography (see: attribute certificate). | |||
| $ tiger team | $ tiger team | |||
| (I) A group of evaluators employed by a system's managers to | (I) A group of evaluators employed by a system's managers to | |||
| perform penetration tests on the system. | perform penetration tests on the system. | |||
| Deprecated Term: It is likely that other cultures have different | Deprecated Term: It is likely that other cultures use different | |||
| metaphors for this concept. Therefore, to ensure international | metaphors for this concept. Therefore, to avoid international | |||
| understanding, ISDs SHOULD NOT use this term. (See: (Deprecated | misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated | |||
| Usage under) Green Book.) | Usage under "Green Book".) | |||
| $ time stamp | $ time stamp | |||
| (I) /noun/ With respect to a data object, a label or marking in | (I) /noun/ With respect to a data object, a label or marking in | |||
| which is recorded the time (time of day or other instant of | which is recorded the time (time of day or other instant of | |||
| elapsed time) at which the label or marking was affixed to the | elapsed time) at which the label or marking was affixed to the | |||
| data object. (See: Time-Stamp Protocol.) | data object. (See: Time-Stamp Protocol.) | |||
| (O) /noun/ "With respect to a recorded network event, a data field | (O) /noun/ "With respect to a recorded network event, a data field | |||
| in which is recorded the time (time of day or other instant of | in which is recorded the time (time of day or other instant of | |||
| elapsed time) at which the event took place." [A1523] | elapsed time) at which the event took place." [A1523] | |||
| skipping to change at page 249, line 31 ¶ | skipping to change at page 266, line 44 ¶ | |||
| containing a time stamp. The authority creates the stamp by | containing a time stamp. The authority creates the stamp by | |||
| concatenating (a) a hash value of the input data object with (b) a | concatenating (a) a hash value of the input data object with (b) a | |||
| UTC time value and other parameters (policy OID, serial number, | UTC time value and other parameters (policy OID, serial number, | |||
| indication of time accuracy, nonce, DN of the authority, and | indication of time accuracy, nonce, DN of the authority, and | |||
| various extensions), and then signing that dataset with the | various extensions), and then signing that dataset with the | |||
| authority's private key as specified in CMS. Such an authority | authority's private key as specified in CMS. Such an authority | |||
| typically would operate as a trusted third-party service, but | typically would operate as a trusted third-party service, but | |||
| other operational models might be used. | other operational models might be used. | |||
| $ timing channel | $ timing channel | |||
| See: covert timing channel. | (I) See: covert timing channel. | |||
| $ TLS | $ TLS | |||
| (I) See: Transport Layer Security. | (I) See: Transport Layer Security. | |||
| $ TLSP | $ TLSP | |||
| (N) See: Transport Layer Security Protocol. | (N) See: Transport Layer Security Protocol. | |||
| $ TOE | $ TOE | |||
| (N) See: target of evaluation | (N) See: target of evaluation | |||
| skipping to change at page 249, line 44 ¶ | skipping to change at page 267, line 4 ¶ | |||
| (I) See: Transport Layer Security. | (I) See: Transport Layer Security. | |||
| $ TLSP | $ TLSP | |||
| (N) See: Transport Layer Security Protocol. | (N) See: Transport Layer Security Protocol. | |||
| $ TOE | $ TOE | |||
| (N) See: target of evaluation | (N) See: target of evaluation | |||
| $ token | $ token | |||
| 1. (I) /cryptography/ See: cryptographic token. (Compare: dongle.) | 1. (I) /cryptography/ See: cryptographic token. (Compare: dongle.) | |||
| 2. (I) /access control/ An object that is used to control access | 2. (I) /access control/ An object that is used to control access | |||
| and is passed between cooperating entities in a protocol that | and is passed between cooperating entities in a protocol that | |||
| synchronizes use of a shared resource. Usually, the entity that | synchronizes use of a shared resource. Usually, the entity that | |||
| currently holds the token has exclusive access to the resource. | currently holds the token has exclusive access to the resource. | |||
| (See: capability token.) | ||||
| Usage: This term is heavily overloaded in the computing | Usage: This term is heavily overloaded in the computing | |||
| literature; therefore, ISDs SHOULD NOT use this term with any | literature; therefore, ISDs SHOULD NOT use this term with any | |||
| definition other than 1 or 2. | definition other than 1 or 2. | |||
| 3a. (D) /authentication/ A data object or a physical device used | 3a. (D) /authentication/ A data object or a physical device used | |||
| to verify an identity in an authentication process. | to verify an identity in an authentication process. | |||
| 3b. (D) /U.S. Government/ Something that the claimant in an | 3b. (D) /U.S. Government/ Something that the claimant in an | |||
| authentication process (i.e., the entity that claims an identity) | authentication process (i.e., the entity that claims an identity) | |||
| skipping to change at page 250, line 18 ¶ | skipping to change at page 267, line 30 ¶ | |||
| verification step of the process. [SP63] | verification step of the process. [SP63] | |||
| Usage: Deprecated usage: ISDs SHOULD NOT use this term with | Usage: Deprecated usage: ISDs SHOULD NOT use this term with | |||
| definitions 3a and 3b; instead, use more specifically descriptive | definitions 3a and 3b; instead, use more specifically descriptive | |||
| and informative terms such as "authentication information" or | and informative terms such as "authentication information" or | |||
| "cryptographic token", depending on what is meant. | "cryptographic token", depending on what is meant. | |||
| NIST defines four types of claimant tokens for electronic | NIST defines four types of claimant tokens for electronic | |||
| authentication in an information system [SP63]. ISDs SHOULD NOT | authentication in an information system [SP63]. ISDs SHOULD NOT | |||
| use these four NIST terms; they mix concepts in potentially | use these four NIST terms; they mix concepts in potentially | |||
| confusing ways. These terms can be avoided by using more | confusing ways and duplicate the meaning of better-established | |||
| specifically descriptive terms as follows: | terms. These four terms can be avoided by using more specifically | |||
| - NIST "hard token": A hardware device that contains a protected | descriptive terms as follows: | |||
| - NIST "hard token": A hardware device that contains a protected | ||||
| cryptographic key. (This is a type of "cryptographic token", | cryptographic key. (This is a type of "cryptographic token", | |||
| and the key is a type of "authentication information".) | and the key is a type of "authentication information".) | |||
| - NIST "one-time password device token": A personal hardware | - NIST "one-time password device token": A personal hardware | |||
| device that generates one-time passwords. (One-time passwords | device that generates one-time passwords. (One-time passwords | |||
| are typically generated cryptographically. Therefore, this is a | are typically generated cryptographically. Therefore, this is a | |||
| type of "cryptographic token", and the key is a type of | type of "cryptographic token", and the key is a type of | |||
| "authentication information".) | "authentication information".) | |||
| - NIST "soft token": A cryptographic key that typically is stored | - NIST "soft token": A cryptographic key that typically is stored | |||
| on disk or some other magnetic media. (The key is a type of | on disk or some other magnetic media. (The key is a type of | |||
| "authentication information"; "authentication key" would be a | "authentication information"; "authentication key" would be a | |||
| better description.) | better description.) | |||
| - NIST "password token": A secret data value that the claimant | - NIST "password token": A secret data value that the claimant | |||
| memorizes. (This is a "password" that is being used as | memorizes. (This is a "password" that is being used as | |||
| "authentication information".) | "authentication information".) | |||
| $ token backup | $ token backup | |||
| (I) A token management operation that stores sufficient | (I) A token management operation that stores sufficient | |||
| information in a database (e.g., in a CAW) to recreate or restore | 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. | a security token (e.g., a smart card) if it is lost or damaged. | |||
| $ token copy | $ token copy | |||
| (I) A token management operation that copies all the personality | (I) A token management operation that copies all the personality | |||
| information from one security token to another. However, unlike in | information from one security token to another. However, unlike in | |||
| a token restore operation, the second token is initialized with | a token restore operation, the second token is initialized with | |||
| its own, different local security values such as PINs and storage | its own, different local security values such as PINs and storage | |||
| keys. | keys. | |||
| $ token management | $ token management | |||
| (I) The process of initializing security tokens (e.g., see: smart | (I) The process that includes initializing security tokens (e.g., | |||
| card), loading data into the tokens, and controlling the tokens | see: smart card), loading data into the tokens, and controlling | |||
| during their life cycle. May include performing key management and | the tokens during their life cycle. May include performing key | |||
| certificate management functions; generating and installing PINs; | management and certificate management functions; generating and | |||
| loading user personality data; performing card backup, card copy, | installing PINs; loading user personality data; performing card | |||
| and card restore operations; and updating firmware. | backup, card copy, and card restore operations; and updating | |||
| firmware. | ||||
| $ token restore | $ token restore | |||
| (I) A token management operation that loads a security token with | (I) A token management operation that loads a security token with | |||
| data for the purpose of recreating (duplicating) the contents | data for the purpose of recreating (duplicating) the contents | |||
| previously held by that or another token. (See: recovery.) | previously held by that or another token. (See: recovery.) | |||
| $ token storage key | $ token storage key | |||
| (I) A cryptographic key used to protect data that is stored on a | (I) A cryptographic key used to protect data that is stored on a | |||
| security token. | security token. | |||
| $ top CA | $ top CA | |||
| (I) A synonym for "root" in a certification hierarchy. | (I) A synonym for "root" in a certification hierarchy. (See: apex | |||
| trust anchor.) | ||||
| $ top-level specification | $ top-level specification | |||
| (I) "A non-procedural description of system behavior at the most | (I) "A non-procedural description of system behavior at the most | |||
| abstract level; typically a functional specification that omits | abstract level; typically a functional specification that omits | |||
| all implementation details." [NCS04] (See: (discussion under) | all implementation details." [NCS04] (See: Tutorial under | |||
| security policy.) | "security policy".) | |||
| Tutorial: A top-level specification may be descriptive or formal: | Tutorial: A top-level specification is at a level of abstraction | |||
| - "Descriptive top-level specification": One that is written in a | below "security model" and above "security architecture" (see: | |||
| Tutorial under "security policy"). | ||||
| 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. | natural language like English or an informal design notation. | |||
| - "Formal top-level specification": One that is written in a | - "Formal top-level specification": One that is written in a | |||
| formal mathematical language to enable theorems to be proven | formal mathematical language to enable theorems to be proven | |||
| that show that the specification correctly implements a set of | that show that the specification correctly implements a set of | |||
| formal requirements or a formal security model. (See: | formal requirements or a formal security model. (See: | |||
| correctness proof.) | correctness proof.) | |||
| $ traceback | $ traceback | |||
| (I) Identification of the source of a data packet. (See: network | (I) Identification of the source of a data packet. (See: | |||
| weaving.) | masquerade, network weaving.) | |||
| $ tracker | $ tracker | |||
| (N) An attack technique for achieving unauthorized disclosure from | (N) An attack technique for achieving unauthorized disclosure from | |||
| a statistical database. [Denns] (See: (Tutorial under) inference | a statistical database. [Denns] (See: Tutorial under "inference | |||
| control.) | control".) | |||
| $ traffic analysis | $ traffic analysis | |||
| 1. (I) Gaining knowledge of information by inference from | 1. (I) Gaining knowledge of information by inference from | |||
| observable characteristics of data flow(s), even when the | observable characteristics of a data flow, even if the information | |||
| information is encrypted or otherwise not directly available. Such | is not directly available (e.g., when the data is encrypted). | |||
| characteristics include the identities and locations of the | These characteristics include the identities and locations of the | |||
| source(s) and destination(s), and the presence, amount, frequency, | source(s) and destination(s) of the flow, and the flow's presence, | |||
| and duration of occurrence. (See: inference, traffic-flow | amount, frequency, and duration of occurrence. The object of the | |||
| confidentiality, wiretapping. Compare: signal analysis.) | analysis might be information in SDUs, information in the PCI, or | |||
| both. (See: inference, traffic-flow confidentiality, wiretapping. | ||||
| Compare: signal analysis.) | ||||
| 2. (O) "The inference of information from observation of traffic | 2. (O) "The inference of information from observation of traffic | |||
| flows (presence, absence, amount, direction, and frequency)." | flows (presence, absence, amount, direction, and frequency)." | |||
| [I7498 Part 2] | [I7498 Part 2] | |||
| $ traffic-flow analysis | $ traffic-flow analysis | |||
| (I) Synonym for "traffic analysis". | (I) Synonym for "traffic analysis". | |||
| $ traffic-flow confidentiality | $ traffic-flow confidentiality (TFC) | |||
| 1. (I) A data confidentiality service to protect against traffic | 1. (I) A data confidentiality service to protect against traffic | |||
| analysis. (See: communications cover.) | analysis. (See: communications cover.) | |||
| 2. (O) "A confidentiality service to protect against traffic | 2. (O) "A confidentiality service to protect against traffic | |||
| analysis." [I7498 Part 2] | analysis." [I7498 Part 2] | |||
| Tutorial: Confidentiality concerns involve both direct and | ||||
| indirect disclosure of data, and the latter includes traffic | ||||
| analysis. However, operational considerations can make TFC | ||||
| difficult to achieve. For example, if Alice sends a product idea | ||||
| to Bob in an email message, she wants data confidentiality for the | ||||
| message's content, and she might also want to conceal the | ||||
| destination of the message in order to hide Bob's identity from | ||||
| her competitors. However, the identity of the intended recipient, | ||||
| or at least a network address for that recipient, needs to be made | ||||
| available to the mail system. Thus, complex forwarding schemes may | ||||
| be needed to conceal the ultimate destination as the message | ||||
| travels through the open Internet (see: onion routing). | ||||
| Later, if Alice uses an ATM during a clandestine visit to | ||||
| negotiate with Bob, she might prefer that her bank conceal the | ||||
| origin of her transaction, because knowledge of the ATM's location | ||||
| might allow a competitor to infer Bob's identity. The bank, on the | ||||
| other hand, might prefer to protect only Alice's PIN (see: | ||||
| selective-field confidentiality). | ||||
| A TFC service can be either full or partial: | ||||
| - "Full TFC": This type of service conceals all traffic | ||||
| characteristics. | ||||
| - "Partial TFC": This type of service either (a) conceals some | ||||
| but not all of the characteristics or (b) does not completely | ||||
| conceal some characteristic. | ||||
| On point-to-point data links, full TFC can be provided by | ||||
| enciphering all PDUs and also generating a continuous, random data | ||||
| stream to seamlessly fill all gaps between PDUs. To a wiretapper, | ||||
| the link then appears to be carrying an unbroken stream of | ||||
| enciphered data. In other cases -- including on a shared or | ||||
| broadcast medium, or end-to-end in a network -- only partial TFC | ||||
| is possible, and that may require a combination of techniques. For | ||||
| example, a LAN that uses "carrier sense multiple access with | ||||
| collision detection" (CSMA/CD; a.k.a. "listen while talk") to | ||||
| control access to the medium, relies on detecting intervals of | ||||
| silence, which prevents using full TFC. Partial TFC can be | ||||
| provided on that LAN by measures such as adding spurious PDUs, | ||||
| padding PDUs to a constant size, or enciphering addresses just | ||||
| above the Physical Layer; but these measures reduce the efficiency | ||||
| with which the LAN can carry traffic. At higher protocol layers, | ||||
| SDUs can be protected, but addresses and other items of PCI must | ||||
| be visible at the layers below. | ||||
| $ traffic key | ||||
| (I) A cryptographic key used by a device for protecting | ||||
| information that is being transmitted between devices, as opposed | ||||
| to protecting information that being is maintained in the device. | ||||
| (Compare: storage key.) | ||||
| $ traffic padding | $ traffic padding | |||
| (I) "The generation of spurious instances of communication, | (I) "The generation of spurious instances of communication, | |||
| spurious data units, and/or spurious data within data units." | spurious data units, and/or spurious data within data units." | |||
| [I7498 Part 2] | [I7498 Part 2] | |||
| $ tranquillity property | $ tranquillity property | |||
| (N) /formal model/ Property of a system whereby the security level | (N) /formal model/ Property of a system whereby the security level | |||
| of an object cannot change while the object is being processed by | of an object cannot change while the object is being processed by | |||
| the system. (See: Bell-LaPadula model.) | the system. (See: Bell-LaPadula model.) | |||
| skipping to change at page 252, line 33 ¶ | skipping to change at page 270, line 54 ¶ | |||
| 1. (I) A unit of interaction between an external entity and a | 1. (I) A unit of interaction between an external entity and a | |||
| system, or between components within a system, that involves a | system, or between components within a system, that involves a | |||
| series of system actions or events. | series of system actions or events. | |||
| 2. (O) "A discrete event between user and systems that supports a | 2. (O) "A discrete event between user and systems that supports a | |||
| business or programmatic purpose." [M0404] | business or programmatic purpose." [M0404] | |||
| Tutorial: To maintain secure state, transactions need to be | Tutorial: To maintain secure state, transactions need to be | |||
| processed coherently and reliably. Usually, they need to be | processed coherently and reliably. Usually, they need to be | |||
| designed to be atomic, consistent, isolated, and durable [Gray]: | designed to be atomic, consistent, isolated, and durable [Gray]: | |||
| - "Atomic": All actions and events that comprise the transaction | - "Atomic": All actions and events that comprise the transaction | |||
| are guaranteed to be completed successfully, or else the result | are guaranteed to be completed successfully, or else the result | |||
| is as if none at all were executed. | is as if none at all were executed. | |||
| - "Consistent": The transaction satisfies correctness constraints | - "Consistent": The transaction satisfies correctness constraints | |||
| defined for the data that is being processed. | defined for the data that is being processed. | |||
| - "Isolated": If two transactions are performed concurrently, | - "Isolated": If two transactions are performed concurrently, | |||
| they do not interfere with each other, and it appears as though | they do not interfere with each other, and it appears as though | |||
| the system performs one at a time. | the system performs one at a time. | |||
| - "Durable": System state and transaction semantics survive | - "Durable": System state and transaction semantics survive | |||
| system failures. | system failures. | |||
| $ TRANSEC | $ TRANSEC | |||
| (I) See: transmission security. | (I) See: transmission security. | |||
| $ Transmission Control Code field (TCC field) | $ Transmission Control Code field (TCC field) | |||
| (I) A data field that provides a means to segregate traffic and | (I) A data field that provides a means to segregate traffic and | |||
| define controlled communities of interest in the security option | define controlled communities of interest in the security option | |||
| (option type = 130) of IP's datagram header format. The TCC values | (option type = 130) of IPv4's datagram header format. The TCC | |||
| are alphanumeric trigraphs assigned by the U.S. Government as | values are alphanumeric trigraphs assigned by the U.S. Government | |||
| specified in RFC 791. | as specified in RFC 791. | |||
| $ Transmission Control Protocol (TCP) | $ Transmission Control Protocol (TCP) | |||
| (I) An Internet Standard, transport-layer protocol (RFC 793) that | (I) An Internet Standard, Transport-Layer protocol (RFC 793) that | |||
| reliably delivers a sequence of datagrams from one computer to | reliably delivers a sequence of datagrams from one computer to | |||
| another in a computer network. (See: TCP/IP.) | another in a computer network. (See: TCP/IP.) | |||
| Tutorial: TCP is designed to fit into a layered suite of protocols | Tutorial: TCP is designed to fit into a layered suite of protocols | |||
| that support internetwork applications. TCP assumes it can obtain | that support internetwork applications. TCP assumes it can obtain | |||
| a simple but potentially unreliable end-to-end datagram service | a simple but potentially unreliable end-to-end datagram service | |||
| (such as IP) from the lower level protocols. | (such as IP) from the lower layer protocols. | |||
| $ transmission security (TRANSEC) | $ transmission security (TRANSEC) | |||
| (I) Measures that protect communications from interception and | (I) Measures that protect communications from interception and | |||
| exploitation by means other than cryptanalysis. Usually understood | exploitation by means other than cryptanalysis. Usually understood | |||
| to be a part of COMSEC. (Compare: traffic flow confidentiality.) | to be a part of COMSEC. (Compare: traffic flow confidentiality.) | |||
| $ Transport Layer | ||||
| See: Internet Protocol Suite, OSIRM. | ||||
| $ Transport Layer Security (TLS) | $ Transport Layer Security (TLS) | |||
| (I) TLS Version 1.0 is an Internet protocol [R2246] that is based | (I) TLS Version 1.0 is an Internet protocol [R2246] that is based | |||
| on, and very similar to, SSL Version 3.0. (Compare: TLSP.) | on, and very similar to, SSL Version 3.0. (Compare: TLSP.) | |||
| Usage: The TLS protocol is misnamed, because it operates well | Deprecated Usage: The TLS protocol is misnamed. The name | |||
| above the IPS transport layer. | misleadingly suggests that TLS is situated in the IPS Transport | |||
| Layer, but TLS is always layered above a reliable Transport-Layer | ||||
| protocol (usually TCP) and either layered immediately below or | ||||
| integrated with an Application-Layer protocol (often HTTP). | ||||
| $ Transport Layer Security Protocol (TLSP) | $ Transport Layer Security Protocol (TLSP) | |||
| (N) An end-to-end encryption protocol (ISO 10736) that provides | (N) An end-to-end encryption protocol (ISO 10736) that provides | |||
| security services at the bottom of OSIRM layer 4, i.e., directly | security services at the bottom of OSIRM Layer 4, i.e., directly | |||
| above layer 3. (Compare: TLS.) | above Layer 3. (Compare: TLS.) | |||
| Tutorial: TLSP evolved directly from SP4. | Tutorial: TLSP evolved directly from SP4. | |||
| $ transport mode | $ transport mode | |||
| (I) One of two ways to apply AH or ESP to protect data packets; in | (I) One of two ways to apply AH or ESP to protect data packets; in | |||
| this mode, the IPsec protocol encapsulates (i.e., the protection | this mode, the IPsec protocol encapsulates (i.e., the protection | |||
| applies to) the packets of an IPS transport protocol (e.g., TCP, | applies to) the packets of an IPS Transport-Layer protocol (e.g., | |||
| UDP), which is normally carried directly above IP in an IPS | TCP, UDP), which is normally carried directly above IP in an IPS | |||
| protocol stack. (Compare: tunnel mode.) | protocol stack. (Compare: tunnel mode.) | |||
| Tutorial: An IPsec transport-mode security association is always | Tutorial: An IPsec transport-mode security association is always | |||
| between two hosts; neither end has the role of a security gateway. | between two hosts; neither end has the role of a security gateway. | |||
| Whenever either end of an IPsec security association is a security | Whenever either end of an IPsec security association is a security | |||
| gateway, the association is required to be in tunnel mode. | gateway, the association is required to be in tunnel mode. | |||
| $ transposition | $ transposition | |||
| (I) /cryptography/ A method of encryption in which elements of the | (I) /cryptography/ A method of encryption in which elements of the | |||
| plain text retain their original form but undergo some change in | plain text retain their original form but undergo some change in | |||
| skipping to change at page 254, line 4 ¶ | skipping to change at page 272, line 31 ¶ | |||
| their relative position. (Compare: substitution.) | their relative position. (Compare: substitution.) | |||
| $ trap door | $ trap door | |||
| (I) Synonym for "back door". | (I) Synonym for "back door". | |||
| $ Triple Data Encryption Algorithm | $ Triple Data Encryption Algorithm | |||
| (I) An block cipher that transforms each 64-bit plaintext block by | (I) An block cipher that transforms each 64-bit plaintext block by | |||
| applying the DEA three successive times, using either two or three | applying the DEA three successive times, using either two or three | |||
| different keys for an effective key length of 112 or 168 bits. | different keys for an effective key length of 112 or 168 bits. | |||
| [A9052, SP67] | [A9052, SP67] | |||
| Example: A variation proposed for IPsec's ESP uses a 168-bit key, | Example: A variation proposed for IPsec's ESP uses a 168-bit key, | |||
| consisting of three independent 56-bit values used by the DEA, and | consisting of three independent 56-bit values used by the DEA, and | |||
| a 64-bit initialization vector. Each datagram contains an IV to | a 64-bit initialization vector. Each datagram contains an IV to | |||
| ensure that each received datagram can be decrypted even when | ensure that each received datagram can be decrypted even when | |||
| other datagrams are dropped or a sequence of datagrams is | other datagrams are dropped or a sequence of datagrams is | |||
| reordered in transit. [R1851] | reordered in transit. [R1851] | |||
| $ triple-wrapped | $ triple-wrapped | |||
| (I) /S-MIME/ Data that has been signed with a digital signature, | (I) /S-MIME/ Data that has been signed with a digital signature, | |||
| and then encrypted, and then signed again. [R2634] | then encrypted, and then signed again. [R2634] | |||
| $ Trojan horse | $ Trojan horse | |||
| (I) A computer program that appears to have a useful function, but | (I) A computer program that appears to have a useful function, but | |||
| also has a hidden and potentially malicious function that evades | also has a hidden and potentially malicious function that evades | |||
| security mechanisms, sometimes by exploiting legitimate | security mechanisms, sometimes by exploiting legitimate | |||
| authorizations of a system entity that invokes the program. (See: | authorizations of a system entity that invokes the program. (See: | |||
| malware, spyware. Compare: logic bomb, virus, worm.) | malware, spyware. Compare: logic bomb, virus, worm.) | |||
| $ trust | $ trust | |||
| 1. (I) /information system/ The extent to which someone who relies | 1. (I) /information system/ A feeling of certainty (sometimes | |||
| on a system can have confidence that the system meets its | based on inconclusive evidence) either (a) that the system will | |||
| specifications, i.e., that the system does what it claims to do | not fail or (b) that the system meets its specifications (i.e., | |||
| and does not perform unwanted functions. (See: trust level, | the system does what it claims to do and does not perform unwanted | |||
| trusted system, trustworthy system. Compare: assurance.) | functions). (See: trust level, trusted system, trustworthy system. | |||
| Compare: assurance.) | ||||
| 2. (I) /PKI/ A relationship between a certificate user and a CA in | 2. (I) /PKI/ A relationship between a certificate user and a CA in | |||
| which the user acts according to the assumption that the CA | which the user acts according to the assumption that the CA | |||
| creates only valid digital certificates. | creates only valid digital certificates. | |||
| Tutorial: "Generally, an entity is said to 'trust' a second entity | Tutorial: "Generally, an entity is said to 'trust' a second entity | |||
| when the first entity makes the assumption that the second entity | when the first entity makes the assumption that the second entity | |||
| will behave exactly as the first entity expects. This trust may | will behave exactly as the first entity expects. This trust may | |||
| apply only for some specific function. The key role of trust in | apply only for some specific function. The key role of trust in | |||
| [X.509] is to describe the relationship between an entity and a | [X.509] is to describe the relationship between an entity [i.e., a | |||
| [CA]; an entity shall be certain that it can trust the CA to | certificate user] and a [CA]; an entity shall be certain that it | |||
| create only valid and reliable certificates." [X509] | can trust the CA to create only valid and reliable certificates." | |||
| [X509] | ||||
| Components can be grouped into three categories of trust [Gass]: | Components of a system can be grouped into three classes of trust | |||
| - "Trusted": The component is responsible for enforcing security | [Gass]: | |||
| - "Trusted": The component is responsible for enforcing security | ||||
| policy on other components; the system's security depends on | policy on other components; the system's security depends on | |||
| flawless operation of the component. (See: trusted process.) | flawless operation of the component. (See: trusted process.) | |||
| - "Benign": The component is not responsible for enforcing | - "Benign": The component is not responsible for enforcing | |||
| security policy, but it has sensitive authorizations. It must | security policy, but it has sensitive authorizations. It must | |||
| be trusted not to intentionally violate security policy, but | be trusted not to intentionally violate security policy, but | |||
| security violations are assumed to be accidental and not likely | security violations are assumed to be accidental and not likely | |||
| to affect overall system security. | to affect overall system security. | |||
| - "Untrusted": The component is of unknown or suspicious | - "Untrusted": The component is of unknown or suspicious | |||
| provenance and must be treated as deliberately malicious. (See: | provenance and must be treated as deliberately malicious. (See: | |||
| malicious logic.) | malicious logic.) | |||
| $ trust anchor | $ trust anchor | |||
| (D) /PKI/ Synonym for "trusted certificate", "root", "root | (I) /PKI/ An established point of trust (usually based on the | |||
| certificate", or "root key". (See: trust chain.) | authority of some person, office, or organization) from which a | |||
| certificate user begins the validation of a certification path. | ||||
| (See: path validation, trust anchor CA, trust anchor certificate, | ||||
| trust anchor key.) | ||||
| Deprecated Term: ISDs SHOULD NOT use this term; it unnecessarily | Usage: ISDs that use this term SHOULD state a definition for it | |||
| duplicates the meaning of other terms and mixes concepts in a | because it is used in various ways in existing ISDs and other PKI | |||
| potentially misleading way. (See: (Deprecated Term under) trust | literature. The literature almost always uses this term in a sense | |||
| chain.) | that is equivalent to this definition, but usage often differs | |||
| with regard to what constitutes the point of trust. | ||||
| Tutorial: A trust anchor may be defined as being based on a public | ||||
| key, a CA, a public-key certificate, or some combination or | ||||
| variation of those: | ||||
| - A public key as a point of trust: Although a certification path | ||||
| is defined as beginning with a "sequence of public-key | ||||
| certificates", an implementation of a path validation process | ||||
| might not explicitly handle a root certificate as part of the | ||||
| path, but instead begin the process by using a trusted root key | ||||
| to verify the signature on a certificate that was issued by the | ||||
| root. | ||||
| Therefore, "trust anchor" is sometimes defined as just a public | ||||
| key. (See: root key, trust anchor key, trusted key.) | ||||
| - A CA as a point of trust: A trusted public key is just one of | ||||
| the data elements needed for path validation; the IPS path | ||||
| validation algorithm [R3280] also needs the name of the CA to | ||||
| which that key belongs, i.e., the DN of the issuer of the first | ||||
| X.509 certificate to be validated on the path. (See: issue.) | ||||
| Therefore, "trust anchor" is sometimes defined as either just a | ||||
| CA (where some public key is implied) or as a CA together with | ||||
| a specified public key belonging to that CA. (See: root, trust | ||||
| anchor CA, trusted CA.) | ||||
| Example: "A public key and the name of a [CA] 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 [CA]." [SP57] | ||||
| - A public-key certificate as a point of trust: In addition to | ||||
| the trusted CA's public key and name, the path validation | ||||
| algorithm needs to know the digital signature algorithm and any | ||||
| associated parameters with which the public key is used, and | ||||
| also any constraints that have been placed on the set of paths | ||||
| that may be validated using the key. All of this information is | ||||
| available from a CA's public-key certificate. | ||||
| Therefore, "trust anchor" is sometimes defined as a public-key | ||||
| certificate of a CA. (See: root certificate, trust anchor | ||||
| certificate, trusted certificate.) | ||||
| - Combinations: Combinations and variations of the first three | ||||
| definitions are also used in the PKI literature. | ||||
| Example: "trust anchor information". The IPS standard for path | ||||
| validation [R3280] specifies the information that describes "a | ||||
| CA that serves as a trust anchor for the certification path. | ||||
| The trust anchor information includes: (1) the trusted issuer | ||||
| name, (2) the trusted public key algorithm, (3) the trusted | ||||
| public key, and (4) optionally, the trusted public key | ||||
| parameters associated with the public key. The trust anchor | ||||
| information may be provided to the path processing procedure in | ||||
| the form of a self-signed certificate. The trusted anchor | ||||
| information is trusted because it was delivered to the path | ||||
| processing procedure by some trustworthy out-of-band procedure. | ||||
| If the trusted public key algorithm requires parameters, then | ||||
| the parameters are provided along with the trusted public key." | ||||
| $ trust anchor CA | ||||
| (I) A CA that is the subject of a trust anchor certificate or | ||||
| otherwise establishes a trust anchor key. (See: root, trusted CA.) | ||||
| Tutorial; The selection of a CA to be a trust anchor is a matter | ||||
| of policy. Some of the possible choices include (a) the top CA in | ||||
| a hierarchical PKI, (b) the CA that issued the verifier's own | ||||
| certificate, or (c) any other CA in a network PKI. Different | ||||
| applications may rely on different trust anchors, or may accept | ||||
| paths that begin with any of a set of trust anchors. The IPS path | ||||
| validation algorithm is the same regardless of the choice. | ||||
| $ trust anchor certificate | ||||
| (I) A public-key certificate that is used to provide the first | ||||
| public key in a certification path. (See: root certificate, trust | ||||
| anchor, trusted certificate.) | ||||
| $ trust anchor key | ||||
| (I) A public key that is used as the first public key in a | ||||
| certification path. (See: root key, trust anchor, trusted public | ||||
| key.) | ||||
| $ trust anchor information | ||||
| (I) See: secondary definition under "trust anchor". | ||||
| $ trust chain | $ trust chain | |||
| (D) Synonym for "certification path". (See: trust anchor, trusted | (D) Synonym for "certification path". (See: trust anchor, trusted | |||
| certificate.) | certificate.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term, because it | Deprecated Term: ISDs SHOULD NOT use this term, because it | |||
| unnecessarily duplicates the meaning of the internationally | unnecessarily duplicates the meaning of the internationally | |||
| standardized term. | standardized term. | |||
| This term also mixes concepts in a potentially misleading way. | Also, the term mixes concepts in a potentially misleading way. | |||
| Having "trust" involves factors unrelated to verifying signatures | Having "trust" involves factors unrelated to simply verifying | |||
| and performing other tests as specified by a standard for path | signatures and performing other tests as specified by a standard | |||
| validation (e.g., RFC 3280). Thus, even if a user is able to | algorithm for path validation (e.g., RFC 3280). Thus, even if a | |||
| validate a certification path, the user still might distrust one | user is able to validate a certification path algorithmically, the | |||
| of the CAs that issued certificates in that path or distrust some | user still might distrust one of the CAs that issued certificates | |||
| other aspects of the PKI. | in that path or distrust some other aspects of the PKI. | |||
| $ trust-file PKI | $ trust-file PKI | |||
| (I) A non-hierarchical PKI in which each certificate user has a | (I) A non-hierarchical PKI in which each certificate user has a | |||
| local file (which is used by application software) of public-key | local file (which is used by application software) of public-key | |||
| certificates that the user trusts as starting points (i.e., roots) | certificates that the user trusts as starting points (i.e., trust | |||
| for certification paths. (Compare: hierarchical PKI, mesh PKI, | anchors) for certification paths. (Compare: hierarchical PKI, mesh | |||
| trusted certificate, web of trust.) | PKI, trusted certificate, web of trust.) | |||
| Example: Popular browsers are distributed with an initial file of | Example: Popular browsers are distributed with an initial file of | |||
| root certificates, which often are self-signed certificates. Users | trust anchor certificates, which often are self-signed | |||
| can add certificates to the file or delete from it. The file may | certificates. Users can add certificates to the file or delete | |||
| be directly managed by the user, or the user's organization may | from it. The file may be directly managed by the user, or the | |||
| manage it from a centralized server. | user's organization may manage it from a centralized server. | |||
| $ trust hierarchy | $ trust hierarchy | |||
| (D) Synonym for "certification hierarchy". | (D) Synonym for "certification hierarchy". | |||
| Deprecated Usage: ISDs SHOULD NOT use this term because it mixes | Deprecated Usage: ISDs SHOULD NOT use this term because it mixes | |||
| concepts in a potentially misleading way. (See: trust, trust | concepts in a potentially misleading way. (See: trust, trust | |||
| chain, web of trust.) | chain, web of trust.) | |||
| $ trust level | $ trust level | |||
| (I) A characterization of a standard of security protection to be | (N) A characterization of a standard of security protection to be | |||
| met by an information system. (See: Common Criteria, TCSEC.) | met by an information system. (See: Common Criteria, TCSEC.) | |||
| Tutorial: A trust level is based not only on (a) the presence of | Tutorial: A trust level is based not only on (a) the presence of | |||
| security mechanisms, but also on the use of (b) systems | security mechanisms, but also on the use of (b) systems | |||
| engineering discipline to properly structure the system and (c) | engineering discipline to properly structure the system and (c) | |||
| implementation analysis to ensure that the system provides an | implementation analysis to ensure that the system provides an | |||
| appropriate degree of trust. | appropriate degree of trust. | |||
| $ trusted CA | ||||
| (I) A CA upon which a certificate user relies as issuing valid | ||||
| certificates; especially a CA that is used as a trust anchor CA. | ||||
| (See: certification path, root, trust anchor CA, validation.) | ||||
| Tutorial. This trust is transitive to the extent that the X.509 | ||||
| certificate extensions permit; that is, if a trusted CA issues a | ||||
| certificate to another CA, a user that trusts the first CA also | ||||
| trusts the second CA if the user succeeds in validating the | ||||
| certificate path (see: path validation). | ||||
| $ trusted certificate | $ trusted certificate | |||
| (I) A certificate upon which a certificate user relies as being | 1. (I) A digital certificate that a certificate user accepts as | |||
| valid without the need for validation testing; especially a | being valid "a priori", i.e., without testing the certificate to | |||
| public-key certificate that is used to provide the first public | validate it as the final certificate on a certification path; | |||
| key in a certification path. (See: certification path, root | especially a certificate that is used as a trust anchor | |||
| certificate, validation.) | certificate. (See: certification path, root certificate, trust | |||
| anchor certificate, trust-file PKI, validation.) | ||||
| Tutorial: A trusted public-key certificate might be (a) the root | Tutorial: The acceptance of a certificate as trusted is a matter | |||
| certificate in a hierarchical PKI, (b) the certificate of the CA | of policy and choice. Usually, a certificate is accepted as | |||
| that issued the user's own certificate in a mesh PKI, or (c) a | trusted because the user obtained it by reliable, out-of-band | |||
| certificate accepted by the user in a trust-file PKI. | means that cause the user to believe the certificate accurately | |||
| binds its subject's name to the subject's public key or other | ||||
| attribute values. Many choices are possible; e.g., 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) a certificate | ||||
| provided with an application that uses a trust-file PKI. | ||||
| $ Trusted Computer System Evaluation Criteria (TCSEC) | $ Trusted Computer System Evaluation Criteria (TCSEC) | |||
| (N) A standard for evaluating the security provided by operating | (N) A standard for evaluating the security provided by operating | |||
| systems [CSC001, DoD1]. Known as the "Orange Book" because of the | systems [CSC001, DoD1]. Known as the "Orange Book" because of the | |||
| color of its cover; first document in the Rainbow Series. (See: | color of its cover; first document in the Rainbow Series. (See: | |||
| Common Criteria, (Deprecated Usage under) Green Book, Orange Book, | Common Criteria, Deprecated Usage under "Green Book", Orange Book, | |||
| trust level, trusted computer system. Compare: TSEC.) | trust level, trusted computer system. Compare: TSEC.) | |||
| Tutorial: The TCSEC defines classes of hierarchically ordered | Tutorial: The TCSEC defines classes of hierarchically ordered | |||
| assurance levels for rating computer systems. From highest to | assurance levels for rating computer systems. From highest to | |||
| lowest, the classes are as follows: | lowest, the classes are as follows: | |||
| - Division A: Verified protection. | ||||
| - Division A. Verified protection. | Beyond A1 Beyond current technology. (See: beyond A1.) | |||
| Beyond A1. Beyond current technology. (See: beyond A1.) | Class A1 Verified design. (See: SCOMP.) | |||
| Class A1. Verified design. (See: SCOMP.) | - Division B: Mandatory protection. | |||
| - Division B: Mandatory protection. | Class B3 Security domains. | |||
| Class B3. Security domains. | Class B2 Structured protection. (See: Multics.) | |||
| Class B2. Structured protection. (See: Multics.) | Class B1 Labeled security protection. | |||
| Class B1. Labeled security protection. | - Division C: Discretionary protection. | |||
| - Division C: Discretionary protection. | Class C2 Controlled access protection. | |||
| Class C2. Controlled access protection. | Class C1 Discretionary security protection. | |||
| Class C1. Discretionary security protection. | - Division D: Minimal protection, i.e., has been evaluated but | |||
| - Division D: Minimal protection; i.e., has been evaluated but | does not meet the requirements for a higher evaluation class. | |||
| does not meet the requirements for a higher evaluation class. | ||||
| $ trusted computing base (TCB) | $ trusted computing base (TCB) | |||
| (N) "The totality of protection mechanisms within a computer | (N) "The totality of protection mechanisms within a computer | |||
| system, including hardware, firmware, and software, the | system, including hardware, firmware, and software, the | |||
| combination of which is responsible for enforcing a security | combination of which is responsible for enforcing a security | |||
| policy." [NCS04] (See: (discussion of "trusted" under) trust.) | policy." [NCS04] (See: "trusted" under "trust".) | |||
| $ trusted distribution | $ trusted distribution | |||
| (I) /computer security/ "A trusted method for distributing the TCB | (I) /computer security/ "A trusted method for distributing the TCB | |||
| hardware, software, and firmware components, both originals and | hardware, software, and firmware components, both originals and | |||
| updates, that provides methods for protecting the TCB from | updates, that provides methods for protecting the TCB from | |||
| modification during distribution and for detection of any changes | modification during distribution and for detection of any changes | |||
| to the TCB that may occur." [NCS04] (See: code signing, | to the TCB that may occur." [NCS04] (See: code signing, | |||
| configuration control.) | configuration control.) | |||
| $ trusted key | $ trusted key | |||
| (I) A public key upon which a user relies; especially a public key | (D) Abbreviation for "trusted public key" and also for other types | |||
| that can be used as the first public key in a certification path. | of keys. (See: root key, trust anchor key.) | |||
| (See: certification path, root key, validation.) | ||||
| Tutorial: A trusted public key might be (a) the root key in a | Deprecated Usage: ISDs SHOULD either (a) state a definition for | |||
| hierarchical PKI, (b) the key of the CA that issued the user's own | this term or (b) use a different, less ambiguous term. This term | |||
| certificate in a mesh PKI, or (c) any key accepted by the user in | is ambiguous when it stands alone; e.g., it could refer to a | |||
| a trust-file PKI. | trusted public key or to a private key or symmetric key that is | |||
| believed to be secure (i.e., not compromised). | ||||
| $ trusted path | $ trusted path | |||
| 1a. (I) /COMPUSEC/ A mechanism by which a computer system user can | 1a. (I) /COMPUSEC/ A mechanism by which a computer system user can | |||
| communicate directly and reliably with the TCB and that can only | communicate directly and reliably with the TCB and that can only | |||
| be activated by the user or the TCB and cannot be imitated by | be activated by the user or the TCB and cannot be imitated by | |||
| untrusted software within the computer. [NCS04] | untrusted software within the computer. [NCS04] | |||
| 1b. (I) /COMSEC/ A mechanism by which a person or process can | 1b. (I) /COMSEC/ A mechanism by which a person or process can | |||
| communicate directly with a cryptographic module and that can only | communicate directly with a cryptographic module and that can only | |||
| be activated by the person, process, or module, and cannot be | be activated by the person, process, or module, and cannot be | |||
| imitated by untrusted software within the module. [FP140] | imitated by untrusted software within the module. [FP140] | |||
| $ trusted process | $ trusted process | |||
| 1. (I) A system component that has privileges that enable it to | 1. (I) A system component that has privileges that enable it to | |||
| affect the state of system security and that can, therefore, | affect the state of system security and that can, therefore, | |||
| through incorrect or malicious execution, violate the system's | through incorrect or malicious execution, violate the system's | |||
| security policy. (See: privileged process, trusted system.) | security policy. (See: privileged process, trusted system.) | |||
| $ trusted public key | ||||
| (I) A public key upon which a user relies; especially a public key | ||||
| that is used as a trust anchor key. (See: certification path, root | ||||
| key, trust anchor key, validation.) | ||||
| Tutorial: A trusted public key could 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 recovery | $ trusted recovery | |||
| (I) A process that, after a system has experienced a failure or an | (I) A process that, after a system has experienced a failure or an | |||
| attack, restores the system to normal operation (or to a secure | attack, restores the system to normal operation (or to a secure | |||
| state) without causing a security compromise. (See: recovery.) | state) without causing a security compromise. (See: recovery.) | |||
| $ trusted subnetwork | $ trusted subnetwork | |||
| (I) A subnetwork containing hosts and routers that trust each | (I) A subnetwork containing hosts and routers that trust each | |||
| other not to engage in active or passive attacks. (There also is | other not to engage in active or passive attacks. (There also is | |||
| an assumption that the underlying communication channels -- e.g., | an assumption that the underlying communication channels -- e.g., | |||
| telephone lines, or a LAN -- are protected from attack.) | telephone lines, or a LAN -- are protected from attack.) | |||
| skipping to change at page 258, line 33 ¶ | skipping to change at page 279, line 21 ¶ | |||
| (Compare: TCSEC.) | (Compare: TCSEC.) | |||
| $ TSIG | $ TSIG | |||
| (N) See: Trusted System Interoperability Group. | (N) See: Trusted System Interoperability Group. | |||
| $ tunnel | $ tunnel | |||
| 1. (I) A communication channel created in a computer network by | 1. (I) A communication channel created in a computer network by | |||
| encapsulating (i.e., layering) a communication protocol's data | encapsulating (i.e., layering) a communication protocol's data | |||
| packets in (i.e., above) a second protocol that normally would be | packets in (i.e., above) a second protocol that normally would be | |||
| carried above, or at the same layer as, the first one. (See: L2TP, | carried above, or at the same layer as, the first one. (See: L2TP, | |||
| VPN.) | VPN.) (Compare: covert channel.) | |||
| Tutorial: Tunneling can involve almost any OSIRM or TCP/IP | Tutorial: Tunneling can involve almost any two IPS protocol | |||
| protocol layers; for example, a TCP connection between two hosts | layers. For example, a TCP connection between two hosts could | |||
| could conceivably be tunneled through email messages across the | conceivably be carried above SMTP (i.e., in SMTP messages) as a | |||
| Internet. However, a tunnel usually is a logical point-to-point | covert channel to evade access controls that a security gateway | |||
| link -- i.e., an OSIRM layer 2 connection -- created by | applies to the normal TCP layer that is below SMTP. | |||
| encapsulating the layer 2 protocol in an IPS transport layer | ||||
| protocol (such as TCP), in an IPS network or internetwork layer | Usually, however, a tunnel is a logical point-to-point link -- | |||
| protocol (such as IP), or in another layer 2 protocol. In many | i.e., an OSIRM Layer 2 connection -- created by encapsulating the | |||
| cases, the encapsulation is accomplished with an extra, | Layer 2 protocol in one of the following three types of IPS | |||
| intermediate protocol, i.e., a tunneling protocol (such as L2TP) | protocols: (a) an IPS Transport-Layer protocol (such as TCP), (b) | |||
| that is layered between the tunneled layer 2 protocol and the | an IPS Network-Layer or Internet-Layer protocol (such as IP), or | |||
| encapsulating protocol. | (c) another Layer 2 protocol. In many cases, the encapsulation is | |||
| accomplished with an extra, intermediate protocol (i.e., a | ||||
| "tunneling protocol"; e.g., L2TP) that is layered below the | ||||
| tunneled Layer 2 protocol and above the encapsulating protocol. | ||||
| Tunneling can be used to move data between computers that use a | Tunneling can be used to move data between computers that use a | |||
| protocol not supported by the network connecting them. Tunneling | protocol not supported by the network connecting them. Tunneling | |||
| also can enable a computer network to use the services of a second | 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 | network as though the second network were a set of point-to-point | |||
| links between the first network's nodes. (See: virtual private | links between the first network's nodes. (See: virtual private | |||
| network.) | network.) | |||
| 2. (O) /SET/ The name of a SET private extension that indicates | 2. (O) /SET/ The name of a SET private extension that indicates | |||
| whether the CA or the payment gateway supports passing encrypted | whether the CA or the payment gateway supports passing encrypted | |||
| skipping to change at page 259, line 28 ¶ | skipping to change at page 280, line 20 ¶ | |||
| is required to be in tunnel mode. | is required to be in tunnel mode. | |||
| $ two-person control | $ two-person control | |||
| (I) The close surveillance and control of a system, a process, or | (I) The close surveillance and control of a system, a process, or | |||
| materials (especially with regard to cryptography) at all times by | materials (especially with regard to cryptography) at all times by | |||
| a minimum of two appropriately authorized persons, each capable of | a minimum of two appropriately authorized persons, each capable of | |||
| detecting incorrect and unauthorized procedures with respect to | detecting incorrect and unauthorized procedures with respect to | |||
| the tasks to be performed and each familiar with established | the tasks to be performed and each familiar with established | |||
| security requirements. (See: dual control, no-lone zone.) | security requirements. (See: dual control, no-lone zone.) | |||
| $ Twofish | ||||
| (O) A symmetric, 128-bit block cipher with variable key length | ||||
| (128, 192, or 256 bits), developed by Counterpane Labs as a | ||||
| candidate for the AES. (See: Blowfish.) | ||||
| $ type 0 product | $ type 0 product | |||
| (O) /cryptography, U.S. Government/ Classified cryptographic | (O) /cryptography, U.S. Government/ Classified cryptographic | |||
| equipment endorsed by NSA specifically for use (when appropriately | equipment endorsed by NSA specifically for use (when appropriately | |||
| keyed) in electronically distributing bulk keying material. | keyed) in electronically distributing bulk keying material. | |||
| $ type 1 product | $ type 1 product | |||
| (O) /cryptography, U.S. Government/ "Classified or controlled | (O) /cryptography, U.S. Government/ "Classified or controlled | |||
| cryptographic item endorsed by the NSA for securing classified and | cryptographic item endorsed by the NSA for securing classified and | |||
| sensitive U.S. Government information, when appropriately keyed. | sensitive U.S. Government information, when appropriately keyed. | |||
| The term refers only to products, and not to information, key, | The term refers only to products, and not to information, key, | |||
| skipping to change at page 260, line 14 ¶ | skipping to change at page 281, line 10 ¶ | |||
| $ type 4 algorithm | $ type 4 algorithm | |||
| (O) /cryptography, U.S. Government/ "Unclassified cryptographic | (O) /cryptography, U.S. Government/ "Unclassified cryptographic | |||
| algorithm that has been registered by [NIST] but not published as | algorithm that has been registered by [NIST] but not published as | |||
| a [FIPS]." [C4009] | a [FIPS]." [C4009] | |||
| $ UDP | $ UDP | |||
| (I) See: User Datagram Protocol. | (I) See: User Datagram Protocol. | |||
| $ UDP flood | $ UDP flood | |||
| (I) A denial-of-service attack that connects one system's UDP test | (I) A denial-of-service attack that takes advantage of (a) one | |||
| function that generates a series of characters for each packet it | system's UDP test function that generates a series of characters | |||
| receives, to another system's UPD test function that echoes any | for each packet it receives and (b) another system's UPD test | |||
| character it receives, resulting in a nonstop flood of data | function that echoes any character it receives; the attack | |||
| between the two systems. | connects (a) to (b) to cause a nonstop flood of data between the | |||
| two systems. | ||||
| $ unauthorized disclosure | $ unauthorized disclosure | |||
| (I) A circumstance or event whereby an entity gains access to | (I) A circumstance or event whereby an entity gains access to | |||
| information for which the entity is not authorized. | information for which the entity is not authorized. | |||
| Tutorial: This type of threat consequence can be caused by the | Tutorial: This type of threat consequence can be caused by the | |||
| following types of threat actions: exposure, interception, | following types of threat actions: exposure, interception, | |||
| inference, intrusion. Some methods of protecting against this | inference, intrusion. Some methods of protecting against this | |||
| consequence include access control, flow control, and inference | consequence include access control, flow control, and inference | |||
| control. (See: data confidentiality.) | control. (See: data confidentiality.) | |||
| $ unauthorized user | $ unauthorized user | |||
| (I) /access control/ A system entity that accesses a system | (I) /access control/ A system entity that accesses a system | |||
| resource for which the entity has not received an authorization. | resource for which the entity has not received an authorization. | |||
| (See: user. Compare: authorized user, insider, outsider.) | (See: user. Compare: authorized user, insider, outsider.) | |||
| Usage: The term is used in many ways and could easily be | Usage: ISDs that use this term SHOULD state a definition for it | |||
| misunderstood; therefore, ISDs that use this term SHOULD state a | because the term is used in many ways and could easily be | |||
| definition for it. | misunderstood. | |||
| $ uncertainty | $ uncertainty | |||
| (I) An information-theoretic measure (usually stated as a number | (N) An information-theoretic measure (usually stated as a number | |||
| of bits) of the minimum amount of plaintext information that needs | of bits) of the minimum amount of plaintext information that needs | |||
| to be recovered from cipher text in order to learn the entire | to be recovered from cipher text in order to learn the entire | |||
| plain text that was encrypted. [SP63] (See: entropy.) | plain text that was encrypted. [SP63] (See: entropy.) | |||
| $ unclassified | $ unclassified | |||
| (I) Not classified. | (I) Not classified. | |||
| $ unencrypted | $ unencrypted | |||
| (I) Not encrypted. | (I) Not encrypted. | |||
| $ unforgeable | $ unforgeable | |||
| (I) /cryptography/ The property of a cryptographic data structure | (I) /cryptography/ The property of a cryptographic data structure | |||
| (i.e., a data structure that is defined using one or more | (i.e., a data structure that is defined using one or more | |||
| cryptographic functions; e.g., see digital certificate) that makes | cryptographic functions, e.g., see digital certificate) that makes | |||
| it computationally infeasible to construct (i.e., compute) an | it computationally infeasible to construct (i.e., compute) an | |||
| unauthorized but correct value of the structure without having | unauthorized but correct value of the structure without having | |||
| knowledge of one of more keys. | knowledge of one of more keys. | |||
| Tutorial: This definition is narrower than general English usage, | Tutorial: This definition is narrower than general English usage, | |||
| where "unforgeable" means unable to be fraudulently created or | where "unforgeable" means unable to be fraudulently created or | |||
| duplicated. In that broader sense, anyone can forge a digital | duplicated. In that broader sense, anyone can forge a digital | |||
| certificate containing any set of data items whatsoever by | certificate containing any set of data items whatsoever by | |||
| generating the to-be-signed certificate and signing it with any | generating the to-be-signed certificate and signing it with any | |||
| private key whatsoever. But for PKI purposes, the forged data | private key whatsoever. But for PKI purposes, the forged data | |||
| skipping to change at page 262, line 12 ¶ | skipping to change at page 283, line 10 ¶ | |||
| 2. (I) A system component that (a) has not been evaluated or | 2. (I) A system component that (a) has not been evaluated or | |||
| examined for adherence to a specified security policy and, | examined for adherence to a specified security policy and, | |||
| therefore, (b) must be assumed to contain logic that might attempt | therefore, (b) must be assumed to contain logic that might attempt | |||
| to circumvent system security. | to circumvent system security. | |||
| $ UORA | $ UORA | |||
| (O) See: user-PIN ORA. | (O) See: user-PIN ORA. | |||
| $ update | $ update | |||
| See: certificate update and key update. | See: "certificate update" and "key update". | |||
| $ upgrade | $ upgrade | |||
| (I) /data security/ Increase the classification level of data | (I) /data security/ Increase the classification level of data | |||
| without changing the information content of the data. (Compare: | without changing the information content of the data. (See: | |||
| downgrade. See: regrade.) | classify, downgrade, regrade.) | |||
| $ URI | $ URI | |||
| (I) See: uniform resource identifier. | (I) See: uniform resource identifier. | |||
| $ URL | $ URL | |||
| (I) See: uniform resource locator. | (I) See: uniform resource locator. | |||
| $ URN | $ URN | |||
| (I) See: uniform resource name. | (I) See: uniform resource name. | |||
| $ user | $ user | |||
| (I) An active system entity that uses a product or service | (I) An active system entity that uses a product or service | |||
| provided by the system, or that accesses system resources to | provided by the system, or that accesses system resources to | |||
| produce a product or service of the system. (See: access, [R2504]. | produce a product or service of the system. (See: access, [R2504]. | |||
| Compare: authorized user, manager, operator, principal, subject, | Compare: authorized user, manager, operator, principal, privileged | |||
| subscriber, unauthorized user.) | user, subject, subscriber, unauthorized user.) | |||
| Usage: The term is used in many ways and could easily be | ||||
| misunderstood; therefore, ISDs that use this term SHOULD state a | ||||
| definition for it. | ||||
| - This term usually refers to an entity that has been authorized | Usage: ISDs that use this term SHOULD state a definition for it | |||
| because the term is used in many ways and could easily be | ||||
| misunderstood: | ||||
| - This term usually refers to an entity that has been authorized | ||||
| to access the system, but the term sometimes is used without | to access the system, but the term sometimes is used without | |||
| regard for whether access is authorized. | regard for whether access is authorized. | |||
| - This term usually refers to a living human being acting either | - This term usually refers to a living human being acting either | |||
| personally or in an organizational role, but the term may refer | personally or in an organizational role, but the term also may | |||
| to an automated process in the form of either hardware or | refer to an automated process in the form of hardware, | |||
| software or both, or to a set of persons, or to a set of | softwarr, or firmware; to a set of persons; or to a set of | |||
| processes | processes. | |||
| - ISDs SHOULD exclude the case of a mixed set containing both | - ISDs SHOULD exclude the case of a mixed set containing both | |||
| persons and processes. The exclusion is intended to prevent | persons and processes. The exclusion is intended to prevent | |||
| situations that might require a security policy to be | situations that might require a security policy to be | |||
| interpreted in two different and conflicting ways. | interpreted in two different and conflicting ways. | |||
| A user can be characterized as direct or indirect: | ||||
| - "Passive user": A system entity that is (a) outside the | ||||
| system's security perimeter *and* (b) can receive output from | ||||
| the system but cannot provide input or otherwise interact with | ||||
| the system. | ||||
| - "Active user": A system entity that is (a) inside the system's | ||||
| security perimeter *or* (b) can provide input or otherwise | ||||
| interact with the system. | ||||
| $ user authentication service | $ user authentication service | |||
| (I) A security service that verifies that the identity claimed by | (I) A security service that verifies the identity claimed by an | |||
| an entity that attempts to access the system. (See: | entity that attempts to access the system. (See: authentication, | |||
| authentication, user.) | user.) | |||
| $ User Datagram Protocol (UDP) | $ User Datagram Protocol (UDP) | |||
| (I) An Internet Standard, transport-layer protocol (RFC 768) that | (I) An Internet Standard, Transport-Layer protocol (RFC 768) that | |||
| delivers a sequence of datagrams from one computer to another in a | delivers a sequence of datagrams from one computer to another in a | |||
| computer network. (See: UPD flood.) | computer network. (See: UPD flood.) | |||
| Tutorial: UDP assumes that IP is the underlying protocol. UDP | Tutorial: UDP assumes that IP is the underlying protocol. UDP | |||
| enables application programs to send transaction-oriented data to | enables application programs to send transaction-oriented data to | |||
| other programs with minimal protocol mechanism. UDP does not | other programs with minimal protocol mechanism. UDP does not | |||
| provide reliable delivery, flow control, sequencing, or other end- | provide reliable delivery, flow control, sequencing, or other end- | |||
| to-end service guarantees that TCP does. | to-end service guarantees that TCP does. | |||
| $ user identity | $ user identity | |||
| skipping to change at page 263, line 50 ¶ | skipping to change at page 285, line 6 ¶ | |||
| $ UTCTime | $ UTCTime | |||
| (N) The ASN.1 data type "UTCTime" contains a calendar date | (N) The ASN.1 data type "UTCTime" contains a calendar date | |||
| (YYMMDD) and a time to a precision of either one minute (HHMM) or | (YYMMDD) and a time to a precision of either one minute (HHMM) or | |||
| one second (HHMMSS), where the time is either (a) Coordinated | one second (HHMMSS), where the time is either (a) Coordinated | |||
| Universal Time or (b) the local time followed by an offset that | Universal Time or (b) the local time followed by an offset that | |||
| enables Coordinated Universal Time to be calculated. Note: UTCTime | enables Coordinated Universal Time to be calculated. Note: UTCTime | |||
| has the Year 2000 problem. (See: Coordinated Universal Time, | has the Year 2000 problem. (See: Coordinated Universal Time, | |||
| GeneralizedTime.) | GeneralizedTime.) | |||
| $ v1 certificate | $ v1 certificate | |||
| (I) An abbreviation that ambiguously refers to either an "X.509 | (N) An abbreviation that ambiguously refers to either an "X.509 | |||
| public-key certificate in version 1 format" or an "X.509 attribute | public-key certificate in version 1 format" or an "X.509 attribute | |||
| certificate in version 1 format". | certificate in version 1 format". | |||
| Deprecated Usage: ISDs MAY use this term as an abbreviation for | Deprecated Usage: ISDs MAY use this term as an abbreviation of | |||
| "version 1 X.509 public-key certificate", but only after using the | "version 1 X.509 public-key certificate", but only after using the | |||
| full term at the first instance. Otherwise, the term is ambiguous, | full term at the first instance. Otherwise, the term is ambiguous, | |||
| because X.509 specifies both v1 public-key certificates and v1 | because X.509 specifies both v1 public-key certificates and v1 | |||
| attribute certificates. (See: X.509 attribute certificate, X.509 | attribute certificates. (See: X.509 attribute certificate, X.509 | |||
| public-key certificate.) | public-key certificate.) | |||
| $ v1 CRL | $ v1 CRL | |||
| (I) An abbreviation for "X.509 CRL in version 1 format". | (N) Abbreviation of "X.509 CRL in version 1 format". | |||
| Usage: ISDs MAY use this abbreviation, but SHOULD use the full | Usage: ISDs MAY use this abbreviation, but SHOULD use the full | |||
| term at its first occurrence and define the abbreviation there. | term at its first occurrence and define the abbreviation there. | |||
| $ v2 certificate | $ v2 certificate | |||
| (I) An abbreviation for "X.509 public-key certificate in version 2 | (N) Abbreviation of "X.509 public-key certificate in version 2 | |||
| format". | format". | |||
| Usage: ISDs MAY use this abbreviation, but SHOULD use the full | Usage: ISDs MAY use this abbreviation, but SHOULD use the full | |||
| term at its first occurrence and define the abbreviation there. | term at its first occurrence and define the abbreviation there. | |||
| $ v2 CRL | $ v2 CRL | |||
| (I) An abbreviation for "X.509 CRL in version 2 format". | (N) Abbreviation of "X.509 CRL in version 2 format". | |||
| Usage: ISDs MAY use this abbreviation, but SHOULD use the full | Usage: ISDs MAY use this abbreviation, but SHOULD use the full | |||
| term at its first occurrence and define the abbreviation there. | term at its first occurrence and define the abbreviation there. | |||
| $ v3 certificate | $ v3 certificate | |||
| (I) An abbreviation for "X.509 public-key certificate in version 3 | (N) Abbreviation of "X.509 public-key certificate in version 3 | |||
| format". | format". | |||
| Usage: ISDs MAY use this abbreviation, but SHOULD use the full | Usage: ISDs MAY use this abbreviation, but SHOULD use the full | |||
| term at its first occurrence and define the abbreviation there. | term at its first occurrence and define the abbreviation there. | |||
| $ valid certificate | $ valid certificate | |||
| 1. (I) A digital certificate that can be validated successfully. | 1. (I) A digital certificate that can be validated successfully. | |||
| (See: validate, verify.) | (See: validate, verify.) | |||
| 2. (I) A digital certificate for which the binding of the data | 2. (I) A digital certificate for which the binding of the data | |||
| skipping to change at page 264, line 49 ¶ | skipping to change at page 286, line 4 ¶ | |||
| 2. (I) A digital certificate for which the binding of the data | 2. (I) A digital certificate for which the binding of the data | |||
| items can be trusted. | items can be trusted. | |||
| $ valid signature | $ valid signature | |||
| (D) Synonym for "authentic signature". | (D) Synonym for "authentic signature". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; instead, say | Deprecated Term: ISDs SHOULD NOT use this term; instead, say | |||
| "authentic signature". This Glossary recommends saying "validate | "authentic signature". This Glossary recommends saying "validate | |||
| the certificate" and "verify the signature"; therefore, it would | the certificate" and "verify the signature"; therefore, it would | |||
| be inconsistent to say that a signature is "valid". (See: | be inconsistent to say that a signature is "valid". (See: | |||
| validate, verify.) | validate, verify.) | |||
| $ validate | $ validate | |||
| 1. (I) Establish the soundness or correctness of a construct. | 1. (I) Establish the soundness or correctness of a construct. | |||
| Example: certificate validation. (See: validate vs. verify.) | Example: certificate validation. (See: validate vs. verify.) | |||
| 2. (I) To officially approve something, sometimes in relation to a | 2. (I) To officially approve something, sometimes in relation to a | |||
| standard. Example: NIST validates cryptographic modules for | standard. Example: NIST validates cryptographic modules for | |||
| conformance with FIPS PUB 140 [FP140]. | conformance with FIPS PUB 140 [FP140]. | |||
| $ validate vs. verify | $ validate vs. verify | |||
| Usage: To ensure consistency and align with ordinary English | Usage: To ensure consistency and align with ordinary English | |||
| usage, ISDs SHOULD comply with the following two rules: | usage, ISDs SHOULD comply with the following two rules: | |||
| - Rule 1: Use "validate" when referring to a process intended to | - Rule 1: Use "validate" when referring to a process intended to | |||
| establish the soundness or correctness of a construct (e.g., | establish the soundness or correctness of a construct (e.g., | |||
| see: certificate validation). (See: validate.) | see: certificate validation). (See: validate.) | |||
| - Rule 2: Use "verify" when referring to a process intended to | - Rule 2: Use "verify" when referring to a process intended to | |||
| test or prove the truth or accuracy of a fact or value (e.g., | test or prove the truth or accuracy of a fact or value (e.g., | |||
| see: authenticate). (See: verify.) | see: authenticate). (See: verify.) | |||
| Tutorial: The Internet security community sometimes uses these two | Tutorial: The Internet security community sometimes uses these two | |||
| terms inconsistently, especially in a PKI context. Most often, | terms inconsistently, especially in a PKI context. Most often, | |||
| however, we say "verify the signature" but say "validate the | however, we say "verify the signature" but say "validate the | |||
| certificate". That is, we "verify" atomic truths but "validate" | certificate". That is, we "verify" atomic truths but "validate" | |||
| data structures, relationships, and systems that are composed of | data structures, relationships, and systems that are composed of | |||
| or depend on verified items. This usage has a basis in Latin: | or depend on verified items. This usage has a basis in Latin: | |||
| skipping to change at page 265, line 50 ¶ | skipping to change at page 287, line 6 ¶ | |||
| certificate, a certificate user verifies the digital signature on | certificate, a certificate user verifies the digital signature on | |||
| the certificate by performing calculations, verifies that the | the certificate by performing calculations, verifies that the | |||
| current time is within the certificate's validity period, and may | current time is within the certificate's validity period, and may | |||
| need to validate a certification path involving additional | need to validate a certification path involving additional | |||
| certificates. | certificates. | |||
| $ validation | $ validation | |||
| (I) See: validate vs. verify. | (I) See: validate vs. verify. | |||
| $ validity period | $ validity period | |||
| (I) A data item in a digital certificate that specifies the time | (I) /PKI/ A data item in a digital certificate that specifies the | |||
| period for which the binding between data items (especially | time period for which the binding between data items (especially | |||
| between the subject name and the public key value in a public-key | between the subject name and the public key value in a public-key | |||
| certificate) is valid, except if the certificate appears on a CRL | certificate) is valid, except if the certificate appears on a CRL | |||
| or the key appears on a CKL. | or the key appears on a CKL. (See: cryptoperiod, key lifetime.) | |||
| $ value-added network (VAN) | $ value-added network (VAN) | |||
| (I) A computer network or subnetwork (usually a commercial | (I) A computer network or subnetwork (usually a commercial | |||
| enterprise) that transmits, receives, and stores EDI transactions | enterprise) that transmits, receives, and stores EDI transactions | |||
| on behalf of its users. | on behalf of its users. | |||
| Tutorial: A VAN may also provide additional services, ranging from | Tutorial: A VAN may also provide additional services, ranging from | |||
| EDI format translation, to EDI-to-FAX conversion, to integrated | EDI format translation, to EDI-to-FAX conversion, to integrated | |||
| business systems. | business systems. | |||
| skipping to change at page 267, line 53 ¶ | skipping to change at page 289, line 9 ¶ | |||
| is employed by a wide range of users, then it is likely that there | is employed by a wide range of users, then it is likely that there | |||
| will be enough motivation for someone to launch an attack. | will be enough motivation for someone to launch an attack. | |||
| $ W3 | $ W3 | |||
| (D) Synonym for WWW. | (D) Synonym for WWW. | |||
| Deprecated Abbreviation: This abbreviation could be confused with | Deprecated Abbreviation: This abbreviation could be confused with | |||
| W3C; use "WWW" instead. | W3C; use "WWW" instead. | |||
| $ W3C | $ W3C | |||
| See: World Wide Web Consortium. | (N) See: World Wide Web Consortium. | |||
| $ war dialer | $ war dialer | |||
| (I) A computer program that automatically dials a series of | (I) /slang/ A computer program that automatically dials a series | |||
| telephone numbers to find lines connected to computer systems, and | of telephone numbers to find lines connected to computer systems, | |||
| catalogs those numbers so that a cracker can try to break the | and catalogs those numbers so that a cracker can try to break the | |||
| systems. | systems. | |||
| Deprecated Usage: This term could confuse international readers; | Deprecated Usage: ISDs that use this term SHOULD state a | |||
| therefore, ISDs that use it SHOULD state a definition for it. | definition for it because the term could confuse international | |||
| readers. | ||||
| $ Wassenaar Arrangement | $ Wassenaar Arrangement | |||
| (N) The Wassenaar Arrangement on Export Controls for Conventional | (N) The Wassenaar Arrangement on Export Controls for Conventional | |||
| Arms and Dual-Use Goods and Technologies is a global, multilateral | Arms and Dual-Use Goods and Technologies is a global, multilateral | |||
| agreement approved by 33 countries in July 1996 to contribute to | agreement approved by 33 countries in July 1996 to contribute to | |||
| regional and international security and stability, by promoting | regional and international security and stability, by promoting | |||
| information exchange concerning, and greater responsibility in, | information exchange concerning, and greater responsibility in, | |||
| transfers of arms and dual-use items, thus preventing | transfers of arms and dual-use items, thus preventing | |||
| destabilizing accumulations. (See: International Traffic in Arms | destabilizing accumulations. (See: International Traffic in Arms | |||
| Regulations.) | Regulations.) | |||
| skipping to change at page 269, line 11 ¶ | skipping to change at page 290, line 17 ¶ | |||
| $ watermarking | $ watermarking | |||
| See: digital watermarking. | See: digital watermarking. | |||
| $ weak key | $ weak key | |||
| (I) In the context of a particular cryptographic algorithm, a key | (I) In the context of a particular cryptographic algorithm, a key | |||
| value that provides poor security. | value that provides poor security. | |||
| Example: The DEA has four "weak keys" [Schn] for which encryption | Example: The DEA has four "weak keys" [Schn] for which encryption | |||
| produces the same result as decryption. It also has ten pairs of | produces the same result as decryption. It also has ten pairs of | |||
| "semi-weak keys" [Schn] (also known as "dual keys" [FP074]) for | "semi-weak keys" [Schn] (a.k.a. "dual keys" [FP074]) for which | |||
| which encryption with one key in the pair produces the same result | encryption with one key in the pair produces the same result as | |||
| as decryption with the other key. | decryption with the other key. | |||
| $ web, Web | $ web, Web | |||
| 1. (C) /not capitalized/ ISD SHOULD NOT capitalize "web" when | 1. (I) /not capitalized/ ISDs SHOULD NOT capitalize "web" when | |||
| using the term (usually as an adjective) to refer generically to | using the term (usually as an adjective) to refer generically to | |||
| technology -- such as web browsers, web servers, HTTP, and HTML -- | technology -- such as web browsers, web servers, HTTP, and HTML -- | |||
| that is used in the Web or similar networks. | that is used in the Web or similar networks. | |||
| 2. (I) /capitalized/ ISDs SHOULD capitalize "Web" when using the | 2. (I) /capitalized/ ISDs SHOULD capitalize "Web" when using the | |||
| term (as either a noun or an adjective) to refer specifically to | term (as either a noun or an adjective) to refer specifically to | |||
| the World Wide Web. (Similarly, see: internet.) | the World Wide Web. (Similarly, see: internet.) | |||
| Usage: IETF documents SHOULD spell out "World Wide Web" fully at | Usage: ISDs SHOULD NOT use "web" or "Web" in a way that might | |||
| the first instance of usage and MUST use "Web" and "web" | confuse these definitions with the PGP "web of trust". When using | |||
| especially carefully where confusion with the PGP web of trust is | Web as an abbreviation for "World Wide Web", ISDs SHOULD fully | |||
| possible. | spell out the term at the first instance of usage. | |||
| $ web of trust | $ web of trust | |||
| (D) /PGP/ A trust-file PKI technique used for building a file of | (D) /PGP/ A trust-file PKI technique used for building a file of | |||
| trusted public keys by making personal judgments about being able | trusted public keys by making personal judgments about being able | |||
| to trust certain people to be holding properly certified keys of | to trust certain people to be holding properly certified keys of | |||
| other people. (See: certification hierarchy, mesh PKI.) | other people. (See: certification hierarchy, mesh PKI, trust | |||
| anchor, web, Web.) | ||||
| Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | |||
| in a potentially misleading way. This PKI technique does not | in a potentially misleading way. This PKI technique does not | |||
| depend on World Wide Web technology. | depend on World Wide Web technology. | |||
| $ web server | $ web server | |||
| (I) A software process that runs on a host computer connected to a | (I) A software process that runs on a host computer connected to a | |||
| network and responds to HTTP requests made by client web browsers. | network and responds to HTTP requests made by client web browsers. | |||
| $ WEP | $ WEP | |||
| (N) See: Wired Equivalency Protocol. | (N) See: Wired Equivalency Protocol. | |||
| $ Wired Equivalent Privacy (WEP) | $ Wired Equivalent Privacy (WEP) | |||
| (N) A cryptographic protocol defined in the IEEE 802.11 standard | (N) A cryptographic protocol that is defined in the IEEE 802.11 | |||
| encapsulate the packets on wireless LANs. (Frequently referred to | standard and encapsulates the packets on wireless LANs. Usage: | |||
| as "Wired Equivalency Protocol".) | a.k.a. "Wired Equivalency Protocol". | |||
| Tutorial: The WEP design, which uses RC4 to encrypt the plaintext | Tutorial: The WEP design, which uses RC4 to encrypt both the plain | |||
| and a CRC, has been shown to be flawed in multiple ways; and it | text and a CRC, has been shown to be flawed in multiple ways; and | |||
| also has often been flawed in implementation and management. | it also has often suffered from flawed implementation and | |||
| management. | ||||
| $ wiretapping | $ wiretapping | |||
| (I) An attack that intercepts and accesses information contained | (I) An attack that intercepts and accesses information contained | |||
| in a data flow in a communication system. (See: active | in a data flow in a communication system. (See: active | |||
| wiretapping, end-to-end encryption, passive wiretapping.) | wiretapping, end-to-end encryption, passive wiretapping.) | |||
| Usage: Although the term originally referred to making a | Usage: Although the term originally referred to making a | |||
| mechanical connection to an electrical conductor that links two | mechanical connection to an electrical conductor that links two | |||
| nodes, it is now used to refer to accessing information from any | nodes, it is now used to refer to accessing information from any | |||
| sort of medium used for a link or even from a node, such as a | sort of medium used for a link or even from a node, such as a | |||
| gateway or subnetwork switch. | gateway or subnetwork switch. | |||
| Tutorial: Wiretapping can be characterized according to intent: | Tutorial: Wiretapping can be characterized according to intent: | |||
| - "Active wiretapping" attempts to alter the data or otherwise | - "Active wiretapping" attempts to alter the data or otherwise | |||
| affect the flow. | affect the flow. | |||
| - "Passive wiretapping" only attempts to observe the data flow | - "Passive wiretapping" only attempts to observe the data flow | |||
| and gain knowledge of information contained in it. | and gain knowledge of information contained in it. | |||
| $ work factor | $ work factor | |||
| 1. (I) /COMPUSEC/ The estimated amount of effort or time that can | 1. (I) /COMPUSEC/ The estimated amount of effort or time that can | |||
| be expected to be expended by a potential intruder to penetrate a | be expected to be expended by a potential intruder to penetrate a | |||
| system, or defeat a particular countermeasure, when using | system, or defeat a particular countermeasure, when using | |||
| specified amounts of expertise and resources. (See: strength.) | specified amounts of expertise and resources. (See: strength.) | |||
| 2. (I) /cryptography/ The estimated amount of computing power and | 2. (I) /cryptography/ The estimated amount of computing power and | |||
| time needed to break a cryptographic system. | time needed to break a cryptographic system. | |||
| $ World Wide Web ("the Web", WWW) | $ World Wide Web ("the Web", WWW) | |||
| (N) The global, hypermedia-based collection of information and | (N) The global, hypermedia-based collection of information and | |||
| services that is available on Internet servers and is accessed by | services that is available on Internet servers and is accessed by | |||
| browsers using Hypertext Transfer Protocol and other information | browsers using Hypertext Transfer Protocol and other information | |||
| retrieval mechanisms. (See: web vs. Web, [R2084].) | retrieval mechanisms. (See: web vs. Web, [R2084].) | |||
| $ World Wide Web Consortium (W3C) | $ World Wide Web Consortium (W3C) | |||
| (N) Created in October 1994 to develop and standardize protocols | (N) Created in October 1994 to develop and standardize protocols | |||
| to promote the evolution and interoperability of the Web, and now | to promote the evolution and interoperability of the Web, and now | |||
| consisting of over 300 member organizations (commercial firms, | consisting of hundreds of member organizations (commercial firms, | |||
| government agencies, schools, and other organizations). | government agencies, schools, and others). | |||
| Tutorial: W3C Recommendations are developed through a process | Tutorial: W3C Recommendations are developed through a process | |||
| similar to that of the standards published by other organizations, | similar to that of the standards published by other organizations, | |||
| such as the IETF. The W3 Recommendation Track (i.e., standards | such as the IETF. The W3 Recommendation Track (i.e., standards | |||
| track) has four levels of increasing maturity: Working, Candidate | track) has four levels of increasing maturity: Working, Candidate | |||
| Recommendation, Proposed Recommendation, and W3C Recommendation | Recommendation, Proposed Recommendation, and W3C Recommendation | |||
| W3C Recommendations are similar to the standards published by | W3C Recommendations are similar to the standards published by | |||
| other organizations. (Compare: Internet Standard, ISO.) | others organizations. (Compare: Internet Standard, ISO.) | |||
| $ worm | $ worm | |||
| (I) A computer program that can run independently, can propagate a | (I) A computer program that can run independently, can propagate a | |||
| complete working version of itself onto other hosts on a network, | complete working version of itself onto other hosts on a network, | |||
| and may consume system resources destructively. (See: Morris Worm, | and may consume system resources destructively. (See: mobile code, | |||
| virus.) | Morris Worm, virus.) | |||
| $ wrap | $ wrap | |||
| (D) To use cryptography to provide data confidentiality service | (D) To use cryptography to provide data confidentiality service | |||
| for keying material. (See: encrypt. Compare: seal.) | for keying material. (See: encrypt. Compare: seal.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term as defined here; | Deprecated Term: ISDs SHOULD NOT use this term as defined here; | |||
| the definition duplicates the meaning of other, standard terms. | the definition duplicates the meaning of other, standard terms. | |||
| Instead, use "encrypt" or another term that is specific with | Instead, use "encrypt" or another term that is specific with | |||
| regard to the mechanism being used. | regard to the mechanism being used. | |||
| skipping to change at page 272, line 27 ¶ | skipping to change at page 293, line 37 ¶ | |||
| attribute certificates associated with each of its public-key | attribute certificates associated with each of its public-key | |||
| certificates, and an attribute certificate may be issued by a | certificates, and an attribute certificate may be issued by a | |||
| different CA than the one that issued the associated public-key | different CA than the one that issued the associated public-key | |||
| certificate. | certificate. | |||
| An X.509 attribute certificate contains a sequence of data items | An X.509 attribute certificate contains a sequence of data items | |||
| and has a digital signature that is computed from that sequence. | and has a digital signature that is computed from that sequence. | |||
| In addition to the signature, an attribute certificate contains | In addition to the signature, an attribute certificate contains | |||
| items 1 through 9 listed below: | items 1 through 9 listed below: | |||
| 1. version Identifies v1. | 1. version Identifies v1. | |||
| 2. subject Is one of the following: | 2. subject Is one of the following: | |||
| 2a. baseCertificateID Issuer and serial number of an | 2a. baseCertificateID Issuer and serial number of an | |||
| X.509 public-key certificate. | X.509 public-key certificate. | |||
| 2b. subjectName DN of the subject. | 2b. subjectName DN of the subject. | |||
| 3. issuer DN of the issuer (the CA who signed). | 3. issuer DN of the issuer (the CA who signed). | |||
| 4. signature OID of algorithm that signed the cert. | 4. signature OID of algorithm that signed the cert. | |||
| 5. serialNumber Certificate serial number; | 5. serialNumber Certificate serial number; | |||
| an integer assigned by the issuer. | an integer assigned by the issuer. | |||
| 6. attCertValidityPeriod Validity period; a pair of UTCTime | 6. attCertValidityPeriod Validity period; a pair of UTCTime | |||
| values: "not before" and "not after". | values: "not before" and "not after". | |||
| 7. attributes Sequence of attributes describing the | 7. attributes Sequence of attributes describing the | |||
| subject. | subject. | |||
| 8. issuerUniqueId Optional, when a DN is not sufficient. | 8. issuerUniqueId Optional, when a DN is not sufficient. | |||
| 9. extensions Optional. | 9. extensions Optional. | |||
| $ X.509 authority revocation list | ||||
| (N) An ARL in one of the formats defined by X.509 -- version 1 | ||||
| (v1) or version 2 (v2). A specialized kind of certificate | ||||
| revocation list. | ||||
| $ X.509 certificate | $ X.509 certificate | |||
| (N) Synonym for "X.509 public-key certificate". | (N) Synonym for "X.509 public-key certificate". | |||
| Usage: ISDs MAY use this term as an abbreviation for "X.509 | Usage: ISDs MAY use this term as an abbreviation of "X.509 public- | |||
| public-key certificate", but only after using the full term at the | key certificate", but only after using the full term at the first | |||
| first instance. Otherwise, the term is ambiguous, because X.509 | instance. Otherwise, the term is ambiguous, because X.509 | |||
| specifies both public-key certificates and attribute certificates. | specifies both public-key certificates and attribute certificates. | |||
| (See: X.509 attribute certificate, X.509 public-key certificate.) | (See: X.509 attribute certificate, X.509 public-key certificate.) | |||
| Deprecated Usage: ISDs SHOULD NOT use this term as an abbreviation | Deprecated Usage: ISDs SHOULD NOT use this term as an abbreviation | |||
| for "X.509 attribute certificate", because the term is likely to | of "X.509 attribute certificate", because the term is much more | |||
| be misunderstood to mean "X.509 public-key certificate". | commonly used to mean "X.509 public-key certificate" and, | |||
| therefore, is likely to be misunderstood. | ||||
| $ X.509 certificate revocation list (CRL) | $ X.509 certificate revocation list (CRL) | |||
| (N) A CRL in one of the formats defined by X.509 -- version 1 (v1) | (N) A CRL in one of the formats defined by X.509 -- version 1 (v1) | |||
| or version 2 (v2). (The v1 and v2 designations for an X.509 CRL | or version 2 (v2). (The v1 and v2 designations for an X.509 CRL | |||
| are disjoint from the v1 and v2 designations for an X.509 public- | are disjoint from the v1 and v2 designations for an X.509 public- | |||
| key certificate, and from the v1 designation for an X.509 | key certificate, and from the v1 designation for an X.509 | |||
| attribute certificate.) (See: certificate revocation.) | attribute certificate.) (See: certificate revocation.) | |||
| Usage: ISDs SHOULD NOT refer to an X.509 CRL as a digital | Usage: ISDs SHOULD NOT refer to an X.509 CRL as a digital | |||
| certificate; however, note that an X.509 CRL does meet this | certificate; however, note that an X.509 CRL does meet this | |||
| Glossary's definition of "digital certificate". Like a digital | Glossary's definition of "digital certificate". That is, like a | |||
| certificate, an X.509 CRL makes an assertion and is signed by a | digital certificate, an X.509 CRL makes an assertion and is signed | |||
| CA. But instead of binding a key or other attributes to a subject, | by a CA. But instead of binding a key or other attributes to a | |||
| an X.509 CRL asserts that certain previously-issued X.509 | subject, an X.509 CRL asserts that certain previously issued, | |||
| certificates have been revoked. | X.509 certificates have been revoked. | |||
| Tutorial: An X.509 CRL contains a sequence of data items and has a | Tutorial: An X.509 CRL contains a sequence of data items and has a | |||
| digital signature computed on that sequence. In addition to the | digital signature computed on that sequence. In addition to the | |||
| signature, both v1 and v2 contain items 2 through 6b listed below. | signature, both v1 and v2 contain items 2 through 6b listed below. | |||
| Version 2 contains item 1 and may optionally contain 6c and 7. | Version 2 contains item 1 and may optionally contain 6c and 7. | |||
| 1. version Optional. If present, identifies v2. | 1. version Optional. If present, identifies v2. | |||
| 2. signature OID of the algorithm that signed CRL. | 2. signature OID of the algorithm that signed CRL. | |||
| 3. issuer DN of the issuer (the CA who signed). | 3. issuer DN of the issuer (the CA who signed). | |||
| 4. thisUpdate A UTCTime value. | 4. thisUpdate A UTCTime value. | |||
| 5. nextUpdate A UTCTime value. | 5. nextUpdate A UTCTime value. | |||
| 6. revokedCertificates 3-tuples of 6a, 6b, and (optional) 6c: | 6. revokedCertificates 3-tuples of 6a, 6b, and (optional) 6c: | |||
| 6a. userCertificate A certificate's serial number. | 6a. userCertificate A certificate's serial number. | |||
| 6b. revocationDate UTCTime value for the revocation date. | 6b. revocationDate UTCTime value for the revocation date. | |||
| 6c. crlEntryExtensions Optional. | 6c. crlEntryExtensions Optional. | |||
| 7. crlExtensions Optional. | 7. crlExtensions Optional. | |||
| $ X.509 public-key certificate | $ X.509 public-key certificate | |||
| (N) A public-key certificate in one of the formats defined by | (N) A public-key certificate in one of the formats defined by | |||
| X.509 -- version 1 (v1), version 2 (v2), or version 3 (v3). (The | X.509 -- version 1 (v1), version 2 (v2), or version 3 (v3). (The | |||
| v1 and v2 designations for an X.509 public-key certificate are | v1 and v2 designations for an X.509 public-key certificate are | |||
| disjoint from the v1 and v2 designations for an X.509 CRL, and | disjoint from the v1 and v2 designations for an X.509 CRL, and | |||
| from the v1 designation for an X.509 attribute certificate.) | from the v1 designation for an X.509 attribute certificate.) | |||
| Tutorial: An X.509 public-key certificate contains a sequence of | Tutorial: An X.509 public-key certificate contains a sequence of | |||
| data items and has a digital signature computed on that sequence. | data items and has a digital signature computed on that sequence. | |||
| skipping to change at page 274, line 4 ¶ | skipping to change at page 295, line 9 ¶ | |||
| Tutorial: An X.509 public-key certificate contains a sequence of | Tutorial: An X.509 public-key certificate contains a sequence of | |||
| data items and has a digital signature computed on that sequence. | data items and has a digital signature computed on that sequence. | |||
| In addition to the signature, all three versions contain items 1 | In addition to the signature, all three versions contain items 1 | |||
| through 7 listed below. Only v2 and v3 certificates may also | through 7 listed below. Only v2 and v3 certificates may also | |||
| contain items 8 and 9, and only v3 may contain item 10. | contain items 8 and 9, and only v3 may contain item 10. | |||
| 1. version Identifies v1, v2, or v3. | 1. version Identifies v1, v2, or v3. | |||
| 2. serialNumber Certificate serial number; | 2. serialNumber Certificate serial number; | |||
| an integer assigned by the issuer. | an integer assigned by the issuer. | |||
| 3. signature OID of algorithm that was used to | 3. signature OID of algorithm that was used to | |||
| sign the certificate. | sign the certificate. | |||
| 4. issuer DN of the issuer (the CA who signed). | 4. issuer DN of the issuer (the CA who signed). | |||
| 5. validity Validity period; a pair of UTCTime | 5. validity Validity period; a pair of UTCTime | |||
| values: "not before" and "not after". | values: "not before" and "not after". | |||
| 6. subject DN of entity who owns the public key. | 6. subject DN of entity who owns the public key. | |||
| 7. subjectPublicKeyInfo Public key value and algorithm OID. | 7. subjectPublicKeyInfo Public key value and algorithm OID. | |||
| 8. issuerUniqueIdentifier Defined for v2, v3; optional. | 8. issuerUniqueIdentifier Defined for v2, v3; optional. | |||
| 9. subjectUniqueIdentifier Defined for v2, v2; optional. | 9. subjectUniqueIdentifier Defined for v2, v2; optional. | |||
| 10. extensions Defined only for v3; optional. | 10. extensions Defined only for v3; optional. | |||
| $ X9 | $ X9 | |||
| See: (Accredited Standards Committee X9 under) ANSI. | See: "Accredited Standards Committee X9" under "ANSI". | |||
| $ XML | $ XML | |||
| (N) See: Extensible Markup Language. | (N) See: Extensible Markup Language. | |||
| $ XML-Signature. | $ XML-Signature. | |||
| (N) A W3C Recommendation (i.e. approved standard) that specifies | (N) A W3C Recommendation (i.e. approved standard) that specifies | |||
| XML syntax and processing rules for creating and representing | XML syntax and processing rules for creating and representing | |||
| digital signatures (based on asymmetric cryptography) that can be | digital signatures (based on asymmetric cryptography) that can be | |||
| applied to any digital content (i.e., any data object) including | applied to any digital content (i.e., any data object) including | |||
| other XML material. | other XML material. | |||
| $ XTACACS | $ XTACACS | |||
| (I) Cisco Corporation's implementation of the Terminal Access | (I) Cisco Corporation's implementation of the Terminal Access | |||
| Controller (TAC) Access Control System. This implementation | Controller (TAC) Access Control System. This implementation | |||
| enhances and extends the original TACACS. (See: TACACS, TACACS+.) | enhances and extends the original TACACS. (See: TACACS, TACACS+.) | |||
| $ Yellow Book | $ Yellow Book | |||
| (D) Synonym for "Computer Security Requirements: Guidance for | (D) /slang/ Synonym for "Computer Security Requirements: Guidance | |||
| Applying the [U.S.] Department of Defense Trusted Computer System | for Applying the [U.S.] Department of Defense Trusted Computer | |||
| Evaluation Criteria in Specific Environments" [CSC3] (See: (first | System Evaluation Criteria in Specific Environments" [CSC3] (See: | |||
| law under) Courtney's laws). | "first law" under "Courtney's laws".) | |||
| Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | |||
| that or any other document. Instead, use the full proper name of | that or any other document. Instead, use the full proper name of | |||
| the document or, in subsequent references, a conventional | the document or, in subsequent references, a conventional | |||
| abbreviation. (See: (Deprecated Usage under) Green Book, Rainbow | abbreviation. (See: Deprecated Usage under "Green Book", Rainbow | |||
| Series.) | Series.) | |||
| $ zero-knowledge proof | $ zero-knowledge proof | |||
| (I) /cryptography/ A proof-of-possession protocol whereby a system | (I) /cryptography/ A proof-of-possession protocol whereby a system | |||
| entity can prove possession of some information to another entity, | entity can prove possession of some information to another entity, | |||
| without revealing any of that information. (See: proof-of- | without revealing any of that information. (See: proof-of- | |||
| possession protocol.) | possession protocol.) | |||
| $ zeroize | $ zeroize | |||
| 1. (I) Synonym for "purge". Usage: Particularly with regard to | 1. (I) Synonym for "purge". Usage: Particularly with regard to | |||
| erasing keys that are stored in a cryptographic module. | erasing keys that are stored in a cryptographic module. | |||
| 2. (O) Erase electronically stored data by altering the contents | 2. (O) Erase electronically stored data by altering the contents | |||
| of the data storage so as to prevent the recovery of the data. | of the data storage so as to prevent the recovery of the data. | |||
| [FP140] | [FP140] | |||
| $ zombie | $ zombie | |||
| (I) An Internet host computer that has been surreptitiously | (I) /slang/ An Internet host computer that has been | |||
| penetrated by an intruder that installed malicious daemon software | surreptitiously penetrated by an intruder that installed malicious | |||
| to cause the host to operate as an accomplice in attacking other | daemon software to cause the host to operate as an accomplice in | |||
| hosts, particularly in distributed attacks that attempt denial of | attacking other hosts, particularly in distributed attacks that | |||
| service through flooding. | attempt denial of service through flooding. | |||
| Deprecated Term: It is likely that other cultures have different | Deprecated Term: It is likely that other cultures use different | |||
| metaphors for this concept. Therefore, to ensure international | metaphors for this concept. Therefore, to avoid international | |||
| understanding, ISDs SHOULD NOT use this term. (See: (Deprecated | misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated | |||
| Usage under) Green Book.) | Usage under "Green Book".) | |||
| $ zone of control | $ zone of control | |||
| (O) /EMSEC/ Synonym for "inspectable space". [C4009] (See: | (O) /EMSEC/ Synonym for "inspectable space". [C4009] (See: | |||
| TEMPEST.) | TEMPEST.) | |||
| 5. References | 5. Informative References | |||
| This Glossary focuses on the Internet Standards Process. Therefore, | This Glossary focuses on the Internet Standards Process. Therefore, | |||
| this set of references emphasizes international, governmental, and | this set of references emphasizes international, governmental, and | |||
| industry standards documents. | industry standards documents. RFCs referenced in Glossary entries are | |||
| listed here if they are specifically security-relevant; other | ||||
| referenced RFCs are only mentioned by number (e.g., see "RFC 959" in | ||||
| the entry for "File Transport Protocol"). | ||||
| [A1523] American National Standards Institute, "American National | [A1523] American National Standards Institute, "American National | |||
| Standard Telecomm Glossary", ANSI T1.523-2001. | Standard Telecomm Glossary", ANSI T1.523-2001. | |||
| [A3092] ---, "American National Standard Data Encryption Algorithm", | [A3092] ---, "American National Standard Data Encryption Algorithm", | |||
| ANSI X3.92-1981, 30 Dec 1980. | ANSI X3.92-1981, 30 December 1980. | |||
| [A9009] ---, "Financial Institution Message Authentication | [A9009] ---, "Financial Institution Message Authentication | |||
| (Wholesale)", ANSI X9.9-1986, 15 Aug 1986. | (Wholesale)", ANSI X9.9-1986, 15 August 1986. | |||
| [A9017] ---, "Financial Institution Key Management (Wholesale)", | [A9017] ---, "Financial Institution Key Management (Wholesale)", | |||
| X9.17, 4 Apr 1985. [Defines procedures for the manual and | X9.17, 4 April 1985. (Defines procedures for manual and | |||
| automated management of keying material and uses DES to | automated management of keying material and uses DES to | |||
| provide key management for a variety of operational | provide key management for a variety of operational | |||
| environments.] | environments.) | |||
| [A9042] ---, "Public key Cryptography for the Financial Service | [A9042] ---, "Public key Cryptography for the Financial Service | |||
| Industry: Agreement of Symmetric Keys Using Diffie-Hellman | Industry: Agreement of Symmetric Keys Using Diffie-Hellman | |||
| and MQV Algorithms", X9.42, 29 Jan 1999. | and MQV Algorithms", X9.42, 29 January 1999. | |||
| [A9052] ---, "Triple Data Encryption Algorithm Modes of Operation", | [A9052] ---, "Triple Data Encryption Algorithm Modes of Operation", | |||
| X9.52-1998, ANSI approval 9 Nov 1998. | X9.52-1998, ANSI approval 9 November 1998. | |||
| [A9062] ---, "Public Key Cryptography for the Financial Services | [A9062] ---, "Public Key Cryptography for the Financial Services | |||
| Industry: The Elliptic Curve Digital Signature Algorithm | Industry: The Elliptic Curve Digital Signature Algorithm | |||
| (ECDSA)", X9.62-1998, ANSI approval 7 Jan 1999. | (ECDSA)", X9.62-1998, ANSI approval 7 January 1999. | |||
| [A9063] ---, "---: Key Agreement and Key Transport Using Elliptic | [A9063] ---, "---: Key Agreement and Key Transport Using Elliptic | |||
| Curve Cryptography", X9.63-2001. | Curve Cryptography", X9.63-2001. | |||
| [ABA] American Bar Association, "Digital Signature Guidelines: | [ABA] American Bar Association, "Digital Signature Guidelines: | |||
| Legal Infrastructure for Certification Authorities and | Legal Infrastructure for Certification Authorities and | |||
| Secure Electronic Commerce", Chicago, IL, 1 Aug 1996. | Secure Electronic Commerce", Chicago, IL, 1 August 1996. | |||
| [ACM] Association for Computing Machinery, "Communications of the | [ACM] Association for Computing Machinery, "Communications of the | |||
| ACM", Jul 1998 issue with: M. Yeung, "Digital Watermarking"; | ACM", July 1998 issue with: M. Yeung, "Digital | |||
| N. Memom and P. Wong, "Protecting Digital Media Content"; | Watermarking"; N. Memom and P. Wong, "Protecting Digital | |||
| and S. Craver, B.-L. Yeo, and M. Yeung, "Technical Trials | Media Content"; and S. Craver, B.-L. Yeo, and M. Yeung, | |||
| and Legal Tribulations". | "Technical Trials and Legal Tribulations". | |||
| [Ande] J. Anderson, "Computer Security Technology Planning Study", | [Ande] Anderson, J., "Computer Security Technology Planning Study", | |||
| ESD-TR-73-51, Vols. I and II, USAF Electronics Systems Div., | ESD-TR-73-51, Vols. I and II, USAF Electronics Systems Div., | |||
| Bedford, MA, Oct 1972. (Available as AD-758206 and -772806, | Bedford, MA, October 1972. (Available as AD-758206 and - | |||
| National Technical Information Service, Springfield, VA.) | 772806, National Technical Information Service, Springfield, | |||
| VA.) | ||||
| [ANSI] American National Standards Institute, "Role Based Access | [ANSI] American National Standards Institute, "Role Based Access | |||
| Control", Secretariat, Information Technology Industry | Control", Secretariat, Information Technology Industry | |||
| Council, BSR INCITS 359, DRAFT, 10 Nov 2003. | Council, BSR INCITS 359, DRAFT, 10 November 2003. | |||
| [Army] U.S. Army Corps of Engineers, "Electromagnetic Pulse (EMP) | [Army] U.S. Army Corps of Engineers, "Electromagnetic Pulse (EMP) | |||
| and Tempest Protection for Facilities", EP 1110-3-2, 31 Dec | and Tempest Protection for Facilities", EP 1110-3-2, 31 | |||
| 1990. | December 1990. | |||
| [B1822] Bolt Baranek and Newman Inc., "Appendix H: Interfacing a | [B1822] Bolt Baranek and Newman Inc., "Appendix H: Interfacing a | |||
| Host to a Private Line Interface" in "Specifications for the | Host to a Private Line Interface", in "Specifications for | |||
| Interconnection of a Host and an IMP", BBN Report No. 1822, | the Interconnection of a Host and an IMP", BBN Report No. | |||
| revised, Dec 1983. | 1822, revised, December 1983. | |||
| [B4799] ---, "A History of the Arpanet: The First Decade", BBN | [B4799] ---, "A History of the Arpanet: The First Decade", BBN | |||
| Report No. 4799, Apr 1981. | Report No. 4799, April 1981. | |||
| [BS7799] British Standards Institution, "Information Security | [BS7799] British Standards Institution, "Information Security | |||
| Management, Part 1: Code of Practice for Information | Management, Part 1: Code of Practice for Information | |||
| Security Management", BS 7799-1:1999, effective 15 May 1999. | Security Management", BS 7799-1:1999, 15 May 1999. | |||
| ---, ---, "Part 2: Specification for Information Security | ---, ---, "Part 2: Specification for Information Security | |||
| Management Systems", BS 7799-2:1999, effective 15 May 1999. | Management Systems", BS 7799-2:1999, 15 May 1999. | |||
| [Bell] D. Bell and L. LaPadula, "Secure Computer Systems: | [Bell] Bell, D. and L. LaPadula, "Secure Computer Systems: | |||
| Mathematical Foundations and Model", M74-244, The MITRE | Mathematical Foundations and Model", M74-244, The MITRE | |||
| Corporation, Bedford, MA, May 1973. (Available as AD-771543, | Corporation, Bedford, MA, May 1973. (Available as AD-771543, | |||
| National Technical Information Service, Springfield, VA.) | National Technical Information Service, Springfield, VA.) | |||
| [Biba] K. Biba, "Integrity Considerations for Secure Computer | [Biba] K. Biba, "Integrity Considerations for Secure Computer | |||
| Systems", ESD-TR-76-372, USAF Electronic Systems Division, | Systems", ESD-TR-76-372, USAF Electronic Systems Division, | |||
| Bedford, MA, Apr 1977. | Bedford, MA, April 1977. | |||
| [BN89] D. Brewer and M. Nash, "The Chinese wall security policy", | [BN89] Brewer, D. and M. Nash, "The Chinese wall security policy", | |||
| in "Proceedings of IEEE Symposium on Security and Privacy", | in "Proceedings of IEEE Symposium on Security and Privacy", | |||
| May 1989, pp. 205-214. | May 1989, pp. 205-214. | |||
| [C4009] Committee National Security System, "National Information | [C4009] Committee on National Security Systems (U.S. Government), | |||
| Assurance (IA) Glossary", CNSS Instruction No. 4009, revised | "National Information Assurance (IA) Glossary", CNSS | |||
| May 2003. | Instruction No. 4009, revised May 2003. | |||
| [CCIB] Common Criteria Implementation Board, "Common Criteria for | [CCIB] Common Criteria Implementation Board, "Common Criteria for | |||
| Information Technology Security Evaluation, Part 1: | Information Technology Security Evaluation, Part 1: | |||
| Introduction and General Model", ver. 2.0, CCIB-98-026, May | Introduction and General Model", version 2.0, CCIB-98-026, | |||
| 1998. | May 1998. | |||
| [Chau] D. Chaum, "Untraceable Electronic Mail, Return Addresses, | [Chau] D. Chaum, "Untraceable Electronic Mail, Return Addresses, | |||
| and Digital Pseudonyms", in "Communications of the ACM", | and Digital Pseudonyms", in "Communications of the ACM", | |||
| vol. 24, no. 2, Feb 1981, pp. 84-88. | vol. 24, no. 2, February 1981, pp. 84-88. | |||
| [Cheh] M. Cheheyl, M. Gasser, G. Huff, and J. Millen, "Verifying | [Cheh] Cheheyl, M., Gasser, M., Huff, G., and J. Millen, "Verifying | |||
| Security", in "ACM Computing Surveys", vol. 13, no. 3, Sep | Security", in "ACM Computing Surveys", vol. 13, no. 3, | |||
| 1981, pp. 279-339. | September 1981, pp. 279-339. | |||
| [Chris] M. Chrissis et al, 1993. "SW-CMM [Capability Maturity Model | [Chris] Chrissis, M. et al, 1993. "SW-CMM [Capability Maturity Model | |||
| for Software Version", Release 3.0, Software Engineering | for Software Version", Release 3.0, Software Engineering | |||
| Institute, Carnegie Mellon University, Aug 1996. | Institute, Carnegie Mellon University, August 1996. | |||
| [CIPSO] Trusted Systems Interoperability Working Group, "Common IP | [CIPSO] Trusted Systems Interoperability Working Group, "Common IP | |||
| Security Option", ver. 2.3, 9 Mar 1993. | Security Option", version 2.3, 9 March 1993. | |||
| [Clark] D. Clark and D. Wilson, "A Comparison of Commercial and | [Clark] Clark, D. and D. Wilson, "A Comparison of Commercial and | |||
| Military computer Security Policies", in "Proceedings of the | Military computer Security Policies", in "Proceedings of the | |||
| IEEE Symposium on Security and Privacy", Apr 1987, pp. 184- | IEEE Symposium on Security and Privacy", April 1987, pp. | |||
| 194. | 184-194. | |||
| [Cons] NSA, "Consistency Instruction Manual for Development of U.S. | ||||
| Government Protection Profiles for Use in Basic Robustness | ||||
| Environments", Release 2.0, 1 March 2004 | ||||
| [CSC1] U.S. DoD Computer Security Center, "Department of Defense | [CSC1] U.S. DoD Computer Security Center, "Department of Defense | |||
| Trusted Computer System Evaluation Criteria", CSC-STD-001- | Trusted Computer System Evaluation Criteria", CSC-STD-001- | |||
| 83, 15 Aug 1983. (Superseded by [DoD1].) | 83, 15 August 1983. (Superseded by [DoD1].) | |||
| [CSC2] ---, "Department of Defense Password Management Guideline", | [CSC2] ---, "Department of Defense Password Management Guideline", | |||
| CSC-STD-002-85, 12 Apr 1985. | CSC-STD-002-85, 12 April 1985. | |||
| [CSC3] ---, "Computer Security Requirements: Guidance for Applying | [CSC3] ---, "Computer Security Requirements: Guidance for Applying | |||
| the Department of Defense Trusted Computer System Evaluation | the Department of Defense Trusted Computer System Evaluation | |||
| Criteria in Specific Environments", CSC-STD-003-85, 25 Jun | Criteria in Specific Environments", CSC-STD-003-85, 25 June | |||
| 1985. | 1985. | |||
| [CSOR] U.S. Department of Commerce, "General Procedures for | [CSOR] U.S. Department of Commerce, "General Procedures for | |||
| Registering Computer Security Objects", National Institute | Registering Computer Security Objects", National Institute | |||
| of Standards Interagency Report 5308, Dec 1993. | of Standards Interagency Report 5308, December 1993. | |||
| [Daem] J. Daemen and V. Rijmen, "Rijndael, the advanced encryption | [Daem] Daemen, J. and V. Rijmen, "Rijndael, the advanced encryption | |||
| standard" in "Dr. Dobb's Journal", vol. 26, no. 3, Mar 2001, | standard", in "Dr. Dobb's Journal", vol. 26, no. 3, March | |||
| pp.137-139. | 2001, pp.137-139. | |||
| [DC6/9] Director of Central Intelligence, "Physical Security | [DC6/9] Director of Central Intelligence, "Physical Security | |||
| Standards for Sensitive Compartemented [sic] Information | Standards for Sensitive Compartmented Information | |||
| Facilities ", DCI Directive 6/9, 18 Nov 2002. | Facilities", DCI Directive 6/9, 18 November 2002. | |||
| [Denn] D. Denning, "A Lattice Model of Secure Information Flow", in | [Denn] Denning, D., "A Lattice Model of Secure Information Flow", | |||
| "Communications of the ACM", vol. 19, no. 5, May 1976, pp. | in "Communications of the ACM", vol. 19, no. 5, May 1976, | |||
| 236-243. | pp. 236-243. | |||
| [Denns] D. Denning and P. Denning, "Data Security" in "ACM Computing | [Denns] Denning, D. and P. Denning, "Data Security", in "ACM | |||
| Surveys", vol. 11, no. 3, Sep 1979, pp. 227-249. | Computing Surveys", vol. 11, no. 3, September 1979, pp. 227- | |||
| 249. | ||||
| [DH76] W. Diffie and M. Hellman, "New Directions in Cryptography" | [DH76] Diffie, W. and M. Hellman, "New Directions in Cryptography", | |||
| in "IEEE Transactions on Information Theory", vol. IT-22, | in "IEEE Transactions on Information Theory", vol. IT-22, | |||
| no. 6, Nov 1976, pp. 644-654. | no. 6, November 1976, pp. 644-654. | |||
| [DoD1] U.S. DoD, "Department of Defense Trusted Computer System | [DoD1] U.S. DoD, "Department of Defense Trusted Computer System | |||
| Evaluation Criteria", DoD 5200.28-STD, 26 Dec 1985. | Evaluation Criteria", DoD 5200.28-STD, 26 December 1985. | |||
| (Supersedes [CSC1].) (Superseded by DoD Directive 8500.1.) | (Supersedes [CSC1].) (Superseded by DoD Directive 8500.1.) | |||
| [DoD2] ---, Directive 5200.28, "Security Requirements for Automated | ||||
| Information Systems (AISs)", 21 Mar 1988. (Superseded by DoD | ||||
| Directive 8500.1.) | ||||
| [DoD3] ---, "X.509 Certificate Policy for the United States | [DoD3] ---, "X.509 Certificate Policy for the United States | |||
| Department of Defense", version 7, 18 Dec 2002. | Department of Defense", version 7, 18 December 2002. | |||
| [DoD4] ---, "NSA Key Recovery Assessment Criteria", 8 Jun 1998. | [DoD4] ---, "NSA Key Recovery Assessment Criteria", 8 June 1998. | |||
| [DoD5] ---, Directive 5200.1, "DoD Information Security Program", | [DoD5] ---, Directive 5200.1, "DoD Information Security Program", | |||
| 13 Dec 1996. | 13 December 1996. | |||
| [DoD6] ---, "DoD Architecture Framework", Version 1, 30 Aug 2003. | [DoD6] ---, "DoD Architecture Framework", Version 1, 30 August | |||
| 2003. | ||||
| [ElGa] T. El Gamal, "A Public-Key Cryptosystem and a Signature | [ElGa] El Gamal, T., "A Public-Key Cryptosystem and a Signature | |||
| Scheme Based on Discrete Logarithms" in "IEEE Transactions | Scheme Based on Discrete Logarithms", in "IEEE Transactions | |||
| on Information Theory", vol. IT-31, no. 4, 1985, pp. 469- | on Information Theory", vol. IT-31, no. 4, 1985, pp. 469- | |||
| 472. | 472. | |||
| [EMV1] Europay International S.A., MasterCard International | [EMV1] Europay International S.A., MasterCard International | |||
| Incorporated, and Visa International Service Association, | Incorporated, and Visa International Service Association, | |||
| "EMV '96 Integrated Circuit Card Specification for Payment | "EMV '96 Integrated Circuit Card Specification for Payment | |||
| Systems", ver. 3.1.1, 31 May 1998. | Systems", version 3.1.1, 31 May 1998. | |||
| [EMV2] ---, "EMV '96 Integrated Circuit Card Terminal Specification | [EMV2] ---, "EMV '96 Integrated Circuit Card Terminal Specification | |||
| for Payment Systems", ver. 3.1.1, 31 May 1998. | for Payment Systems", version 3.1.1, 31 May 1998. | |||
| [EMV3] ---, EMV '96 Integrated Circuit Card Application | [EMV3] ---, "EMV '96 Integrated Circuit Card Application | |||
| Specification for Payment Systems", ver. 3.1.1, 31 May 1998. | Specification for Payment Systems", version 3.1.1, 31 May | |||
| 1998. | ||||
| [F1037] U.S. General Services Administration, "Glossary of | [F1037] U.S. General Services Administration, "Glossary of | |||
| Telecommunications Terms", FED STD 1037C, 7 Aug 1996. | Telecommunications Terms", FED STD 1037C, 7 August 1996. | |||
| [For94] W. Ford, "Computer Communications Security: Principles, | [For94] Ford, W., "Computer Communications Security: Principles, | |||
| Standard Protocols and Techniques", ISBN 0-13-799453-2, | Standard Protocols and Techniques", ISBN 0-13-799453-2, | |||
| 1994. | 1994. | |||
| [For97] W. Ford and M. Baum, "Secure Electronic Commerce: Building | [For97] --- and M. Baum, "Secure Electronic Commerce: Building the | |||
| the Infrastructure for Digital Signatures and Encryption", | Infrastructure for Digital Signatures and Encryption", ISBN | |||
| ISBN 0-13-476342-4, 1994. | 0-13-476342-4, 1994. | |||
| [FP031] U.S. Department of Commerce, "Guidelines for Automatic Data | [FP001] U.S. Department of Commerce, "Code for Information | |||
| Processing Physical Security and Risk Management", Federal | Interchange", Federal Information Processing Standards | |||
| Information Processing Standards Publication (FIPS PUB) 31, | Publication (FIPS PUB) 1, 1 November 1968. | |||
| Jun 1974. | ||||
| [FP031] ---, "Guidelines for Automatic Data Processing Physical | ||||
| Security and Risk Management", FIPS PUB 31, June 1974. | ||||
| [FP039] ---, "Glossary for Computer Systems Security", FIPS PUB 39, | [FP039] ---, "Glossary for Computer Systems Security", FIPS PUB 39, | |||
| 15 Feb 1976. | 15 February 1976. | |||
| [FP041] ---, "Computer Security Guidelines for Implementing the | [FP041] ---, "Computer Security Guidelines for Implementing the | |||
| Privacy Act of 1974", FIPS PUB 41, 30 May 1975. | Privacy Act of 1974", FIPS PUB 41, 30 May 1975. | |||
| [FP046] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25 Oct | [FP046] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25 | |||
| 1999. | October 1999. | |||
| [FP074] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25 Oct | [FP074] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25 | |||
| 1999. | October 1999. | |||
| [FP081] ---, "DES Modes of Operation", FIPS PUB 81, 2 Dec 1980. | [FP081] ---, "DES Modes of Operation", FIPS PUB 81, 2 December 1980. | |||
| [FP087] ---, "Guidelines for ADP Contingency Planning", FIPS PUB 87, | [FP087] ---, "Guidelines for ADP Contingency Planning", FIPS PUB 87, | |||
| 27 Mar 1981. | 27 March 1981. | |||
| [FP102] ---, "Guideline for Computer Security Certification and | [FP102] ---, "Guideline for Computer Security Certification and | |||
| Accreditation", FIPS PUB 102, 27 Sep 1983. | Accreditation", FIPS PUB 102, 27 September 1983. | |||
| [FP113] ---, "Computer Data Authentication", FIPS PUB 113, 30 May | [FP113] ---, "Computer Data Authentication", FIPS PUB 113, 30 May | |||
| 1985. | 1985. | |||
| [FP140] ---, "Security Requirements for Cryptographic Modules", FIPS | [FP140] ---, "Security Requirements for Cryptographic Modules", FIPS | |||
| PUB 140-2, 25 May 2001 (Change Notices 3 Dec 2002). | PUB 140-2, 25 May 2001; with change notice 4, 3 December | |||
| 2002. | ||||
| [FP151] ---, "Portable Operating System Interface (POSIX)--System | [FP151] ---, "Portable Operating System Interface (POSIX) -- System | |||
| Application Program Interface [C Language]", FIPS PUB 151-2, | Application Program Interface [C Language]", FIPS PUB 151-2, | |||
| 12 May 1993 | 12 May 1993 | |||
| [FP180] ---, "Secure Hash Standard", FIPS PUB 180-2, Aug 2000. | [FP180] ---, "Secure Hash Standard", FIPS PUB 180-2, August 2000; | |||
| with change notice 1, 25 February 2004. | ||||
| [FP185] ---, "Escrowed Encryption Standard", FIPS PUB 185, 9 Feb | [FP185] ---, "Escrowed Encryption Standard", FIPS PUB 185, 9 | |||
| 1994. | February 1994. | |||
| [FP186] ---, "Digital Signature Standard (DSS)", FIPS PUB 186-2, 27 | [FP186] ---, "Digital Signature Standard (DSS)", FIPS PUB 186-2, 27 | |||
| Jun 2000. | June 2000; with change notice 1, 5 October 2001. | |||
| [FP188] ---, "Standard Security Label for Information Transfer", | [FP188] ---, "Standard Security Label for Information Transfer", | |||
| FIPS PUB 188, 6 Sep 1994. | FIPS PUB 188, 6 September 1994. | |||
| [FP191] ---, "Guideline for the Analysis of Local Area Network | [FP191] ---, "Guideline for the Analysis of Local Area Network | |||
| Security", FIPS PUB 191, 9 Nov 1994. | Security", FIPS PUB 191, 9 November 1994. | |||
| [FP197] ---, "Advanced Encryption Standard", FIPS PUB 197, 26 Nov | [FP197] ---, "Advanced Encryption Standard", FIPS PUB 197, 26 | |||
| 2001. | November 2001. | |||
| [FPKI] U.S. Department of Commerce, "Public Key Infrastructure | [FP199] ---, "Standards for Security Categorization of Federal | |||
| (PKI) Technical Specifications: Part A--Technical Concept of | Information and Information Systems ", FIPS PUB 199, | |||
| Operations", National Institute of Standards, 4 Sep 1998. | December 2003. | |||
| [Gass] M. Gasser, "Building a Secure Computer System", Van Nostrand | [FPKI] ---, "Public Key Infrastructure (PKI) Technical | |||
| Reinhold Company, New York, 1988, ISBN 0-442-23022-2. | Specifications: Part A -- Technical Concept of Operations", | |||
| National Institute of Standards, 4 September 1998. | ||||
| [Gray] J. Gray and A. Reuter, "Transaction Processing: Concepts and | [Gass] Gasser, M., "Building a Secure Computer System", Van | |||
| Techniques", Morgan Kaufmann Publishers, Inc., 1993. | Nostrand Reinhold Company, New York, 1988, ISBN 0-442-23022- | |||
| 2. | ||||
| [Hafn] K. Hafner and M. Lyon, "Where Wizards Stay Up Late: The | [Gray] Gray, J. and A. Reuter, "Transaction Processing: Concepts | |||
| and Techniques", Morgan Kaufmann Publishers, Inc., 1993. | ||||
| [Hafn] Hafner, K. and M. Lyon, "Where Wizards Stay Up Late: The | ||||
| Origins of the Internet", Simon & Schuster, New York, 1996. | Origins of the Internet", Simon & Schuster, New York, 1996. | |||
| [Huff] G. Huff, "Trusted Computer Systems -- Glossary", MTR 8201, | [Huff] Huff, G., "Trusted Computer Systems -- Glossary", MTR 8201, | |||
| The MITRE Corporation, Mar 1981. | The MITRE Corporation, March 1981. | |||
| [I3166] International Standards Organization, "Codes for the | [I3166] International Standards Organization, "Codes for the | |||
| Representation of Names of countries and Their Subdivisions | Representation of Names of Countries and Their Subdivisions, | |||
| --Part 1: Country Codes", ISO 3166-1:1997. | Part 1: Country Codes", ISO 3166-1:1997. | |||
| ---, --- "Part 2: Country Subdivision Codes", ISO/DIS 3166- | ---, ---, "Part 2: Country Subdivision Codes", ISO/DIS 3166- | |||
| 2. | 2. | |||
| ---, --- "Part 3: Codes for Formerly Used Names of | ---, ---, "Part 3: Codes for Formerly Used Names of | |||
| Countries", ISO/DIS 3166-3. | Countries", ISO/DIS 3166-3. | |||
| [I7498] ---, "Information Processing Systems--Open Systems | [I7498] ---, "Information Processing Systems -- Open Systems | |||
| Interconnection Reference Model--[Part 1:] Basic Reference | Interconnection Reference Model, [Part 1:] Basic Reference | |||
| Model", ISO/IEC 7498-1. (Equivalent to ITU-T Recommendation | Model", ISO/IEC 7498-1. (Equivalent to ITU-T Recommendation | |||
| X.200.) | X.200.) | |||
| ---, --- "Part 2: Security Architecture", ISO/IEC 7499-2. | ---, ---, "Part 2: Security Architecture", ISO/IEC 7499-2. | |||
| ---, --- "Part 4: Management Framework", ISO/IEC 7498-4. | ---, ---, "Part 4: Management Framework", ISO/IEC 7498-4. | |||
| [I7812] ---, "Identification cards--Identification of Issuers--Part | [I7812] ---, "Identification cards -- Identification of Issuers, | |||
| 1: Numbering System", ISO/IEC 7812-1:1993 | Part 1: Numbering System", ISO/IEC 7812-1:1993 | |||
| ---, --- "Part 2: Application and Registration Procedures", | ---, ---, "Part 2: Application and Registration Procedures", | |||
| ISO/IEC 7812-2:1993. | ISO/IEC 7812-2:1993. | |||
| [I8073] ---, "Information Processing Systems -- Open Systems | ||||
| Interconnection, Transport Protocol Specification", ISO IS | ||||
| 8073. | ||||
| [I8327] ---, ---, "Session Protocol Specification", ISO IS 8327. | ||||
| [I8473] ---, ---, "Protocol for Providing the Connectionless Network | ||||
| Service", ISO IS 8473. | ||||
| [I8802-2] ---, "Information Processing Systems -- Local Area | ||||
| Networks, Part 2: Logical Link Control", ISO IS 8802-2. | ||||
| (Equivalent to IEEE 802.2.) | ||||
| [I8802-3] ---, ---, "Part 3: Carrier Sense Multiple Access with | ||||
| Collision Detection (CSMA/CD) Access Method and Physical | ||||
| Layer Specifications", ISO IS 8802-3. (Equivalent to IEEE | ||||
| 802.3.) | ||||
| [I8823] ---, "Information Processing Systems -- Open Systems | ||||
| Interconnection -- Connection-Oriented Presentation Protocol | ||||
| Specification", ISO IS 8823. | ||||
| [I9945] "Portable Operating System Interface for Computer | [I9945] "Portable Operating System Interface for Computer | |||
| Environments", ISO/IEC 9945-1: 1990. | Environments", ISO/IEC 9945-1: 1990. | |||
| [IATF] U.S. DoD, "Information Assurance Technical Framework", | [IATF] NSA, "Information Assurance Technical Framework", Release 3, | |||
| Release 3, NSA, Sep 2000. (See: IATF.) | NSA, September 2000. (See: IATF.) | |||
| [IDSAN] ---, "Intrusion Detection System Analyzer Protection | [IDSAN] ---, "Intrusion Detection System Analyzer Protection | |||
| Profile", version 1.1, NSA, 10 Dec 2001. | Profile", version 1.1, NSA, 10 December 2001. | |||
| [IDSSC] ---, "Intrusion Detection System Scanner Protection | [IDSSC] ---, "Intrusion Detection System Scanner Protection | |||
| Profile", version 1.1, NSA, 10 Dec 2001. | Profile", version 1.1, NSA, 10 December 2001. | |||
| [IDSSE] ---, "Intrusion Detection System Sensor Protection Profile", | [IDSSE] ---, "Intrusion Detection System Sensor Protection Profile", | |||
| version 1.1, NSA, 10 Dec 2001. | version 1.1, NSA, 10 December 2001. | |||
| [IDSSY] ---, "Intrusion Detection System", version 1.4, NSA, 4 Feb | [IDSSY] ---, "Intrusion Detection System", version 1.4, NSA, 4 | |||
| 2002. | February 2002. | |||
| [Ioan] J. Ioannidis and M. Blaze, "The Architecture and | [Ioan] Ioannidis, J. and M. Blaze, "The Architecture and | |||
| Implementation of Network Layer Security in UNIX", in "UNIX | Implementation of Network Layer Security in UNIX", in "UNIX | |||
| Security IV Symposium", Oct 1993, pp. 29-39. | Security IV Symposium", October 1993, pp. 29-39. | |||
| [ITSEC] "Information Technology Security Evaluation Criteria | [ITSEC] "Information Technology Security Evaluation Criteria | |||
| (ITSEC): Harmonised Criteria of France, Germany, the | (ITSEC): Harmonised Criteria of France, Germany, the | |||
| Netherlands, and the United Kingdom", ver. 1.2, U.K. | Netherlands, and the United Kingdom", version 1.2, U.K. | |||
| Department of Trade and Industry, Jun 1991. | Department of Trade and Industry, June 1991. | |||
| [JCSP1] U.S. DoD, "Dictionary of Military and Associated Terms", | [JCSP1] U.S. DoD, "Dictionary of Military and Associated Terms", | |||
| Joint Chiefs of Staff, JCS Pub. 1, 1 Apr 1984. | Joint Chiefs of Staff, JCS Pub. 1, 1 April 1984. | |||
| [Kahn] D. Kahn, "The Codebreakers: The Story of Secret Writing", | [John] Johnson, N. and S. Jajodia, "Exploring Steganography; Seeing | |||
| the Unseen", in "IEEE Computer", February 1998, pp. 26-34. | ||||
| [Kahn] Kahn, D., "The Codebreakers: The Story of Secret Writing", | ||||
| The Macmillan Company, New York, 1967. | The Macmillan Company, New York, 1967. | |||
| [Knut] D. Knuth, Chapter 3 ("Random Numbers") in Volume 2 | [Knut] Knuth, D., Chapter 3 ("Random Numbers") of Volume 2 | |||
| ("Seminumerical Algorithms") of "The Art of Computer | ("Seminumerical Algorithms") of "The Art of Computer | |||
| Programming", Addison-Wesley, Reading, MA, 1969. | Programming", Addison-Wesley, Reading, MA, 1969. | |||
| [Kuhn] M. Kuhn and R. Anderson, "Soft Tempest: Hidden Data | [Kuhn] Kuhn, M. and R. Anderson, "Soft Tempest: Hidden Data | |||
| Transmission Using Electromagnetic Emanations", in David | Transmission Using Electromagnetic Emanations", in David | |||
| Aucsmith, ed., "Information Hiding, Second International | Aucsmith, ed., "Information Hiding, Second International | |||
| Workshop, IH'98", Portland, Oregon, USA, 15-17 Apr 1998, | Workshop, IH'98", Portland, Oregon, USA, 15-17 April 1998, | |||
| LNCS 1525, Springer-Verlag, ISBN 3-540-65386-4, pp. 124-142. | LNCS 1525, Springer-Verlag, ISBN 3-540-65386-4, pp. 124-142. | |||
| [Land] C. Landwehr, "Formal Models for Computer Security", in "ACM | [Land] Landwehr, C., "Formal Models for Computer Security", in "ACM | |||
| Computing Surveys", vol. 13, no. 3, Sep 1981, pp. 247-278. | Computing Surveys", vol. 13, no. 3, September 1981, pp. 247- | |||
| 278. | ||||
| [Larm] J. Larmouth, "ASN.1 Complete", Open System Solutions, 1999 | [Larm] Larmouth, J., "ASN.1 Complete", Open System Solutions, 1999 | |||
| (a freeware book). | (a freeware book). | |||
| [M0404] U.S. Office of Management and Budget, "E-Authentication | [M0404] U.S. Office of Management and Budget, "E-Authentication | |||
| Guidance for Federal Agencies", Memorandum M-04-04, 16 Dec | Guidance for Federal Agencies", Memorandum M-04-04, 16 | |||
| 2003. | December 2003. | |||
| [Mene] A. Menezes et al, "Some Key Agreement Protocols Providing | [Mene] Menezes, A. et al, "Some Key Agreement Protocols Providing | |||
| Implicit Authentication" in "The 2nd Workshop on Selected | Implicit Authentication", in "The 2nd Workshop on Selected | |||
| Areas in Cryptography", 1995. | Areas in Cryptography", 1995. | |||
| [Moor] A. Moore et al, "Attack Modeling for Information Security | [Moor] Moore, A. et al, "Attack Modeling for Information Security | |||
| and Survivability", Carnegie-Mellon University / Software | and Survivability", Carnegie-Mellon University / Software | |||
| Engineering Institute, CMU/SEI-2001-TN-001, Mar 2001. | Engineering Institute, CMU/SEI-2001-TN-001, March 2001. | |||
| [Murr] W. Murray, "Courtney's Laws of Security" in "Infosecurity | [Murr] Murray, W., "Courtney's Laws of Security", in "Infosecurity | |||
| News", Mar/Apr 1993, p. 65. | News", March/April 1993, p. 65. | |||
| [N4001] National Security Telecommunications and Information System | [N4001] National Security Telecommunications and Information System | |||
| Security Committee, "Controlled Cryptographic Items", | Security Committee, "Controlled Cryptographic Items", | |||
| NSTISSI No. 4001, 25 Mar 1985. | NSTISSI No. 4001, 25 March 1985. | |||
| [N4006] ---, "Controlled Cryptographic Items", NSTISSI No. 4006, 2 | [N4006] ---, "Controlled Cryptographic Items", NSTISSI No. 4006, 2 | |||
| Dec 1991. | December 1991. | |||
| [N7003] ---, "Protective Distribution Systems", NSTISSI No. 7003, 13 | [N7003] ---, "Protective Distribution Systems", NSTISSI No. 7003, 13 | |||
| Dec 1996. | December 1996. | |||
| [NCS01] National Computer Security Center, "A Guide to Understanding | [NCS01] National Computer Security Center, "A Guide to Understanding | |||
| Audit in Trusted Systems", NCSC-TG-001, 1 Jun 1988. (See: | Audit in Trusted Systems", NCSC-TG-001, 1 June 1988. (See: | |||
| Rainbow Series.) | Rainbow Series.) | |||
| [NCS03] ---, "Information System Security Policy Guideline", I942-TR- | [NCS03] ---, "Information System Security Policy Guideline", I942- | |||
| 003, ver. 1, Jul 1994. | TR-003, version 1, July 1994. (See: Rainbow Series.) | |||
| [NCS04] ---, "Glossary of Computer Security Terms", NCSC-TG-004, | [NCS04] ---, "Glossary of Computer Security Terms", NCSC-TG-004, | |||
| ver. 1, 21 Oct 1988. (See: Rainbow Series.) | version 1, 21 October 1988. (See: Rainbow Series.) | |||
| [NCS05] ---, "Trusted Network Interpretation of the Trusted Computer | [NCS05] ---, "Trusted Network Interpretation of the Trusted Computer | |||
| System Evaluation Criteria", NCSC-TG-005, ver. 1, 31 Jul | System Evaluation Criteria", NCSC-TG-005, version 1, 31 July | |||
| 1987. (See: Rainbow Series.) | 1987. (See: Rainbow Series.) | |||
| [NCS25] ---, "A Guide to Understanding Data Remanence in Automated | [NCS25] ---, "A Guide to Understanding Data Remanence in Automated | |||
| Information Systems", NCSC-TG-025, ver. 2, Sep 1991. (See: | Information Systems", NCSC-TG-025, version 2, September | |||
| Rainbow Series.) | 1991. (See: Rainbow Series.) | |||
| [NCS25] ---, "A Guide to Understanding Data Remanence in Automated | [NCS25] ---, "A Guide to Understanding Data Remanence in Automated | |||
| Information Systems", NCSC-TG-025, ver. 2, Sep 1991. (See: | Information Systems", NCSC-TG-025, version 2, September | |||
| Rainbow Series.) | 1991. (See: Rainbow Series.) | |||
| [NRC91] National Research Council, "Computers At Risk: Safe | [NRC91] National Research Council, "Computers At Risk: Safe | |||
| Computing in the Information Age", National Academy Press, | Computing in the Information Age", National Academy Press, | |||
| 1991. | 1991. | |||
| [NRC98] F. Schneider, ed., "Trust in Cyberspace", National Research | [NRC98] Schneider, F., ed., "Trust in Cyberspace", National Research | |||
| Council, National Academy of Sciences, 1998. | Council, National Academy of Sciences, 1998. | |||
| [Park] D. Parker, "Computer Security Management", ISBN 0-8359-0905- | [Padl] Padlipsky, M., "The Elements of Networking Style", 1985, | |||
| 0, 1981 | ISBN 0-13-268111-0. | |||
| [Perr] T. Perrine et al, "An Overview of the Kernelized Secure | [Park] Parker, D., "Computer Security Management", ISBN 0-8359- | |||
| Operating System (KSOS)" in "Proceedings of the 7th DoD/NBS | 0905-0, 1981 | |||
| Computer Security Conference", 24-26 Sep 1984. | ||||
| [PGP] S. Garfinkel, "PGP: Pretty Good Privacy", O'Reilly & | [Perr] Perrine, T. et al, "An Overview of the Kernelized Secure | |||
| Operating System (KSOS)", in "Proceedings of the 7th DoD/NBS | ||||
| Computer Security Conference", 24-26 September 1984. | ||||
| [PGP] Garfinkel, S.. "PGP: Pretty Good Privacy", O'Reilly & | ||||
| Associates, Inc., Sebastopol, CA, 1995. | Associates, Inc., Sebastopol, CA, 1995. | |||
| [PKCS] B. Kaliski, Jr., "An Overview of the PKCS Standards", RSA | [PKCS] Kaliski Jr., B., "An Overview of the PKCS Standards", RSA | |||
| Data Security, Inc., 3 Jun 1991. | Data Security, Inc., 3 June 1991. | |||
| [PKC05] RSA Laboratories, "PKCS #5: Password-Based Encryption | [PKC05] RSA Laboratories, "PKCS #5: Password-Based Encryption | |||
| Standard ", ver. 1.5, RSA Laboratories Technical Note, 1 Nov | Standard ", version 1.5, RSA Laboratories Technical Note, 1 | |||
| 1993. | November 1993. (See: [R2898].) | |||
| [PKC07] ---, "PKCS #7: Cryptographic Message Syntax Standard", ver. | [PKC07] ---, "PKCS #7: Cryptographic Message Syntax Standard", | |||
| 1.5, RSA Laboratories Technical Note, 1 Nov 1993. | version 1.5, RSA Laboratories Technical Note, 1 November | |||
| 1993. | ||||
| [PKC10] ---, "PKCS #10: Certification Request Syntax Standard", ver. | [PKC10] ---, "PKCS #10: Certification Request Syntax Standard", | |||
| 1.0, RSA Laboratories Technical Note, 1 Nov 1993. | version 1.0, RSA Laboratories Technical Note, 1 November | |||
| 1993. | ||||
| [PKC11] ---, "PKCS #11: Cryptographic Token Interface Standard", | [PKC11] ---, "PKCS #11: Cryptographic Token Interface Standard", | |||
| ver. 1.0, 28 Apr 1995. | version 1.0, 28 April 1995. | |||
| [R1108] S. Kent, "U.S. Department of Defense Security Options for | [R1108] Kent, S., "U.S. Department of Defense Security Options for | |||
| the Internet Protocol", RFC 1108, Nov 1991. | the Internet Protocol", RFC 1108, November 1991. | |||
| [R1135] J. Reynolds, "The Helminthiasis of the Internet", RFC 1135, | [R1135] Reynolds, J., "The Helminthiasis of the Internet", RFC 1135, | |||
| Dec 1989 | December 1989 | |||
| [R1157] J. Case et al, "A Simple Network Management Protocol (SNMP)" | [R1208] Jacobsen, O. and D. Lynch, "A Glossary of Networking Terms", | |||
| [version 1], STD 15, RFC 1157, May 1990. | RFC 1208, March 1991. | |||
| [R1208] O. Jacobsen et al, "A Glossary of Networking Terms", RFC | [R1281] Pethia, R., Crocker, S., and B. Fraser, "Guidelines for | |||
| 1208, Mar 1991. | Secure Operation of the Internet", RFC 1281, November 1991. | |||
| [R1281] R. Pethia et al, "Guidelines for Secure Operation of the | [R1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, | |||
| Internet", RFC 1281, Nov 1991. | April 1992. | |||
| [R1319] B. Kaliski, "The MD2 Message-Digest Algorithm", RFC 1319, | [R1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, | |||
| Apr 1992. | April 1992. | |||
| [R1320] R. Rivest, "The MD4 Message-Digest Algorithm", RFC 1320, Apr | [R1321] ---, "The MD5 Message-Digest Algorithm", RFC 1321, April | |||
| 1992. | 1992. | |||
| [R1321] ---, "The MD5 Message-Digest Algorithm", RFC 1321, Apr 1992. | [R1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", | |||
| RFC 1334, October 1992. | ||||
| [R1334] B. Lloyd et al, "PPP Authentication Protocols", RFC 1334, | ||||
| Oct 1992. | ||||
| [R1413] M. St. Johns, "Identification Protocol", RFC 1413, Feb 1993. | [R1413] St. Johns, M., "Identification Protocol", RFC 1413, February | |||
| 1993. | ||||
| [R1421] J. Linn, "Privacy Enhancement for Internet Electronic Mail, | [R1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail, | |||
| Part I: Message Encryption and Authentication Procedures", | Part I: Message Encryption and Authentication Procedures", | |||
| RFC 1421, Feb 1993. | RFC 1421, February 1993. | |||
| [R1422] S. Kent, "Privacy Enhancement for Internet Electronic Mail, | [R1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail, | |||
| Part II: Certificate-Based Key Management", RFC 1422, Feb | Part II: Certificate-Based Key Management", RFC 1422, | |||
| 1993. | February 1993. | |||
| [R1455] D. Eastlake, III, "Physical Link Security Type of Service", | [R1455] Eastlake 3rd, D., "Physical Link Security Type of Service", | |||
| RFC 1455, May 1993. | RFC 1455, May 1993. | |||
| [R1457] R. Housley, "Security Label Framework for the Internet", RFC | [R1457] Housley, R., "Security Label Framework for the Internet", | |||
| 1457, May 1993. | RFC 1457, May 1993. | |||
| [R1492] C. Finseth, "An Access Control Protocol, Sometimes Called | [R1492] Finseth, C., "An Access Control Protocol, Sometimes Called | |||
| TACACS", RFC 1492, Jul 1993. | TACACS", RFC 1492, July 1993. | |||
| [R1507] C. Kaufman, "DASS: Distributed Authentication Security | [R1507] Kaufman, C., "DASS: Distributed Authentication Security | |||
| Service", RFC 1507, Sep 1993. | Service", RFC 1507, September 1993. | |||
| [R1510] J. Kohl et al, "The Kerberos Network Authentication Service | [R1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication | |||
| (V5)", RFC 1510, Sep 1993 | Service (V5)", RFC 1510, September 1993 | |||
| [R1731] J. Myers, "IMAP4 Authentication Mechanisms", RFC 1731, Dec | [R1731] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, | |||
| 1994. | December 1994. | |||
| [R1734] ---, "POP3 AUTHentication Command", RFC 1734, Dec, 1994. | [R1734] ---, "POP3 AUTHentication Command", RFC 1734, Dec, 1994. | |||
| [R1750] D. Eastlake, 3rd, et al, "Randomness Recommendations for | [R1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness | |||
| Security", Dec 1994. | Recommendations for Security", RFC 1750, December 1994. | |||
| [R1824] H. Danisch, "The Exponential Security System TESS: An | [R1760] Haller, N., "The S/KEY One-Time Password System", RFC 1760, | |||
| February 1995. | ||||
| [R1824] Danisch, H., "The Exponential Security System TESS: An | ||||
| Identity-Based Cryptographic Protocol for Authenticated Key- | Identity-Based Cryptographic Protocol for Authenticated Key- | |||
| Exchange (E.I.S.S.-Report 1995/4)", RFC 1824, Aug 1995. | Exchange (E.I.S.S.-Report 1995/4)", RFC 1824, August 1995. | |||
| [R1828] P. Metzger et al, "IP Authentication using Keyed MD5", RFC | [R1828] Metzger, P. and W. Simpson, "IP Authentication using Keyed | |||
| 1828, Aug 1995. | MD5", RFC 1828, August 1995. | |||
| [R1829] P. Karn et al, "The ESP DES-CBC Transform", RFC 1829, Aug | [R1829] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC | |||
| 1995. | Transform", RFC 1829, August 1995. | |||
| [R1848] S. Crocker et al, "MIME Object Security Services", RFC 1848, | [R1848] Crocker, S., Freed, N., Galvin, J., and S. Murphy, "MIME | |||
| Oct 1995. | Object Security Services", RFC 1848, October 1995. | |||
| [R1851] P. Karn et al, "The ESP Triple DES Transform", RFC 1851, Sep | [R1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES | |||
| 1995. | Transform", RFC 1851, September 1995. | |||
| [R1885] A. Conta et al, "Internet Control Message Protocol (ICMPv6) | [R1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. | |||
| for the Internet Protocol Version 6 (IPv6) Specification", | Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. | |||
| RFC 1885, Dec 1995. | ||||
| [R1928] M. Leech et al, "SOCKS Protocol Version 5", RFC 1928, Mar | [R1938] Haller, N. and C. Metz, "A One-Time Password System", RFC | |||
| 1996. | 1938, May 1996. | |||
| [R1938] N. Haller et al, "A One-Time Password System", RFC 1938, May | [R1958] Carpenter, B., ed., "Architectural Principles of the | |||
| 1996. | Internet", RFC 1958, June 1996. | |||
| [R1983] G. Malkin, ed., "Internet Users' Glossary", FYI 18, RFC | [R1983] Malkin, G., ed., "Internet Users' Glossary", FYI 18, RFC | |||
| 1983, Aug 1996. | 1983, August 1996. | |||
| [R1994] W. Simpson, "PPP Challenge Handshake Authentication Protocol | [R1994] Simpson, W., "PPP Challenge Handshake Authentication | |||
| (CHAP)", RFC 1994, Aug 1996. | Protocol (CHAP)", RFC 1994, August 1996. | |||
| [R2026] S. Bradner, "The Internet Standards Process--Revision 3", | [R2078] Linn, J., "Generic Security Service Application Program | |||
| BCP009, RFC 2026, Mar 1994. | Interface, Version 2", RFC 2078, January 1997. | |||
| [R2065] D. Eastlake, 3rd, "Domain Name System Security Extensions", | [R2084] Bossert, G., Cooper, S., and W. Drummond, "Considerations | |||
| RFC 2065, Jan 1997. | for Web Transaction Security", RFC 2084, January 1997. | |||
| [R2078] J. Linn, "Generic Security Service Application Program | [R2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
| Interface, Version 2", RFC 2078, Jan 1997. | Hashing for Message Authentication", RFC 2104, February | |||
| 1997. | ||||
| [R2084] G. Bossert et al, "Considerations for Web Transaction | [R2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, | |||
| Security", RFC 2084, Jan 1997. | May 1997. | |||
| [R2104] H. Krawczyk et al, "HMAC: Keyed-Hashing for Message | [R2179] Gwinn, A., "Network Security For Trade Shows", RFC 2179, | |||
| Authentication", RFC 2104, Feb 1997. | July 1997. | |||
| [R2137] D. Eastlake, 3rd, "Secure Domain Name System Dynamic | [R2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP | |||
| Update", RFC 2137, Apr 1997. | AUTHorize Extension for Simple Challenge/Response", RFC | |||
| 2195, September 1997. | ||||
| [R2138] C. Rigney et al, "Remote Authentication Dial In User Service | [R2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, | |||
| (RADIUS)", RFC 2138, Apr 1997. | September 1997. | |||
| [R2179] A. Gwinn, "Network Security For Trade Shows", RFC 2179, Jul | [R2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- | |||
| 1997. | SHA-1", RFC 2202, Sep. 1997. | |||
| [R2195] J. Klensin et al, "IMAP/POP AUTHorize Extension for Simple | [R2222] Myers, J., "Simple Authentication and Security Layer | |||
| Challenge/Response", RFC 2195, Sep 1997. | (SASL)", RFC 2222, October 1997. | |||
| [R2196] B. Fraser, "Site Security Handbook", FYI 8, RFC 2196, Sep | [R2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", | |||
| 1997. | RFC 2246, January 1999. | |||
| [R2202] P. Cheng et al, "Test Cases for HMAC-MD5 and HMAC- | [R2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax, Version | |||
| SHA-1", RFC 2202, Sep. 1997. | 1.5", RFC 2315, March 1998. | |||
| [R2222] J. Myers, "Simple Authentication and Security Layer (SASL)", | [R2323] Ramos, A., "IETF Identification and Security Guidelines", | |||
| RFC 2222, Oct 1997. | RFC 2323, 1 April 1998. (Intended for humorous entertainment | |||
| -- "please laugh loud and hard" -- and does not contain | ||||
| serious security information.) | ||||
| [R2223] J. Postel, "Instructions to RFC Authors", RFC 2223, Oct | [R2350] Brownlee, N. and E. Guttman, "Expectations for Computer | |||
| 1997. | Security Incident Response", RFC 2350, June 1998. | |||
| [R2246] T. Dierks et al, "The TLS Protocol, Version 1.0", RFC 2246, | [R2356] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal | |||
| Jan 1999. | for Mobile IP", RFC 2356, June 1998. | |||
| [R2267] P. Ferguson et al, "Network Ingress Filtering: Defeating | [R2401] Kent, S. and R. Atkinson, "Security Architecture for the | |||
| Denial of Service Attacks Which Employ IP Source Address | Internet Protocol", RFC 2401, November 1998. | |||
| Spoofing", RFC 2267, Jan 1998 | ||||
| [R2315] B. Kaliski, "PKCS #7: Cryptographic Message Syntax, Version | [R2402] ---, "IP Authentication Header", RFC 2402, November 1998. | |||
| 1.5", RFC 2315, Mar 1998. | ||||
| [R2323] A. Ramos, "IETF Identification and Security Guidelines", RFC | [R2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP | |||
| 2323, 1 Apr 1998. [Intended for humorous entertainment | and AH", RFC 2403, November 1998. | |||
| ("please laugh loud and hard"); does not contain serious | ||||
| security information.] | ||||
| [R2350] N. Brownlee et al, "Expectations for Computer Security | [R2404] ---, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, | |||
| Incident Response", RFC 2350, Jun 1998. | November 1998. | |||
| [R2356] G. Montenegro et al, "Sun's SKIP Firewall Traversal for | [R2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher | |||
| Mobile IP", RFC 2356, Jun 1998. | Algorithm With Explicit IV", RFC 2405, November 1998. | |||
| [R2401] S. Kent et al, "Security Architecture for the Internet | [R2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload | |||
| Protocol", RFC 2401, Nov 1998. | (ESP)", RFC 2406, November 1998. | |||
| [R2402] S. Kent et al, "IP Authentication Header", RFC 2402, Nov | [R2407] Piper, D. "The Internet IP Security Domain of Interpretation | |||
| 1998. | for ISAKMP", RFC 2407, November 1998. | |||
| [R2403] C. Madson et al, "The Use of HMAC-MD5-96 within ESP and AH", | [R2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, | |||
| RFC 2403, Nov 1998. | "Internet Security Association and Key Management Protocol | |||
| (ISAKMP)", RFC 2408, November 1998. | ||||
| [R2404] C. Madson et al, "The Use of HMAC-SHA-1-96 within ESP and | [R2409] Harkins, D. and D. Carrel, "The Internet Key Exchange | |||
| AH", RFC 2404, Nov 1998. | (IKE)", RFC 2409, November 1998. | |||
| [R2405] C. Madson et al, "The ESP DES-CBC Cipher Algorithm With | [R2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and | |||
| Explicit IV", RFC 2405, Nov 1998. | Its Use With IPsec", RFC 2410, November 1998. | |||
| [R2406] S. Kent et al, "IP Encapsulating Security Payload (ESP)", | [R2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC | |||
| RFC 2406, Nov 1998. | 2412, November 1998. | |||
| [R2407] D. Piper, "The Internet IP Security Domain of Interpretation | [R2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher | |||
| for ISAKMP", RFC 2407, Nov 1998. | Algorithms", RFC 2451, November 1998. | |||
| [R2408] D. Maughan et al, "Internet Security Association and Key | [R2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security | |||
| Management Protocol (ISAKMP)", RFC 2408, Nov 1998. | Handbook", RFC 2504, February 1999. | |||
| [R2409] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", | [R2510] Adams, C. and S. Farrell, "Internet X.509 Public Key | |||
| RFC 2409, Nov 1998. | Infrastructure Certificate Management Protocols", RFC 2510, | |||
| March 1999. | ||||
| [R2410] R. Glenn et al, "The NULL Encryption Algorithm and Its Use | [R2535] Eastlake 3rd, D., Domain Name System Security Extensions, | |||
| With IPsec", RFC 2410, Nov 1998. | RFC 2535, March 1999. | |||
| [R2412] H. Orman, "The OAKLEY Key Determination Protocol", RFC 2412, | [R2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name | |||
| Nov 1998. | System (DNS)", RFC 2536, March 1999. | |||
| [R2451] R. Pereira et al, "The ESP CBC-Mode Cipher Algorithms", RFC | [R2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. | |||
| 2451, Nov 1998. | Adams, "X.509 Internet Public Key Infrastructure Online | |||
| Certificate Status Protocol", RFC 2560, June 1999. | ||||
| [R2459] R. Housley et al, " Internet X.509 Public Key Infrastructure | [R2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption | |||
| Certificate and CRL Profile", RFC 2459, Jan 1999. | Algorithm", RFC 2612, June 1999. | |||
| [R2504] E. Guttman et al, "Users' Security Handbook", RFC 2504, Feb | [R2628] Smyslov, V., "Simple Cryptographic Program Interface", RFC | |||
| 2628, June 1999. | ||||
| [R2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC | ||||
| 2631, June 1999. | ||||
| [R2634] Hoffman, P., ed., "Enhanced Security Services for S/MIME", | ||||
| RFC 2634, June 1999. | ||||
| [R2635] Hambridge, S. and A. Lunde, "Don't Spew: A Set of Guidelines | ||||
| for Mass Unsolicited Mailings and Postings", RFC 2635, June | ||||
| 1999. | 1999. | |||
| [R2510] C. Adams et al, "Internet X.509 Public Key Infrastructure | [R2660] Rescorla, E. and A. Schiffman, "The Secure HyperText | |||
| Certificate Management Protocols", RFC 2510, Mar 1999. | Transfer Protocol", RFC 2660, August 1999. | |||
| [R2527] S. Chokhani et al, "Internet X.509 Public Key | [R2773] Housley, R., Yee, P., and W. Nace, "Encryption using KEA and | |||
| Infrastructure, Certificate Policy and Certification | SKIPJACK", RFC 2773, February 2000. | |||
| Practices Framework", RFC 2527, Mar 1999. | ||||
| [R2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System | [R2801] Burdett, D., "Internet Open Trading Protocol - IOTP, Version | |||
| (DNS)", RFC 2536, Mar 1999. | 1.0", RFC 2801, April 2000. | |||
| [R2560] M. Myers et al, "X.509 Internet Public Key Infrastructure | [R2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: | |||
| Online Certificate Status Protocol", RFC 2560, Jun 1999. | Defeating Denial of Service Attacks which employ IP Source | |||
| Address Spoofing", BCP 38, RFC 2827, May 2000. | ||||
| [R2570] J. Case et al, "Introduction to Version 3 of the Internet- | [R2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote | |||
| Standard Network Management Framework", RFC 2570, Apr 1999. | Authentication Dial In User Service (RADIUS)", RFC 2865, | |||
| June 2000. | ||||
| [R2574] U. Blumenthal et al, "User-based Security Model (USM) for | [R2898] Kaliski, B., "PKCS #5: Password-Based Cryptography | |||
| Version 3 of the Simple Network Management Protocol | Specification, Version 2.0", RFC 2898, September 2000. (See: | |||
| (SNMPv3)", RFC 2574, Apr 1999. | [PKC05].) | |||
| [R2612] C. Adams et al, "The CAST-256 Encryption Algorithm", RFC | [R3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic | |||
| 2612, Jun 1999. | Update", RFC 3007, November 2000. | |||
| [R2628] V. Smyslov, "Simple Cryptographic Program Interface", RFC | [R3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, | |||
| 2628, Jun 1999. | "Policy Core Information Model -- Version 1 Specification", | |||
| RFC 3060, February 2001. | ||||
| [R2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC | [R3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, | |||
| 2631, Jun 1999. | M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, | |||
| J., and S. Waldbusser, "Terminology for Policy-Based | ||||
| Management", RFC 3198, November 2001. | ||||
| [R2634] P. Hoffman, ed., "Enhanced Security Services for S/MIME", | [R3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet | |||
| RFC 2634, Jun 1999. | X.509 Public Key Infrastructure Certificate and Certificate | |||
| Revocation List (CRL) Profile", RFC 3280, April 2002. | ||||
| [R2635] S. Hambridge et al, "Don't Spew: A Set of Guidelines for | [R3410] Case, J., Mundy, R., Partain, D., and B. Stewart, | |||
| Mass Unsolicited Mailings and Postings", RFC 2635, Jun 1999. | "Introduction and Applicability Statements for Internet- | |||
| Standard Management Framework", RFC 3410, December 2002. | ||||
| [R2773] R. Housley et al, "Encryption using KEA and SKIPJACK", RFC | [R3414] Blumenthal, U. and B. Wijnen, "User-based Security Model | |||
| 2773, Feb 2000. | (USM) for version 3 of the Simple Network Management | |||
| Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. | ||||
| [R2898] B. Kaliski, PKCS #5: Password-Based Cryptography | [R3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "Group | |||
| Specification, Version 2.0", RFC 2898, Sep 2000. | Domain of Interpretation", RFC 3547, July 2003. | |||
| [R3198] A. Westerinen et al, "Terminology for Policy-Based | [R3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, | |||
| Management", RFC 3198, Nov 2001. | "Internet X.509 Public Key Infrastructure Certificate Policy | |||
| and Certification Practices Framework", RFC 3647, November | ||||
| 2003. | ||||
| [R3547] M. Baugher et al, "Group Domain of Interpretation", RFC | [R3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 | |||
| 3547, Jul 2003. | Public Key Infrastructure: Qualified Certificates Profile", | |||
| RFC 3739, March 2004. | ||||
| [R3739] S. Santesson et al, "Internet X.509 Public Key | [R3740] Hardjono, T. and B. Weis, "The Multicast Group Security | |||
| Infrastructure: Qualified Certificates Profile", RFC 3739, | Architecture", RFC 3740, March 2004. | |||
| Mar 2004. | ||||
| [R3740] T. Hardjono et al, "The Multicast Group Security | [R3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | |||
| Architecture", RFC 3740, Mar 2004. | Levkowetz, "Extensible Authentication Protocol (EAP)", RFC | |||
| 3748, June 2004. | ||||
| [R3748] B. Aboda, et al, "Extensible Authentication Protocol (EAP)", | [R3766] Orman, H. and P. Hoffman, "Determining Strengths For Public | |||
| RFC 3748, Jun 2004. | Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, | |||
| April 2004. | ||||
| [R3753] J. Manner et al, ed's., "Mobility Related Terminology", RFC | [R3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. | |||
| 3573, Jun 2004. | Thompson, "Internet X.509 Public Key Infrastructure (PKI) | |||
| Proxy Certificate Profile", RFC 3820, June 2004. | ||||
| [R3820] S. Tuecke et al, "Internet X.509 Public Key Infrastructure | [R3851] Ramsdell, B., ed., "Secure/Multipurpose Internet Mail | |||
| (PKI) Proxy Certificate Profile", RFC 3280, Jun 2004. | Extensions (S/MIME) Version 3.1 Message Specification", RFC | |||
| 3851, July 2004. | ||||
| [Raym] E. Raymond, ed., "The On-Line Hacker Jargon File", ver. | [R3871] Jones, G., ed., "Operational Security Requirements for Large | |||
| 4.0.0, 24 Jul 1996. (Also available as "The New Hacker's | Internet Service Provider (ISP) IP Network Infrastructure", | |||
| Dictionary", 2nd edition, MIT Press, Sep 1993, ISBN 0-262- | RFC 3871, September 2004. | |||
| 18154-1. See: http://www.tuxedo.org/jargon/ for the latest | ||||
| version.) | ||||
| [Roge] H. Rogers, "An Overview of the Caneware Program", in | [Raym] Raymond, E., ed., "The On-Line Hacker Jargon File", version | |||
| 4.0.0, 24 July 1996. (See: http://www.tuxedo.org/jargon/ for | ||||
| the latest version. Also, "The New Hacker's Dictionary", 2nd | ||||
| edition, MIT Press, September 1993, ISBN 0-262-18154-1.) | ||||
| [Roge] Rogers, H., "An Overview of the Caneware Program", in | ||||
| "Proceedings of the 10th National Computer Security | "Proceedings of the 10th National Computer Security | |||
| Conference", NIST and NCSC, Sep 1987. | Conference", NIST and NCSC, September 1987. | |||
| [Russ] D. Russell et al, Chapter 10 ("TEMPEST") in "Computer | [RSCG] NSA, "Router Security Configuration Guide: Principles and | |||
| Guidance for Secure Configuration of IP Routers, with | ||||
| Detailed Instructions for Cisco Systems Routers", version | ||||
| 1.0g, C4-054R-00, 20 April 2001, available at | ||||
| http://www.nsa.gov. | ||||
| [Russ] Russell, D. et al, Chapter 10 ("TEMPEST") of "Computer | ||||
| Security Basics", ISBN 0-937175-71-4, 1991. | Security Basics", ISBN 0-937175-71-4, 1991. | |||
| [SAML] Organization for the Advancement of Structured Information | [SAML] Organization for the Advancement of Structured Information | |||
| Standards (OASIS), "Assertions and Protocol for the OASIS | Standards (OASIS), "Assertions and Protocol for the OASIS | |||
| Security Assertion Markup Language (SAML)", version 1.1, 2 | Security Assertion Markup Language (SAML)", version 1.1, 2 | |||
| Sep 2003. | September 2003. | |||
| [Sand] R. Sandhu et al, "Role-Based Access Control Models", in | [Sand] Sandhu, R. et al, "Role-Based Access Control Models", in | |||
| "IEEE Computer", vol. 29, no.2, Feb 1996, pp. 38-47. | "IEEE Computer", vol. 29, no.2, February 1996, pp. 38-47. | |||
| [Schn] B. Schneier, "Applied Cryptography Second Edition", John | [Schn] Schneier, B., "Applied Cryptography Second Edition", John | |||
| Wiley & Sons, Inc., New York, 1996. | Wiley & Sons, Inc., New York, 1996. | |||
| [SDNS3] U.S. DoD, NSA, "Secure Data Network Systems, Security | [SDNS3] U.S. DoD, NSA, "Secure Data Network Systems, Security | |||
| Protocol 3 (SP3)", document SDN.301, Revision 1.5, 15 May | Protocol 3 (SP3)", document SDN.301, Revision 1.5, 15 May | |||
| 1989. | 1989. | |||
| [SDNS4] ---, ---, "Security Protocol 4 (SP4)", document SDN.401, | [SDNS4] ---, ---, "Security Protocol 4 (SP4)", document SDN.401, | |||
| Revision 1.2, 12 Jul 1988. | Revision 1.2, 12 July 1988. | |||
| [SDNS7] ---, ---, "Secure data Network System, Message Security | [SDNS7] ---, ---, "Secure data Network System, Message Security | |||
| Protocol (MSP)", document SDN.701, Revision 4.0, 7 Jun 1996, | Protocol (MSP)", SDN.701, Revision 4.0, 7 June 1996, with | |||
| with Corrections to Message Security Protocol, SDN.701, Rev | "Corrections to Message Security Protocol, SDN.701, Rev 4.0, | |||
| 4.0", 96-06-07, 30 Aug, 1996. | 96-06-07", 30 Aug, 1996. | |||
| [SET1] MasterCard and Visa, "SET Secure Electronic Transaction | [SET1] MasterCard and Visa, "SET Secure Electronic Transaction | |||
| Specification, Book 1: Business Description", ver. 1.0, 31 | Specification, Book 1: Business Description", version 1.0, | |||
| May 1997. | 31 May 1997. | |||
| [SET2] ---, "SET Secure Electronic Transaction Specification, Book | [SET2] ---, "SET Secure Electronic Transaction Specification, Book | |||
| 2: Programmer's Guide", ver. 1.0, 31 May 1997. | 2: Programmer's Guide", version 1.0, 31 May 1997. | |||
| [SKEME] H. Krawczyk, H., "SKEME: A Versatile Secure Key Exchange | [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange | |||
| Mechanism for Internet", in "Proceedings of the 1996 | Mechanism for Internet", in "Proceedings of the 1996 | |||
| Symposium on Network and Distributed Systems Security". | Symposium on Network and Distributed Systems Security". | |||
| [SKIP] "SKIPJACK and KEA Algorithm Specifications", ver. 2.0, 22 | [SKIP] "SKIPJACK and KEA Algorithm Specifications", version 2.0, 22 | |||
| May 1998 (available from NIST Computer Security Resource | May 1998, and "Clarification to the SKIPJACK Algorithm | |||
| Center). | Specification", 9 May 2002 (available from NIST Computer | |||
| Security Resource Center). | ||||
| [SP12] NIST, "An Introduction to Computer Security: The NIST | [SP12] NIST, "An Introduction to Computer Security: The NIST | |||
| Handbook", Special Publication 800-12. | Handbook", Special Publication 800-12. | |||
| [SP14] M. Swanson et al (NIST), "Generally Accepted Principles and | [SP14] Swanson, M. et al (NIST), "Generally Accepted Principles and | |||
| Practices for Security Information Technology Systems", --- | Practices for Security Information Technology Systems", --- | |||
| 800-14, Sep 1996. | 800-14, September 1996. | |||
| [SP15] W. Burr et al (NIST), "Minimum Interoperability | [SP15] Burr, W. et al (NIST), "Minimum Interoperability | |||
| Specification for PKI Components (MISPC), Version 1", --- | Specification for PKI Components (MISPC), Version 1", --- | |||
| 800-15, Sep 1997. | 800-15, September 1997. | |||
| [SP22] A. Rukhin et al (NIST), "A Statistical Test Suite for Random | [SP22] Rukhin, A. et al (NIST), "A Statistical Test Suite for | |||
| and Pseudorandom Number Generators for Cryptographic | Random and Pseudorandom Number Generators for Cryptographic | |||
| Applications", --- 800-15, 15 May 2001. | Applications", --- 800-15, 15 May 2001. | |||
| [SP27] G. Stoneburner et al (NIST), "Engineering Principles for | [SP27] Stoneburner, G. et al (NIST), "Engineering Principles for | |||
| Information Technology Security (A Baseline for Achieving | Information Technology Security (A Baseline for Achieving | |||
| Security)", --- 800-27 Rev A, June 2004. | Security)", --- 800-27 Rev A, June 2004. | |||
| [SP28] W. Jansen (NIST), "Guidelines on Active Content and Mobile | [SP28] Jansen, W. (NIST), "Guidelines on Active Content and Mobile | |||
| Code", --- 800-28, Oct 2001. | Code", --- 800-28, October 2001. | |||
| [SP30] G. Stoneburner et al (NIST), "Risk Management Guide for | [SP30] Stoneburner, G. et al (NIST), "Risk Management Guide for | |||
| Information Technology Systems", --- 800-30, Oct 2001. | Information Technology Systems", --- 800-30, October 2001. | |||
| [SP31] R. Bace et al (NIST), "Intrusion Detection Systems", --- | [SP31] Bace, R. et al (NIST), "Intrusion Detection Systems", --- | |||
| 800-31. | 800-31. | |||
| [SP32] D. Kuhn (NIST), "Introduction to Public Key Technology and | [SP32] Kuhn, D. (NIST), "Introduction to Public Key Technology and | |||
| the Federal PKI Infrastructure ", --- 800-32, 26 Feb 2001. | the Federal PKI Infrastructure ", --- 800-32, 26 February | |||
| 2001. | ||||
| [SP33] G. Stoneburner (NIST), "Underlying Technical Models for | [SP33] Stoneburner, G. (NIST), "Underlying Technical Models for | |||
| Information Technology Security", --- 800-33, Dec 2001. | Information Technology Security", --- 800-33, December 2001. | |||
| [SP37] R. Ross et al (NIST), "Guide for the Security Certification | [SP37] Ross, R. et al (NIST), "Guide for the Security Certification | |||
| and Accreditation of Federal Information Systems", --- 800- | and Accreditation of Federal Information Systems", --- 800- | |||
| 37, May 2004 | 37, May 2004 | |||
| [SP41] J. Wack et al (NIST), "Guidelines on Firewalls and Firewall | [SP41] Wack. J. et al (NIST), "Guidelines on Firewalls and Firewall | |||
| Policy", --- 800-41, Jan 2002. | Policy", --- 800-41, January 2002. | |||
| [SP42] J. Wack et al (NIST), "Guideline on Network Security | [SP42] ---, "Guideline on Network Security Testing", --- 800-42, | |||
| Testing", --- 800-42, Oct 2003. | October 2003. | |||
| [SP56] NIST, "Recommendations on Key Establishment Schemes", Draft | [SP56] NIST, "Recommendations on Key Establishment Schemes", Draft | |||
| 2.0, --- 800-63, Jan 2003. | 2.0, --- 800-63, January 2003. | |||
| [SP57] NIST, "Recommendation for Key Management", Part 1 "General | [SP57] ---, "Recommendation for Key Management", Part 1 "General | |||
| Guideline" and Part 2 "Best Practices for Key Management | Guideline" and Part 2 "Best Practices for Key Management | |||
| Organization", --- 800-57, Jan 2003. | Organization", --- 800-57, DRAFT, January 2003. | |||
| [SP61] T. Grance et al (NIST), "Computer Security Incident Handling | [SP61] Grance, T. et al (NIST), "Computer Security Incident | |||
| Guide", --- 800-57, Jan 2003. | Handling Guide", --- 800-57, January 2003. | |||
| [SP63] W. Burr et al (NIST), "Electronic Authentication Guideline", | [SP63] Burr, W. et al (NIST), "Electronic Authentication | |||
| --- 800-63, Jun 2004 | Guideline", --- 800-63, June 2004 | |||
| [SP67] W. Barker (NIST), "Recommendation for the Triple Data | [SP67] Barker, W. (NIST), "Recommendation for the Triple Data | |||
| Encryption Algorithm (TDEA) Block Cipher", --- 800-67, May | Encryption Algorithm (TDEA) Block Cipher", --- 800-67, May | |||
| 2004 | 2004 | |||
| [Stei] J. Steiner et al, "Kerberos: An Authentication Service for | [Stal] Stallings, W., "Local Networks", 1987, ISBN 0-02-415520-9. | |||
| Open Network Systems" in "Usenix Conference Proceedings", | ||||
| Feb 1988. | ||||
| [Weis] C. Weissman, "Blacker: Security for the DDN: Examples of A1 | [Stei] Steiner, J. et al, "Kerberos: An Authentication Service for | |||
| Open Network Systems", in "Usenix Conference Proceedings", | ||||
| February 1988. | ||||
| [Weis] Weissman, C., "Blacker: Security for the DDN: Examples of A1 | ||||
| Security Engineering Trades", in "Symposium on Security and | Security Engineering Trades", in "Symposium on Security and | |||
| Privacy", IEEE Computer Society Press, May 1992, pp. 286- | Privacy", IEEE Computer Society Press, May 1992, pp. 286- | |||
| 292. | 292. | |||
| [X400] International Telecommunications Union--Telecommunication | [X400] International Telecommunications Union -- Telecommunication | |||
| Standardization Sector (formerly "CCITT"), Recommendation | Standardization Sector (formerly "CCITT"), Recommendation | |||
| X.400, "Message Handling Services: Message Handling System | X.400, "Message Handling Services: Message Handling System | |||
| and Service Overview". | and Service Overview". | |||
| [X500] ---, Recommendation X.500, "Information Technology--Open | [X419] ---, "Message Handling Systems: Protocol Specifications", | |||
| Systems Interconnection--The Directory: Overview of | ITU-T Recommendation X.419. (Equivalent to ISO 10021-6). | |||
| [X420] ---, ---: "Interpersonal Messaging System", ITU-T | ||||
| Recommendation X.420. (Equivalent to ISO 10021-7.). | ||||
| [X500] ---, Recommendation X.500, "Information Technology -- Open | ||||
| Systems Interconnection -- The Directory: Overview of | ||||
| Concepts, Models, and Services". (Equivalent to ISO 9594-1.) | Concepts, Models, and Services". (Equivalent to ISO 9594-1.) | |||
| [X501] ---, Recommendation X.501, "Information Technology--Open | [X501] ---, Recommendation X.501, ---: "Models". | |||
| Systems Interconnection--The Directory: Models". | ||||
| [X509] ---, Recommendation X.509, "Information Technology--Open | [X509] ---, Recommendation X.509, ---: "Authentication Framework", | |||
| Systems Interconnection--The Directory: Authentication | COM 7-250-E Revision 1, 23 February 2001. (Equivalent to ISO | |||
| Framework", COM 7-250-E Revision 1, 23 Feb 2001. (Equivalent | 9594-8.) | |||
| to ISO 9594-8.) | ||||
| [X519] ---, Recommendation X.519, "Information Technology--Open | [X519] ---, Recommendation X.519, ---: "Protocol Specifications". | |||
| Systems Interconnection--The Directory: Protocol | ||||
| Specifications". | ||||
| [X520] ---, Recommendation X.520, "Information Technology--Open | [X520] ---, Recommendation X.520, ---: "Selected Attribute Types". | |||
| Systems Interconnection--The Directory: Selected Attribute | ||||
| Types". | ||||
| [X680] ---, Recommendation X.680, "Information Technology--Abstract | [X680] ---, Recommendation X.680, "Information Technology -- | |||
| Syntax Notation One (ASN.1)--Specification of Basic | Abstract Syntax Notation One (ASN.1) -- Specification of | |||
| Notation", 15 Nov 1994. (Equivalent to ISO/IEC 8824-1.) | Basic Notation", 15 November 1994. (Equivalent to ISO/IEC | |||
| 8824-1.) | ||||
| [X690] ---, Recommendation X.690, "Information Technology--ASN.1 | [X690] ---, Recommendation X.690, "Information Technology -- ASN.1 | |||
| Encoding Rules--Specification of Basic Encoding Rules (BER), | Encoding Rules -- Specification of Basic Encoding Rules | |||
| Canonical Encoding Rules (CER) and Distinguished Encoding | (BER), Canonical Encoding Rules (CER) and Distinguished | |||
| Rules (DER)", 15 Nov 1994. (Equivalent to ISO/IEC 8825-1.) | Encoding Rules (DER)", 15 November 1994. (Equivalent to | |||
| ISO/IEC 8825-1.) | ||||
| 6. Security Considerations | 6. Security Considerations | |||
| This document mainly defines security terms and recommends how to use | This document mainly defines security terms and recommends how to use | |||
| them. It also provides limited tutorial information about security | them. It also provides limited tutorial information about security | |||
| aspects of Internet protocols, but it not describe in detail the | aspects of Internet protocols, but it does not describe in detail the | |||
| vulnerabilities of or threats to specific protocols and does not | vulnerabilities of, or threats to, specific protocols and does not | |||
| definitively describe mechanisms that protect specific protocols. | definitively describe mechanisms that protect specific protocols. | |||
| 7. Acknowledgments | 7. Acknowledgments | |||
| Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
| Internet Society. | Internet Society. | |||
| George Huff had a good idea! [Huff] | George Huff had a good idea! [Huff] | |||
| 8. Author's Address | 8. Author's Address | |||
| Please address all comments to: | Please address all comments to: | |||
| Robert W. Shirey BBN Technologies | Robert W. Shirey BBN Technologies | |||
| E-mail: rshirey@bbn.com Suite 400, Mail Stop 30/6B1 | E-mail: rshirey@bbn.com Suite 400, Mail Stop 30/6B1 | |||
| 1300 Seventeenth Street North | 1300 Seventeenth Street North | |||
| Arlington, VA 22209-3801 USA | Arlington, VA 22209-3801 USA | |||
| 9. Full Copyright Statement | 9. Full Copyright Statement | |||
| Copyright (C) The Internet Society (2004). This document is subject | Copyright (C) The Internet Society (2005). This document is subject | |||
| to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
| except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
| This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE IS SPONSORED | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE IS SPONSORED | |||
| BY, THE INTERNET SOCIETY, AND THE INTERNET ENGINEERING TASK FORCE | BY, THE INTERNET SOCIETY, AND THE INTERNET ENGINEERING TASK FORCE | |||
| DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT | DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT | |||
| LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL | LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL | |||
| NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY | NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY | |||
| OR FITNESS FOR A PARTICULAR PURPOSE. | OR FITNESS FOR A PARTICULAR PURPOSE. | |||
| Expiration Date: 20 February 2004. | Expiration Date: 9 September 2005. | |||
| End of changes. 1376 change blocks. | ||||
| 2845 lines changed or deleted | 4053 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||