Security Architecture and Design/Security Product Evaluation Methods and Criteria

Security Product Evaluation Methods and Criteria

• A security evaluation examines the security-relevant parts of a system, meaning the TCB, access control mechanisms, reference monitor, kernel, and protection mechanisms. The relationship and interaction between these components are also evaluated.
• There are different methods of evaluating and assigning assurance levels to systems. Two reasons explain why more than one type of assurance evaluation process exist:
  • methods and ideologies have evolved over time, and
  • various parts of the world look at computer security differently and rate some aspects of security differently
• An evaluation program establishes a trust between the security product vendor and the customer.

Evaluation Standards

• Information Technology Security Evaluation Criteria (ITSEC)- EU
• Trusted Computing Security Evaluation Criteria (TCSEC) -US
• Common Criteria- Hybrid of ITSEC and TCSEC

Rainbow Series

The Rainbow series was a series of books to cover all the areas of security like

• Red Books- Network Security
• Orange Books- Operating System Security
• Yellow- Security Risk Management
• Violet- Database Security

Orange Book or TCSEC

Overview

• TCSEC was developed by US DoD and was published in an Orange book and hence also called as Orange Book
• It mainly addresses the confidentiality, but not integrity and mainly addresses government and military requirements.
• It is used to evaluate whether a product contains the security properties the vendor claims it does and whether the product is appropriate for a specific application or function.
• It is used to review the functionality, effectiveness, and assurance of a product during its evaluation, and it uses classes that were devised to address typical patterns of security requirements.
• TCSEC provides a classification system that is divided into different assurance levels with A representing the highest and D the lowest.
  • A: Verified protection
  • B: Mandatory protection: Variants- B1<B2<B3
  • C: Discretionary protection: Variants-C1<C2
  • D: Minimal security

The levels are concentric.i.e if a product is assured at level B2, that implies it meets D,C1,C2 and B1

The Criteria

• Security policy- The policy must be explicit and well defined and enforced by the mechanisms within the system.
• Identification- Individual subjects must be uniquely identified.
• Labels Access- Control labels must be associated properly with objects.
• Documentation- Documentation must be provided, including test, design, and specification documents, user guides, and manuals.
• Accountability- Audit data must be captured and protected to enforce accountability.
• Life cycle assurance- Software, hardware, and firmware must be able to be tested individually to ensure that each enforces the security policy in an effective manner throughout their lifetimes.
• Continuous protection- The security mechanisms and the system as a whole must perform predictably and acceptably in different situations continuously.

The Assurance Levels

• Division D: Minimal Protection- It is reserved for systems that have been evaluated but fail to meet the criteria and requirements of the higher divisions.
• Division C: Discretionary Protection- The C rating category has two individual assurance ratings within it.
  • C1: Discretionary Security Protection
    • Based on individuals and/or groups.
    • It requires a separation of users and information, and identification and authentication of individual entities is provided.
    • The type of environment that would require this rating is one in which users are processing information at the same sensitivity level; thus, strict access control and auditing measures are not required.
    • It would be a trusted environment with low security concerns
  • C2: Controlled Access Protection
    • Users need to be identified individually to provide more precise access control and auditing functionality.
    • Logical access control mechanisms are used to enforce authentication and the uniqueness of each individual’s identification
    • The type of environment that would require systems with a C2 rating is one in which users are trusted but a certain level of accountability is required.
    • Overall, C2 is regarded to be the most reasonable class for commercial applications, but the level of protection is still relatively weak
• Division B: Mandatory Protection- Mandatory access control is enforced by the use of security labels. The architecture is based on the Bell-LaPadula security model, and evidence of reference monitor enforcement must be available
  • B1: Labeled Security
    • Each data object must contain a classification label and each subject must have a clearance label.
    • When a subject attempts to access an object, the system must compare the subject’s and object’s security labels to ensure that the requested actions are acceptable.
    • Data leaving the system must also contain an accurate security label.
    • The security policy is based on an informal statement, and the design specifications are reviewed and verified.
    • This security rating is intended for environments that require systems to handle classified data.
  • B2: Structured Protection
    • The security policy is clearly defined and documented, and the system design and implementation are subjected to more thorough review and testing procedures.
    • This class requires more stringent authentication mechanisms and well-defined interfaces among layers.
    • Subjects and devices require labels, and the system must not allow covert channels.
    • The type of environment that would require B2 systems is one that processes sensitive data that requires a higher degree of security and are relatively resistant to penetration and compromise.
  • B3: Security Domains
    • In this class, more granularity is provided in each protection mechanism, and the programming code that is not necessary to support the security policy is excluded.
    • The reference monitor components must be small enough to test properly and be tamper-proof
    • The system must be able to recover from failures without its security level being compromised.
    • The type of environment that requires B3 systems is a highly secured environment that processes very sensitive information and are highly resistant to penetration.
