Security Target

Last updated

Common Criteria for Information Technology Security Evaluation, version 3.1 Part 1 (called CC 3.1 or CC) [1] defines the Security Target (ST) as an "implementation-dependent statement of security needs for a specific identified Target of Evaluation (TOE)". In other words, the ST defines boundary and specifies the details of the TOE. In a product evaluation process according to the CC the ST document is provided by the vendor of the product.

Contents

An ST defines information assurance security and functional requirements for the given information system product, which is called the Target of Evaluation (TOE). An ST is a complete and rigorous description of a security problem in terms of TOE description, threats, assumptions, security objectives, security functional requirements (SFRs), security assurance requirements (SARs), and rationales. The SARs are typically given as a number 1 through 7 called Evaluation Assurance Level (EAL), indicating the depth and rigor of the security evaluation, usually in the form of supporting documentation and testing, that the product meets the SFRs.

An ST contains some (but not very detailed) implementation-specific information that demonstrates how the product addresses the security requirements. It may refer to one or more Protection Profiles (PPs). In such a case, the ST must fulfill the generic security requirements given in each of these PPs, and may define further requirements.

Security Target outline

  1. Introduction – an overview of what the TOE does, including key features and purpose.
    • ST Reference
    • TOE Reference
    • TOE Overview
    • TOE Description
  2. Conformance Claims – identifies conformance claims for the TOE evaluation.
    • CC version conformance claims
    • CC Part 2 conformance claims
    • CC Part 3 conformance claims
    • PP conformance claims – strict conformance or demonstrable conformance
  3. Security Problem Definition – describes the threats and assumptions about the operational environment. Objective is to demonstrate the security problem intended to be addressed by the TOE and its operational environment.
    • Threats – an adverse action performed by a threat agent on an asset. Threat agents are described by aspects such as expertise, resources, opportunity, and motivation.
    • Organizational Security Policies (OSP) – OSP is a set of security rules, procedures, or guidelines imposed by an organization in TOEs operational environment.
    • Assumptions – made only about the operational environment of the TOE behavior.
  4. Security Objectives – a concise and abstract statement of the intended solution to the problem specified by the security problem definition. Each security objective must trace back to at least one threat or OSP.
    1. aspect of security which to achieve is the purpose and objective of using certain mitigation measures, such as confidentiality, integrity, availability, user authenticity, access authorisation, accountability.
    2. confidentiality, integrity or availability required to support the applicable foundational requirements.-
  5. Extended Components Definition – the extended components must consist of measurable and objective elements where conformance can be demonstrated.
  6. Security Requirements – defines and describes the SFRs from CC Part 2 and SARs from CC Part 3.
    • Security Functional Requirements – the SFRs form a clear, unambiguous and well-defined description of the expected security behavior of the TOE.
    • Security Assurance Requirements – the SARs form a clear, unambiguous and established description of the expected activities that will be undertaken to gain assurance in the TOE.
    • Security Requirements Rationale – the justification for a security objective for the TOE demonstrates that the SFRs are sufficient and necessary.
  7. TOE Summary Specifications – enables evaluators and potential consumers to gain a general understanding of how the TOE is implemented.
    • Security Functions – function of a zone or conduit to prevent unauthorised electronic intervention that can impact or influence the normal functioning of devices and systems within the zone or conduit. TOE summary specification must describe how the TOE meets each SFR.
    • TOE Security Specifications – a high-level view of how the developer intends to satisfy each SFR.

See also

Related Research Articles

The Common Criteria for Information Technology Security Evaluation is an international standard for computer security certification. It is currently in version 3.1 revision 5.

Trusted Operating System (TOS) generally refers to an operating system that provides sufficient support for multilevel security and evidence of correctness to meet a particular set of government requirements.

In computing, security-evaluated operating systems have achieved certification from an external security-auditing organization, the most popular evaluations are Common Criteria (CC) and FIPS 140-2.

In computer security, mandatory access control (MAC) refers to a type of access control by which the operating system or database constrains the ability of a subject or initiator to access or generally perform some sort of operation on an object or target. In the case of operating systems, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, IO devices, etc. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, an authorization rule enforced by the operating system kernel examines these security attributes and decides whether the access can take place. Any operation by any subject on any object is tested against the set of authorization rules to determine if the operation is allowed. A database management system, in its access control mechanism, can also apply mandatory access control; in this case, the objects are tables, views, procedures, etc.

Multilevel security or multiple levels of security (MLS) is the application of a computer system to process information with incompatible classifications, permit access by users with different security clearances and needs-to-know, and prevent users from obtaining access to information for which they lack authorization. There are two contexts for the use of multilevel security. One is to refer to a system that is adequate to protect itself from subversion and has robust mechanisms to separate information domains, that is, trustworthy. Another context is to refer to an application of a computer that will require the computer to be strong enough to protect itself from subversion and possess adequate mechanisms to separate information domains, that is, a system we must trust. This distinction is important because systems that need to be trusted are not necessarily trustworthy.

The Evaluation Assurance Level of an IT product or system is a numerical grade assigned following the completion of a Common Criteria security evaluation, an international standard in effect since 1999. The increasing assurance levels reflect added assurance requirements that must be met to achieve Common Criteria certification. The intent of the higher levels is to provide higher confidence that the system's principal security features are reliably implemented. The EAL level does not measure the security of the system itself, it simply states at what level the system was tested.

