Comparing and Contrasting TCSEC and ITSEC Security Standards

Security Evaluation Criteria

Let’s assume I am the security manager for an organization that writes chat application software, and my company is promising all chat communications will be secure.

TCSEC

TCSEC stands for “Trusted Computer System Evaluation Criteria”, and was initially issued in 1983 by the National Computer Security Center (part of the NSA). It has since been replaced by the “Common Criteria” international standard. (“Trusted Computer System Evaluation Criteria,” 2019) The TCSEC has four divisions (or classes), labeled D, C, B, A; with A indicating the highest security. They are described, briefly, as such (with included subclasses):

1. D – Minimal protection
2. C – Discretionary protection
   1. C1 – Discretionary Security Protection
   2. C2 – Controlled Access Protection
3. B – Mandatory protection
   1. B1 – Labeled Security Protection
   2. B2 – Structured Protection
   3. B3 – Security Domains
4. A – Verified protection
   1. A1 – Verified Design
   2. Beyond A1

For the chat app to achieve class D designation, nothing has to be done; this is the default for doing nothing except for evaluating the app’s systems and determining they have no security features.

For class C1 achievement, the chat app must have identification and authentication mechanisms. The act of installing those features achieves the mandate of separation of users and personalized data. Further, discretionary access controls are installed, which will enable “roles” for individuals and groups. Roles can make rolling out security profiles en masse an easier proposition. All C1 features must be tested to ensure they’re working.

Achieving class C2 specifies Controlled Access Protection, extending C1’s discretionary access controls. At this point, users are accountable for login procedures, and admins can better monitor and audit security-relevant events, or have the data to properly reallocate resources. This class also specifies media rules for cases of data that should be deleted to save disk space or other sensitive procedures that may destroy, update, or reuse data. For the chat app, it’s important that users actually have messages deleted as desired, and not simply moved to a discoverable disk location. There was a mini-scandal for Snapchat in 2014 when the media played up the idea that the app wasn’t fully deleting certain messages, but many users thought that was what Snapchat did to all messages. (RHEANA MURRAY, 2014)

Class B1 means the chat app has “an informal statement of security policy model, data labeling, and mandatory access control (especially for named subjects and objects)” (Dhillon, Gurpreet, 2017).

Achieving Class B2 security is about Structured Protection. This means the chat app is at a point it can be considered resistant to any kind of penetration. This status is achieved by attaching documentation that specifies a well—defined security model requiring discretionary and mandatory access control that is enforced on all objects and subjects. A detailed analysis of covert channels must be performed. Authentication mechanisms are strengthened. The “trusted computing base” is classified into critical and noncritical elements, in order to better allocation resources in the future (it takes resources to maintain codebases, so why not designate which portions are worth extra effort, which is not as important nor high maintenance. All of this is important for a chat app, as users are more likely to expect privacy and secret communications when using this kind of app as opposed to a less personal app, like a simple phone game.

Class B3 is the point where Security Domains are specified. The chat app’s Reference Monitor must mediate access of all “subjects to objects” in a tamper proof manner. (Dhillon, Gurpreet, p. 248, 2017). The Trusted Computing Base is minimized by removing “non-critical” portions—this helps lighten the load of maintaining an app—fewer files to maintain and monitor. The role of a system admin is defined, recovery procedures are laid out.

Class A1 is reached when formal architecture documentation and verification techniques are established. Sometimes documenting software is the hardest phase to accomplish for a team, so the chat app team project manager must take this phase of project delivery seriously.

ITSEC

The ITSEC stands for “Information Technology Security Evaluation Criteria” and is the European Union’s TCSEC-comparable infosec specification. (Wikibooks, 2019) Part of the documentation outlines seven security assurance requirements:

1. E00: Inadequate assurance
2. E01: Discretionary Security
3. E02: Controlled Access
4. E03: Security Labels
5. E04: Structured Security
6. E05: Security Domains
7. E06: Verified Security

Level E0 is essentially security failure, or “inadequate assurance” of a security target, known as a Target of Evaluation (ToE). (Department of Trade and Industry, London, 1991) The ToE for the chat app should not be set to E0. In fact, E0 is typically considered the absence of a target.

Level E1 is considered part of “Construction Phase: The Development Process.” This means the chat app has a ToE and an informal description of its architecture (how the target will be met). Optionally, the chat app will have planned security testing documentation and a library of such testing programs and tools.

Level E2 is considered the first level in “Phase 1: Requirements for Content and Presentation”. At this point, the chat app has an SSP (System Security Policy) identifying the security objectives and threats. The security target now has a documented rationale identifying the method of use for the chat app product and describes the intended environment and its assumed threats.

Level E3 is described as “Phase 1: Requirements for Evidence”. At this point, the chat app will require the documentation of how the proposed functionality fulfills the security objectives and is adequate to counter assumed threats. Evidence of passed tests is required.

To achieve level E4, or “Phase 1: Evaluator Actions”, an underlying formal model of security policy must be established. The detailed design specification is created, although not necessarily to a formal standard. (Dhillon, Gurpreet, p. 250, 2017)

When achieving level E5 of assurance, also described as the first level of “Phase 2: Architectural Design: Requirements for Content and Presentation,” the chat app will exhibit close correspondence between the detailed security architecture and the actual source code.

Level 6 of the assurance model may be considered “Phase 2: Architectural Design: Requirements for Evidence.” It indicates the chat app has security enforcing functions and the app design is specified in formal style. This architectural spec is consistent with the formal security policy, ensuring the ToE will be met.

Comparison

The ITSEC and TCSEC seem very similar in part and in aim; both are trying to help developers produce secure products. They also seem to have similar numbers of steps when you count the subsections of the TCSEC and the seven steps of the ITSEC. Another similarity is that both of these models now seem to be obsolete, replaced by the “Common Criteria” (Staff, n.d.)

To compare the two schemas in a chart, the similarities become most obvious.

TCSEC	ITSEC	Description
D	E0	Minimal Protection
C1	E1	Discretionary Security
C2	E2	Controlled Access
B1	E3	Security Labels
B2	E4	Structured Security
B3	E5	Security Domains
A1	E6	Verified Security

References

Department of Trade and Industry, London. (1991, June). Information Technology Security Evaluation Criteria ( ITSEC ). Retrieved November 15, 2019, from http://www.iwar.org.uk/comsec/resources/standards/itsec.htm#ass2

Dhillon, Gurpreet. (2017). Principles of Information Systems Security (1.1).

RHEANA MURRAY. (2014, May 9). What Really Happens to Your Deleted Snapchat Photos. Retrieved November 15, 2019, from ABC News website: https://abcnews.go.com/Technology/deleted-snapchat-photos/story?id=23657797

Staff. (n.d.). Publications: New CC Portal. Retrieved from https://www.commoncriteriaportal.org/cc/

Trusted Computer System Evaluation Criteria. (2019). In Wikipedia. Retrieved from https://en.wikipedia.org/w/index.php?title=Trusted_Computer_System_Evaluation_Criteria&oldid=897024036

Wikibooks. (2019). Security Architecture and Design/Security Product Evaluation Methods and Criteria. Retrieved from https://en.m.wikibooks.org/wiki/Security_Architecture_and_Design/Security_Product_Evaluation_Methods_and_Criteria