• Division A: Verified Protection- Formal methods are used to ensure that all subjects and objects are controlled with the necessary discretionary and mandatory access controls. The design, development, implementation, and documentation are looked at in a formal and detailed way
  • A1: Verified Design
    • Formal techniques are used to prove the equivalence between the TCB specifications and the security policy model.
    • More stringent change configuration is put in place with the development of an A1 system, and the overall design can be verified
    • The type of environment that would require A1 systems is the most secure of secured environments. This type of environment deals with top-secret information and cannot adequately trust anyone using the systems without strict authentication, restrictions, and auditing.

TCSEC Myths

• It looks specifically at the operating system and not at other issues like networking, databases, and so on.
• It focuses mainly on one attribute of security, confidentiality, and not at integrity and availability.
• It works with government classifications and not the protection classifications that commercial industries use.
• It has a relatively small number of ratings, which means many different aspects of security are not evaluated and rated independently.

Red Book or TNI

Overview

• Red books also called Trusted Network Interpretation (TNI),addresses security evaluation topics for networks and network components.
• Like the Orange Book, the Red Book does not supply specific details about how to implement security mechanisms; instead, it provides a framework for securing different types of networks
• It rates the confidentiality of data and operations that happen within a network and the network components and products.

Security Items addresses in the red Books

• Communication integrity
  • Authentication Protects against masquerading and playback attacks. Mechanisms include digital signatures, encryption, timestamp, and passwords.
  • Message integrity Protects the protocol header, routing information, and packet payload from being modified. Mechanisms include message authentication and encryption.
  • Non-repudiation Ensures that a sender cannot deny sending a message.Mechanisms include encryption, digital signatures, and notarization.
• Denial-of-service prevention
  • Continuity of operations Ensures that the network is available even if attacked. Mechanisms include fault tolerant and redundant systems and the capability to reconfigure network parameters in case of an emergency.
  • Network management Monitors network performance and identifies attacks and failures. Mechanisms include components that enable network administrators to monitor and restrict resource access.
• Compromise protection
  • Data confidentiality Protects data from being accessed in an unauthorized method during transmission. Mechanisms include access controls, encryption, and physical protection of cables.
  • Traffic flow confidentiality Ensures that unauthorized entities are not aware of routing information or frequency of communication via traffic analysis. Mechanisms include padding messages, sending noise, or sending false messages.
  • Selective routing Routes messages in a way to avoid specific threats.Mechanisms include network configuration and routing tables.

Information Technology Security Evaluation Criteria (ITSEC)

Overview

• As TCSEC was developed by US, ITSEC was developed by the EU to address all the security evaluation issues.
• The ITSEC had two main evaluation attributes
  • Functionality- When the functionality of a system’s protection mechanisms is being evaluated, the services that are provided to the subjects like access control mechanisms, auditing, authentication, and so on are examined and measured.
  • Assurance- Assurance, is the degree of confidence in the protection mechanisms,and their effectiveness and capability to perform consistently. Assurance is generally tested by examining development practices, documentation, configuration management, and testing mechanisms.

Evaluation Criteria

ITSEC had 10 classes F1 to F10 to evaluate the functional requirements and 7 classes E0 to E6 to evaluate the assurance requirements.

• Security functional requirements
  • F00:Identification and authentication
  • F01:Audit
  • F02:Resource utilization
  • F03:Trusted paths/channels
  • F04:User data protection
  • F05:Security management
  • F06:Product access
  • F07:Communications
  • F08:Privacy
  • F09:Protection of the product’s security functions
  • F10:Cryptographic support
• Security assurance requirements
  • E00:Guidance documents and manuals
  • E01:Configuration management
  • E02:Vulnerability assessment
  • E03:Delivery and operation
  • E04:Life-cycle support
  • E05:Assurance maintenance
  • E06:Development
  • Testing

ITSEC Ratings

