IS 2620: Developing Secure Systems
description
Transcript of IS 2620: Developing Secure Systems
![Page 1: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/1.jpg)
IS 2620: Developing Secure Systems
Assurance and EvaluationAssurance and Evaluation
Lecture 8March 15, 2012
![Page 2: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/2.jpg)
Reference
Matt Bishop Book Chapters 18, 19, 21
![Page 3: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/3.jpg)
3
Trust
Trustworthy entity has sufficient credible evidence leading one to believe that the system will meet a set of requirements
Trust is a measure of trustworthiness relying on the evidence
Assurance is confidence that an entity meets its security requirements based on evidence provided by the application of assurance techniques SDLC, Formal methods, design analysis, testing etc.
![Page 4: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/4.jpg)
4
Relationships
Policy
Mechanisms
Assurance
Statement of requirements that explicitly definesthe security expectations of the mechanism(s)
Provides justification that the mechanism meets policythrough assurance evidence and approvals based onevidence
Executable entities that are designed and implementedto meet the requirements of the policy
Evaluation standardsTrusted Computer System Evaluation Criteria
Information Technology Security Evaluation Criteria Common Criteria
![Page 5: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/5.jpg)
5
Problem Sources (Neumann)
1. Requirements definitions, omissions, and mistakes
2. System design flaws
3. Hardware implementation flaws, such as wiring and chip flaws
4. Software implementation errors, program bugs, and compiler bugs
5. System use and operation errors and inadvertent mistakes
6. Willful system misuse
7. Hardware, communication, or other equipment malfunction
8. Environmental problems, natural causes, and acts of God
9. Evolution, maintenance, faulty upgrades, and decommissions
![Page 6: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/6.jpg)
6
Types of Assurance Policy assurance is evidence establishing security
requirements in policy is complete, consistent, technically sound
Design assurance is evidence establishing design sufficient to meet requirements of security policy
Implementation assurance is evidence establishing implementation consistent with security requirements of security policy
Operational assurance is evidence establishing system sustains the security policy requirements during installation, configuration, and day-to-day operation
![Page 7: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/7.jpg)
7
Waterfall Life Cycle Model
Requirementsdefinition andanalysis
System andsoftwaredesign
Implementationand unittesting Integration
and systemtesting
Operationandmaintenance
![Page 8: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/8.jpg)
8
Other Models of Software Development
Exploratory programming Develop working system quickly No requirements or design specification, so low
assurance Prototyping (Similar to Exploratory)
Objective is to establish system requirements Future iterations (after first) allow assurance
techniques Formal transformation
Create formal specification Very conducive to assurance methods
![Page 9: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/9.jpg)
9
Models System assembly from reusable components
Depends on whether components are trusted Must assure connections, composition as well Very complex, difficult to assure This is common approach to building secure and
trusted systems Extreme programming
Rapid prototyping and “best practices” Project driven by business decisions Requirements open until project complete Components tested, integrated several times
![Page 10: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/10.jpg)
10
Architectural considerations for assurance
Determine the focus of control of security enforcement mechanism Operating system: focus is on data Applications: more on operations/transactions
Centralized or Distributed Distribute them among systems/components Tradeoffs? Generally easier to “assure” centralized system
Security mechanism may exist in any layer
![Page 11: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/11.jpg)
11
Architectural considerationsExample: Four layer architecture
Application layer Transaction control
Services/middleware layer Support services for applications Eg., DBMS, Object reference brokers
Operating system layer Memory management, scheduling and process control
Hardware Includes firmware
![Page 12: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/12.jpg)
12
Trusted Computing Base(Security an integral part)
Reference monitor (total mediation!) Mediates all accesses to objects by subjects
Reference validation mechanism must be– 1. Tamperproof
2. Never be bypassed
3. Small enough to be subject to analysis and testing – the completeness can be assured
Security kernel Hardware + software implementing a RM
![Page 13: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/13.jpg)
13
Trusted Computing Base TCB consists of all protection mechanisms
within a computer system that are responsible for enforcing a security policy
TCB monitors four basic interactions Process activation Execution domain switching Memory protection I/O operation
A unified TCB may be too large Create a security kernel
![Page 14: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/14.jpg)
14
Techniques for Design Assurance Modularity & Layering
Well defined independent modules Simplifies and makes system more understandable Data hiding Easy to understand and analyze
Different layers to capture different levels of abstraction Subsystem (memory management, I/O subsystem, credit-card
processing function) Subcomponent (I/O management, I/O drivers) Module: set of related functions and data structure
Use principles of secure design
![Page 15: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/15.jpg)
15
Design meets requirements?
Techniques needed To prevent requirements and functionality from being
discarded, forgotten, or ignored at lower levels of design
Requirements tracing Process of identifying specific security requirements that
are met by parts of a description
Informal Correspondence Process of showing that a specification is consistent with
an adjacent level of specification
![Page 16: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/16.jpg)
16
Requirement mapping and informal correspondence
Security Functional Requirements
External Functional Specification
Internal Design Specification
Implementation CodeRequirement
Tracing
InformalCorrespondence
![Page 17: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/17.jpg)
17
Design meets requirements? Informal arguments
Protection profiles Define threats to systems and security objectives Provide rationale (an argument)
Security targets Identifies mechanisms and provide justification
Formal methods: proof techniques Formal proof mechanisms are usually based on logic
(predicate calculus) Review
When informal assurance technique is used Reviews of guidelines Conflict resolution methods Completion procedures
![Page 18: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/18.jpg)
18
Implementation considerations for assurance
Modularity with minimal interfaces Language choice
C vs. Java Java
Configuration management tools Control of the refinement and modification of
configuration items such as source code, documentation etc.
![Page 19: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/19.jpg)
19
Implementation meets Design? Security testing
Functional testing (FT) (black box testing) Testing of an entity to determine how well it meets its specification
Structural testing (ST) (white box testing) Testing based on an analysis of the code to develop test cases
Testing occurs at different times Unit testing (usually ST): testing a code module before
integration System testing (FT): on integrated modules Security testing: product security
Security functional testing (against security issues) Security structural testing (security implementation) Security requirements testing
![Page 20: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/20.jpg)
20
Code development and testing
Code
Unit test
Integrate
Build system
Execute systemTest on current Build
Code
Test the testOn current build
Integrate testedtest into automated
Test suite
Build test suite
Codebugs
![Page 21: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/21.jpg)
21
Operation and maintenance assurance
Bugs in operational phase need fixing Hot fix
Immediate fix Bugs are serous and critical
Regular fix Less serious bugs Long term solution after a hot fix
![Page 22: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/22.jpg)
Courtesy of Professors Chris Clifton & Matt Bishop
22
Evaluation
![Page 23: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/23.jpg)
What is Formal Evaluation?
Method to achieve Trust Not a guarantee of security
Evaluation methodology includes: Security requirements Assurance requirements showing how to establish
security requirements met Procedures to demonstrate system meets
requirements Metrics for results (level of trust)
Examples: TCSEC (Orange Book), ITSEC, CC
![Page 24: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/24.jpg)
Formal Evaluation: Why?
Organizations require assurance Defense Telephone / Utilities “Mission Critical” systems
Formal verification of entire systems not feasible Instead, organizations develop formal evaluation
methodologies Products passing evaluation are trusted Required to do business with the organization
![Page 25: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/25.jpg)
Mutual Recognition Arrangement
National Information Assurance partnership (NIAP), in conjunction with the U.S. State Department, negotiated a Recognition Arrangement that:
Provides recognition of Common Criteria certificates by 24 nations (was 19 in 2005)
Eliminates need for costly security evaluations in more than one country
Offers excellent global market opportunities for U.S. IT industry
![Page 26: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/26.jpg)
An Evolutionary Process
Two decades of research and development…
US-DOD
TCSEC
1983-85
US-NIST
MSFR
1990
FederalCriteria
1992
Europe
ITSEC
1991
Canada
TCPEC
1993
CommonCriteria1993-98
ISO 15408CommonCriteria
1999
European National/Regional
Initiatives
1989-93
Canadian Initiatives
1989-93
![Page 27: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/27.jpg)
Common Criteria: Origin
![Page 28: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/28.jpg)
TCSEC
Known as Orange Book, DoD 5200.28-STD Four trust rating divisions (classes)
D: Minimal protection C (C1,C2): Discretionary protection B (B1, B2, B3): Mandatory protection A (A1): Highly-secure
![Page 29: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/29.jpg)
TCSEC: The Original Trusted Computer System Evaluation Criteria
U.S. Government security evaluation criteria Used for evaluating commercial products
Policy model based on Bell-LaPadula Enforcement: Reference Validation Mechanism
Every reference checked by compact, analyzable body of code
Emphasis on Confidentiality Metric: Seven trust levels:
D, C1, C2, B1, B2, B3, A1 D is “tried but failed”
![Page 30: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/30.jpg)
TCSEC Class Assurances C1: Discretionary Protection
Identification Authentication Discretionary access control
C2: Controlled Access Protection Object reuse and auditing
B1: Labeled security protection Mandatory access control on limited set of objects Informal model of the security policy
![Page 31: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/31.jpg)
TCSEC Class Assurances(continued)
B2: Structured Protections Trusted path for login Principle of Least Privilege Formal model of Security Policy Covert channel analysis Configuration management
B3: Security Domains Full reference validation mechanism Constraints on code development process Documentation, testing requirements
A1: Verified Protection Formal methods for analysis, verification Trusted distribution
![Page 32: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/32.jpg)
How is Evaluation Done?
Government-sponsored independent evaluators Application: Determine if government cares Preliminary Technical Review
Discussion of process, schedules Development Process Technical Content, Requirements
Evaluation Phase
![Page 33: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/33.jpg)
TCSEC: Evaluation Phase
Three phases Design analysis
Review of design based on documentation Test analysis Final Review
Trained independent evaluation Results presented to Technical Review Board Must approve before next phase starts
Ratings Maintenance Program Determines when updates trigger new evaluation
![Page 34: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/34.jpg)
TCSEC: Problems
Based heavily on confidentiality Did not address integrity, availability
Tied security and functionality Base TCSEC geared to operating systems
TNI: Trusted Network Interpretation TDI: Trusted Database management System
Interpretation
![Page 35: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/35.jpg)
Later Standards
CTCPEC – Canada ITSEC – European Standard
Did not define criteria Levels correspond to strength of evaluation Includes code evaluation, development methodology
requirements Known vulnerability analysis
CISR: Commercial outgrowth of TCSEC FC: Modernization of TCSEC FIPS 140: Cryptographic module validation Common Criteria: International Standard SSE-CMM: Evaluates developer, not product
![Page 36: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/36.jpg)
ITSEC: Levels
E1: Security target defined, tested Must have informal architecture description
E2: Informal description of design Configuration control, distribution control
E3: Correspondence between code and security target E4: Formal model of security policy
Structured approach to design Design level vulnerability analysis
E5: Correspondence between design and code Source code vulnerability analysis
E6: Formal methods for architecture Formal mapping of design to security policy Mapping of executable to source code
![Page 37: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/37.jpg)
ITSEC Problems:
No validation that security requirements made sense Product meets goals But does this meet user expectations?
Inconsistency in evaluations Not as formally defined as TCSEC
![Page 38: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/38.jpg)
Replaced TCSEC, ITSEC 7 Evaluation Levels (functionally tested to
formally designed and tested) Functional requirements, assurance
requirements and evaluation methodology Functional and assurance requirements are
organized hierarchically into: class, family, component, and, element. The components may have dependencies.
![Page 39: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/39.jpg)
PP/ST Framework
![Page 40: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/40.jpg)
The Common Criteria defines two types of IT security requirements:
Functional Requirements- for defining security behavior of the IT product or system:• implemented requirements become security functions
Assurance Requirements- for establishing confidence in security functions:• correctness of implementation• effectiveness in satisfying security objectives
Examples:•Identification & Authentication•Audit•User Data Protection•Cryptographic Support
Examples:•Development•Configuration Management•Life Cycle Support•Testing•Vulnerability Analysis
IT Security Requirements
![Page 41: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/41.jpg)
![Page 42: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/42.jpg)
Documentation
Part 1: Introduction and General Model Part 2: Security Functional Requirements Part 3: Security Assurance Requirements CEM
Latest version: 3.1 (variations exist) http://www.commoncriteriaportal.org/public/expert/index.php?menu=2
![Page 43: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/43.jpg)
Class Decomposition
Class
Family
Components
ElementsNote: Applicable to both functional and assurance documents
![Page 44: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/44.jpg)
CC Evaluation 1: Protection Profile
Implementation independent, domain-specific set of security requirementsNarrative OverviewProduct/System descriptionSecurity Environment (threats, overall policies)Security Objectives: System, EnvironmentIT Security Requirements
Functional requirements drawn from CC set
Assurance levelRationale for objectives and requirements
![Page 45: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/45.jpg)
CC Evaluation 2: Security Target
Specific requirements used to evaluate systemNarrative introductionEnvironmentSecurity Objectives
How metSecurity Requirements
Environment and system Drawn from CC set
Mapping of Function to RequirementsClaims of Conformance to Protection Profile
![Page 46: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/46.jpg)
Common Criteria:Functional Requirements
314 page document 11 Classes
Security Audit, Communication, Cryptography, User data protection, ID/authentication, Security Management, Privacy, Protection of Security Functions, Resource Utilization, Access, Trusted paths
Several families per class Lattice of components in a family
![Page 47: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/47.jpg)
Class Example:Communication
Non-repudiation of origin1. Selective Proof. Capability to request verification
of origin
2. Enforced Proof. All communication includes verifiable origin
![Page 48: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/48.jpg)
Class Example: Privacy
1. Pseudonymity– The TSF shall ensure that [assignment:
set of users and/or subjects] are unable to determine the real user name bound to [assignment: list of subjects and/or operations and/or objects]
– The TSF shall be able to provide [assignment: number of aliases] aliases of the real user name to [assignment: list of subjects]
– The TSF shall [selection: determine an alias for a user, accept the alias from the user] and verify that it conforms to the [assignment: alias metric]
2. Reversible Pseudonimity• …
3. Alias Pseudonimity1. …
![Page 49: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/49.jpg)
Common Criteria:Assurance Requirements
231 page document 10 Classes
Protection Profile Evaluation, Security Target Evaluation, Configuration management, Delivery and operation, Development, Guidance, Life cycle, Tests, Vulnerability assessment, Maintenance
Several families per class Lattice of components in family
![Page 50: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/50.jpg)
Common Criteria:Evaluation Assurance Levels
1. Functionally tested2. Structurally tested3. Methodically tested and checked4. Methodically designed, tested, and reviewed5. Semi-formally designed and tested6. Semi-formally verified design and tested7. Formally verified design and tested
![Page 51: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/51.jpg)
Common Criteria:Evaluation Process
National Authority authorizes evaluators U.S.: NIST accredits commercial organizations Fee charged for evaluation
Team of four to six evaluators Develop work plan and clear with NIST Evaluate Protection Profile first If successful, can evaluate Security Target
![Page 52: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/52.jpg)
Defining Requirements
ISO/IEC Standard 15408
A flexible, robust catalogue of standardized IT security
requirements(features and assurances)
Protection Profiles
Consumer-driven security requirements in specific
information technology areas
Operating Systems Database Systems Firewalls Smart Cards Applications Biometrics Routers VPNs
Access ControlIdentification
AuthenticationAudit
Cryptography
![Page 53: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/53.jpg)
Industry Responds
Protection Profile
Consumer statement of IT security requirements to industry in a
specific information technology area
Security Targets
Vendor statements of security claims for their IT
products
CISCO Firewall Lucent Firewall Checkpoint Firewall Network Assoc. FW Security
Features and
Assurances
Firewall Security Requirements
![Page 54: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/54.jpg)
Demonstrating Conformance
IT Products
Vendors bring IT products to independent, impartial testing
facilities for security evaluation
Security Features
and Assurances
Private sector, accredited security testing laboratories
conduct evaluations
Common Criteria
Testing Labs
Test results submitted to the National Information Assurance Partnership
(NIAP) for post-evaluation validation
Test Reports
![Page 55: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/55.jpg)
Validating Test Results
Laboratory submits test report to Validation
Body
Test Report
Validation Body validates laboratory’s test results
Common Criteria
Validation Body
NIAP issues Validation Report and Common
Criteria Certificate
Validation Report
National Information Assurance Partnership
Common Criteria Certificate
TM
![Page 56: IS 2620: Developing Secure Systems](https://reader035.fdocuments.us/reader035/viewer/2022070415/56814f66550346895dbd1b8c/html5/thumbnails/56.jpg)
Common Criteria:Status
About 80 registered products (2005) Only one at level 5
(Java Smart Card) Several OS at 4 Likely many more not registered
223 Validated products (Oct, 2007) Tenix Interactive Link Data Diode Device Version
2.1 at EAL 7+