Software assurance (SwA) is a critical process in software development that ensures the reliability, safety, and security of software products. It involves a variety of activities, including requirements analysis, design reviews, code inspections, testing, and formal verification. One crucial component of software assurance is secure coding practices, which follow industry-accepted standards and best practices, such as those outlined by the Software Engineering Institute (SEI) in their CERT Secure Coding Standards (SCS).

Validation is the process of establishing documentary evidence demonstrating that a procedure, process, or activity carried out in testing and then production maintains the desired level of compliance at all stages. In the pharmaceutical industry, it is very important that in addition to final testing and compliance of products, it is also assured that the process will consistently produce the expected results. The desired results are established in terms of specifications for outcome of the process. Qualification of systems and equipment is therefore a part of the process of validation. Validation is a requirement of food, drug and pharmaceutical regulating agencies such as the US FDA and their good manufacturing practices guidelines. Since a wide variety of procedures, processes, and activities need to be validated, the field of validation is divided into a number of subsections including the following:

<span class="mw-page-title-main">Software security assurance</span>

Software security assurance is a process that helps design and implement software that protects the data and resources contained in and controlled by that software. Software is itself a resource and thus must be afforded appropriate security.

The XTS-400 is a multilevel secure computer operating system. It is multiuser and multitasking that uses multilevel scheduling in processing data and information. It works in networked environments and supports Gigabit Ethernet and both IPv4 and IPv6.

A Protection Profile (PP) is a document used as part of the certification process according to ISO/IEC 15408 and the Common Criteria (CC). As the generic form of a Security Target (ST), it is typically created by a user or user community and provides an implementation independent specification of information assurance security requirements. A PP is a combination of threats, security objectives, assumptions, security functional requirements (SFRs), security assurance requirements (SARs) and rationales.

The Common Criteria model provides for the separation of the roles of evaluator and certifier. Product certificates are awarded by national schemes on the basis of evaluations carried by independent testing laboratories.

1√2#5°]4ft-*^$A

Multiple Independent Levels of Security/Safety (MILS) is a high-assurance security architecture based on the concepts of separation and controlled information flow. It is implemented by separation mechanisms that support both untrusted and trustworthy components; ensuring that the total security solution is non-bypassable, evaluatable, always invoked, and tamperproof.

A separation kernel is a type of security kernel used to simulate a distributed environment. The concept was introduced by John Rushby in a 1981 paper. Rushby proposed the separation kernel as a solution to the difficulties and problems that had arisen in the development and verification of large, complex security kernels that were intended to "provide multilevel secure operation on general-purpose multi-user systems." According to Rushby, "the task of a separation kernel is to create an environment which is indistinguishable from that provided by a physically distributed system: it must appear as if each regime is a separate, isolated machine and that information can only flow from one machine to another along known external communication lines. One of the properties we must prove of a separation kernel, therefore, is that there are no channels for information flow between regimes other than those explicitly provided."

The CESG Claims Tested Mark, formerly CSIA Claims Tested Mark, is a UK Government Standard for computer security.

In the United States military integrated acquisition lifecycle the Technical section has multiple acquisition "Technical Reviews". Technical reviews and audits assist the acquisition and the number and types are tailored to the acquisition. Overall guidance flows from the Defense Acquisition Guidebook chapter 4, with local details further defined by the review organizations. Typical topics examined include adequacy of program/contract metrics, proper staffing, risks, budget, and schedule.

<span class="mw-page-title-main">Trusted Computer System Evaluation Criteria</span>

Trusted Computer System Evaluation Criteria (TCSEC) is a United States Government Department of Defense (DoD) standard that sets basic requirements for assessing the effectiveness of computer security controls built into a computer system. The TCSEC was used to evaluate, classify, and select computer systems being considered for the processing, storage, and retrieval of sensitive or classified information.

Digital supply chain security refers to efforts to enhance cyber security within the supply chain. It is a subset of supply chain security and is focused on the management of cyber security requirements for information technology systems, software and networks, which are driven by threats such as cyber-terrorism, malware, data theft and the advanced persistent threat (APT). Typical supply chain cyber security activities for minimizing risks include buying only from trusted vendors, disconnecting critical machines from outside networks, and educating users on the threats and protective measures they can take.

<span class="mw-page-title-main">System and Organization Controls</span> Group of reports produced in an audit

System and Organization Controls (SOC), as defined by the American Institute of Certified Public Accountants (AICPA), is the name of a suite of reports produced during an audit. It is intended for use by service organizations to issue validated reports of internal controls over those information systems to the users of those services. The reports focus on controls grouped into five categories called Trust Service Criteria. The Trust Services Criteria were established by The AICPA through its Assurance Services Executive Committee (ASEC) in 2017. These control criteria are to be used by the practitioner/examiner in attestation or consulting engagements to evaluate and report on controls of information systems offered as a service. The engagements can be done on an entity wide, subsidiary, division, operating unit, product line or functional area basis. The Trust Services Criteria were modeled inconformity to The Committee of Sponsoring Organizations of the Treadway Commission (COSO) Internal Control - Integrated Framework. In addition, the Trust Services Criteria can be mapped to NIST SP 800 - 53 criteria and to EU General Data Protection Regulation (GDPR) Articles. The AICPA auditing standard Statement on Standards for Attestation Engagements no. 18, section 320, "Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting", defines two levels of reporting, type 1 and type 2. Additional AICPA guidance materials specify three types of reporting: SOC 1, SOC 2, and SOC 3.

References

  1. ↑ Common Criteria Portal – http://www.commoncriteriaportal.org/cc/
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.