• The ratings are based on effectiveness and correctness.
  • Effectiveness means that the TOE meets the security claims that the vendor has specified. This analysis looks at the construction and operational vulnerabilities and the ease of use, to ensure that the proper security settings do not get in the way of productivity.- rates functionality
  • Correctness deals with how the TOE was built and implementation issues. This type of analysis looks at the architectural design, how the security mechanisms enforce the policy, and the operational documentation and environment.- rates assurance.

TCSEC vs ITSEC

• TCSEC bundles functionality and assurance into one rating, whereas ITSEC evaluates these two attributes separately.
• ITSEC provides more flexibility than TCSEC.
• ITSEC addresses integrity, availability, and confidentiality whereas TCSEC addresses only confidentiality.
• ITSEC also addresses networked systems, whereas TCSEC deals with stand-alone systems.

Common Criteria

Overview

• Common criteria was the result of ISO's attempt to gather several organizations to come together to combine and align existing and emerging evaluation criteria like TCSEC, ITSEC, Canadian Trusted Computer Product Evaluation Criteria [CTCPEC], and the Federal Criteria.
• It was developed through a collaboration among national security standards organizations within the United States, Canada, France, Germany, the United Kingdom, and the Netherlands.
• Under the Common Criteria model, an evaluation is carried out on a product and is assigned an Evaluation Assurance Level (EAL)

Benefits of the CC

• Helps consumers by reducing the complexity of the ratings and eliminating the need to understand the definition and meaning of different ratings within various evaluation schemes.
• Helps manufacturers because now they can build to one specific set of requirements if they want to sell their products internationally, instead of having to meet several different ratings with varying rules and requirements.

CC Assurance Levels

• The Common Criteria has seven assurance levels which ranges from EAL1(lowest), where functionality testing takes place, through EAL7(highest), where thorough testing is performed and the system design is verified.
  • EAL 1 Functionally tested
  • EAL 2 Structurally tested
  • EAL 3 Methodically tested and checked
  • EAL 4 Methodically designed, tested, and reviewed
  • EAL 5 Semi-formally designed and tested
  • EAL 6 Semi-formally verified design and tested
  • EAL 7 Formally verified design and tested

Protection Profile

• A protection profile is a mechanism that is used by CC in its evaluation process to describe a real-world need of a product that is not currently on the market.
• Protection Profile Characteristics
  • Contains the set of security requirements, their meaning and reasoning, and the corresponding EAL rating that the intended product will require.
  • Describes the environmental assumptions, the objectives, and the functional and assurance level expectations. Each relevant threat is listed along with how it is to be controlled by specific objectives.
  • Justifies the assurance level and requirements for the strength of each protection mechanism.
  • Provides a means for a consumer, or others, to identify specific security needs; this is the security problem that is to be conquered
  • Provide the necessary goals and protection mechanisms to achieve the necessary level of security and a list of the things that can go wrong during the type of system development.
• Protection Profile Sections
  • Descriptive elements Provides the name of the profile and a description of the security problem that is to be solved.
  • Rationale Justifies the profile and gives a more detailed description of the real-world problem to be solved. The environment, usage assumptions, and threats are illustrated along with guidance on the security policies that can be supported by products and systems that conform to this profile.
  • Functional requirements Establishes a protection boundary, meaning the threats or compromises that are within this boundary to be countered. The product or system must enforce the boundary established in this section.
  • Development assurance requirements Identifies the specific requirements that the product or system must meet during the development phases, from design to implementation.
  • Evaluation assurance requirements Establishes the type and intensity of the evaluation.

CC Components

• Protection profile- Description of needed security solution.
• Target of evaluation- Product proposed to provide needed security solution.
• Security target- Vendor’s written explanation of the security functionality and assurance mechanisms that meet the needed security solution; in other words, “This is what our product does and how it does it.”
• Packages—EALs- Functional and assurance requirements are bundled into packages for reuse. This component describes what must be met to achieve specific EAL ratings.

Certification and Accreditation

Certification

• Certification is the comprehensive technical evaluation of the security components and their compliance for the purpose of accreditation.
• A certification process may use safeguard evaluation, risk analysis, verification, testing, and auditing techniques to assess the appropriateness of a specific system.
• The goal of a certification process is to ensure that a system, product, or network is right for the customer’s purposes.

Accreditation

• Accreditation is the formal acceptance of the adequacy of a system’s overall security and functionality by management.
• Certification is a technical review that assesses the security mechanisms and evaluates their effectiveness. Accreditation is management’s official acceptance of the information in the certification process findings.