C. Criteria. Common Criteria for Information Technology Security Evaluation (Parts 1, 2 and 3). Technical report, The Common Criteria Project, August 1999. Home/Search Document Not in Database Summary Related Articles Check |
This paper is cited in the following contexts:
First 50 documents
Development of a Prototype for a Security Platform for Mobile.. - Stüble (Correct)
....To simplify development of secure applications the secure environment shall provide a framework containing simple implementations of basic functionalities. Simplicity is necessary to make evaluation of security related components possible. Example evaluation criteria are the Common Criteria [37], which partially need formal techniques to evaluate higher security levels. The proposal of the PERSEUS project [21] suggests a detailed software architecture of the secure environment, illustrated by Figure 1.1. It informally describes approximately twelve components, their contents and ....
....basic requirements necessary to develop a secure environment as described in Section 1.1. Another task of this section is to provide a set of de nitions to prevent misunderstandings. The security functional requirements of the Common Criteria for Information Technology Security Evaluation [37], short CC, is used as a guide for development of the secure environment. In addition, I hope that later evaluation of secure components is easier if both, de ned terms and concepts, are used continuously in the analysis, design and implementation phase. 3.1.1 Introduction The Common Criteria is ....
Common Criteria Project Sponsoring Organisations. Common Criteria for Information Technology Security Evaluation (Version 2.1). Common Criteria Project Sponsoring Organisations, August 1999. adopted by ISO/IEC as Draft International Standard DIS 15408 1-3.
Pseudonymizing Unix Log Files - Flegel (2002) (3 citations) (Correct)
....All of these record the identity of the actor of an event or at least identifying features of users. Audit components specifically designed for compliance with the Trusted Computer System Evaluation Criteria (TCSEC) C2 or higher) 9, 10] or the Common Criteria (FAU GEN1.2 and FAU GEN2) [11] are required to record information identifying the originator of an event. Hence, all of these audit components record personal data and need to be considered for pseudonymization. In annex C the Common Criteria provide for the application of the Privacy class (FPR) to FAU GEN2. The Privacy class ....
Common Criteria Implementation Board. Common Criteria for Information Technology Security Evaluation --- Part 2: Security functional requirements, Version 2.1. Number CCIMB-99-032. National Institute of Standards and Technology, August 1999. http:// csrc.ncsl.nist.gov/cc/ccv20/p2-v21.pdf.
Network Pump (NP) Security Target - Moore (2000) (Correct)
....recovery (FPT RCV.3) requirements support the recovery of the user administrator data and function upon system, connection or power failure. 5. 3 NP Security Assurance Requirements The Common Criteria requires that NP s Security Assurance Requirements (SARs) be chosen from the set specified in [12]. That document describes seven increasingly rigorous Evaluation Assurance Levels, EAL1 to EAL7, where a particular level of assurance contain a subset of the SARs contained at the next higher level. Each EAL contains SAR classes, which refine into SAR families. SAR families, in turn, refine into ....
Common Criteria Implementation Board, "Common Criteria for Information Technology Security Evaluation; Part 3: Security assurance requirements," Version 2.0, CCIB-97/083R, 19 December 1997.
Network Pump (NP) Security Target - Moore (2000) (Correct)
....in Section 5.1, the rational for these requirements in Section 5.2, and the NP s security assurance requirements in Section 5.3. 5. 1 Security Functional Requirements (SFR) The Common Criteria requires that NP s Security Functional Requirements (SFRs) be chosen from the set specified in [10]. That document categorizes the SFRs hierarchically. At the top of the hierarchy are SFR classes, which refine into SFR families. SFR families, in turn, refine into SFR components and finally into the SFRs themselves. Table 7 details the security functional classes and components that constitute ....
....significant threats to integrity and availability that must be addressed by the NP s environment (see Section 3.2) if these threats are important to that environment. 5.2. 11 Security Requirements Mutually Supportive Table 9 below shows the functional dependencies among the SFRs, as defined by [10]. The table verifies that each dependency is met by one of the SFRs included or, in the case of an assurance requirement dependency, that EAL5 satisfies the dependency. The Letter H after a reference number indicates that a dependency is satisfied by a component that is hierarchical to the ....
Common Criteria Implementation Board, "Common Criteria for Information Technology Security Evaluation; Part 2: Security functional requirements," Version 2.0, CCIB-97/082R, 19 December 1997.
Interoperable and Flexible Digital Signatures for.. - Baier, Ruppert (2004) Self-citation (Security) (Correct)
No context found.
Common Criteria for Information Technology Security Evaluation (CC), Version 2.0. ISO/IEC-Standard 15408, 1998.
Security-Critical System Development with Extended Use Cases - Popp, Jürjens, Wimmel, Breu Self-citation (Security) (Correct)
No context found.
Common criteria for information technology security evaluation version 2.1. Technical report, August 1999. Avilable from http://www.commoncriteria.org/ docs/index.html.
A Case Study in Security Requirements Engineering - For High Assurance (2001) Self-citation (Security) (Correct)
No context found.
Common Criteria for Information Technology Security Evaluation Version 2.1, Common Criteria Project Sponsoring Organisations, August, 1999
Use Case Oriented Development of Security-Critical Systems - Jürjens, Popp, Wimmel (2003) Self-citation (Technology) (Correct)
No context found.
Common criteria for information technology security evaluation version 2.1. Technical report, August 1999. Avilable from http://www.commoncriteria.org/ docs/index.html.
Use Case Oriented Development of Security-Critical Systems - Jürjens, Popp, Wimmel (2003) Self-citation (Technology) (Correct)
No context found.
Common criteria for information technology security evaluation version 2.1. Technical report, August 1999. Avilable from http://www.commoncriteria.org/ docs/index.html.
Evaluating security tools towards usable security: A.. - Kaiser, Reichenbach (2002) (2 citations) Self-citation (Security) (Correct)
....of security tools. 2. CATEGORIZATION OF USABILITYAND SECURITY PROBLEMS 2.1 Problem classification 2.1. 1 Sets of usability and security problems Security systems may be considered to be secure if they fulfill, for example, the Common Criteria for Information Technology Security Evaluation (CC) [1]. By certifying security systems according to the CC, security problems on the technical layer can be avoided. Security problems can also stem from the user interface, however. Usability problems can be divided into the following two sets: a. Security non critical usability problems b. ....
....these problems may be ignored. Usability problems, on the other hand, are security critical if at least one protection goal of multilateral security [7] is threatened. In the following we discuss whether security critical usability problems exist in security tools, despite certified security [1] and despite common usability guidelines. Considering usability guidelines, we may point out that security aspects are not yet considered. This is illustrated below by two examples of securitycritical user errors occurring in security systems certified by the CC, for example, and not being ....
Common Criteria for Information Technology Security Evaluation V 2.1, Aug. 1999. Version 2.1/ISO IS 15408.
The Use of Formal Methods for Trusted Digital Signature.. - Langenstein, Vogt, Ullmann (2000) (1 citation) Self-citation (Security) (Correct)
.... for publication at FLAIRS 2000, Orlando, Florida 1 The Use of Formal Methods for Trusted Digital Signature Devices Bruno Langenstein and Roland Vogt Deutsches Forschungszentrum fr Knstliche Intelligenz (DFKI GmbH) German Research Center for Artificial Intelligence] Stuhlsatzenhausweg 3, 66123 Saarbrcken, Germany langenstein,vogt dfki.de Markus Ullmann Bundesamt fr Sicherheit in der Informationstechnik (BSI) German Information Security Agency] Godesberger Allee 183, 53133 Bonn, Germany ullmann bsi.de Abstract This paper presents a formal security policy model for ....
.... for publication at FLAIRS 2000, Orlando, Florida 1 The Use of Formal Methods for Trusted Digital Signature Devices Bruno Langenstein and Roland Vogt Deutsches Forschungszentrum fr Knstliche Intelligenz (DFKI GmbH) German Research Center for Artificial Intelligence] Stuhlsatzenhausweg 3, 66123 Saarbrcken, Germany langenstein,vogt dfki.de Markus Ullmann Bundesamt fr Sicherheit in der Informationstechnik (BSI) German Information Security Agency] Godesberger Allee 183, 53133 Bonn, Germany ullmann bsi.de Abstract This paper presents a formal security policy model for ....
[Article contains additional citation context not shown here]
Common Criteria for Information Technology Security Evaluation (CC), Version 2.0, 1998. Available from http: //csrc.ncsl.nist.gov/nistpubs/cc/.
Security Analysis of Wireless Java - Mourad Debbabi Mohamed (2005) (Correct)
No context found.
C. Criteria. Common Criteria for Information Technology Security Evaluation (Parts 1, 2 and 3). Technical report, The Common Criteria Project, August 1999.
Tracing Secure Information Flow Through Mode Changes - Colin Fidge Tim (Correct)
No context found.
The Common Criteria Project Sponsoring Organisations (1999), Common Criteria for Information Technology Security Evaluation, 2.1 edn.
Threat Modeling Networked And Data-Centric Systems - Myagmar (2005) (Correct)
No context found.
CCEB Common Criteria Editorial Board, "Common criteria for information technology security evaluations, " Report, 1998.
Threat Modeling as a Basis for Security Requirements - Myagmar, Lee, Yurcik (2005) (Correct)
No context found.
Common Criteria Editorial Board. Common Criteria for Information Technology Security Evaluations. Report, 1998.
An Evaluated Certification Services System for the .. - Wiesmaier.. (2005) (Correct)
No context found.
Common Criteria Project Sponsoring Organisations, "Common Criteria for Information Technology Security Evaluation,"
An Evaluated Certification Services System for the .. - Wiesmaier.. (2005) (Correct)
No context found.
Common Criteria Project Sponsoring Organisations. Common Criteria for Information Technology Security Evaluation, 1999. http://www.bsi.de/cc/ccp1V21.pdf (11 Nov 2004).
On the Role of Contextual Information for Privacy Attacks.. - Cvrcek, Matyas, Jr. (2004) (Correct)
No context found.
The Common Criteria Project Sponsoring Organisations. Common Criteria for Information Technology Security Evaluation -- part 2, version 2.1. August 1999.
Making Sense Of Smart Card Security Certifications - Reid, Looi (2000) (1 citation) (Correct)
No context found.
Common Criteria, Common Criteria for Information Technology Security Evaluation [CEM] Part 2 - Security Functional Requirements, Version 2.1, August 1999
Making Sense Of Smart Card Security Certifications - Reid, Looi (2000) (1 citation) (Correct)
No context found.
Common Criteria, Common Criteria for Information Technology Security Evaluation [CEM] Part 3 - Security Assurance Requirements, Version 2.1, August 1999.
Making Sense Of Smart Card Security Certifications - Reid, Looi (2000) (1 citation) (Correct)
No context found.
Common Criteria, Common Criteria for Information Technology Security Evaluation [CEM] Part 1 , Version 2.1, August 1999.
Vote Early, Vote Often, and VoteHere: A Security Analysis of.. - Varner (2001) (Correct)
No context found.
Common Criteria Implementation Board. \Common Criteria for Information Technology Security Evaluation" (May 1998).
Use of XML in the Design and Specification of a - New High Assurance (Correct)
No context found.
Common Criteria Project Sponsoring Organizations. Common Criteria for Information Technology Security Evaluation, August 1999. CCIMB-99-031, Version 2.1.
Network Pump (NP) Security Target - Moore (2000) (Correct)
No context found.
Common Criteria Implementation Board, "Common Criteria for Information Technology Security Evaluation; Part 2: Annexes," Version 2.0, CCIB-97/082AR, 19 December 1997.
Network Pump (NP) Security Target - Moore (2000) (Correct)
No context found.
Common Criteria Implementation Board, "Common Criteria for Information Technology Security Evaluation; Part 1: Introduction and general model," Version 2.0, CCIB-97/081R, 19 December 1997.
First 50 documents
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC