Let\u2019s 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. <\/p>\n\n\n\n
TCSEC stands for \u201cTrusted Computer System Evaluation Criteria\u201d, and was initially issued in 1983 by the National Computer Security Center (part of the NSA). It has since been replaced by the \u201cCommon Criteria\u201d international standard. (\u201cTrusted Computer System Evaluation Criteria,\u201d 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): <\/p>\n\n\n\n
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\u2019s systems and determining they have no security features. <\/p>\n\n\n\n
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 \u201croles\u201d 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\u2019re working. <\/p>\n\n\n\n
Achieving class C2 specifies Controlled Access Protection, extending C1\u2019s 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\u2019s 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\u2019t fully deleting certain messages, but many users thought that was what Snapchat did to all messages. (RHEANA MURRAY, 2014) <\/p>\n\n\n\n
Class B1 means the chat app has \u201can informal statement of security policy model, data labeling, and mandatory access control (especially for named subjects and objects)\u201d (Dhillon, Gurpreet, 2017). <\/p>\n\n\n\n
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\u2014defined 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 \u201ctrusted computing base\u201d 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. <\/p>\n\n\n\n
Class B3 is the point where Security Domains are specified. The chat app\u2019s Reference Monitor must mediate access of all \u201csubjects to objects\u201d in a tamper proof manner. (Dhillon, Gurpreet, p. 248, 2017). The Trusted Computing Base is minimized by removing \u201cnon-critical\u201d portions\u2014this helps lighten the load of maintaining an app\u2014fewer files to maintain and monitor. The role of a system admin is defined, recovery procedures are laid out. <\/p>\n\n\n\n
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. <\/p>\n\n\n\n
The ITSEC stands for \u201cInformation Technology Security Evaluation Criteria\u201d and is the European Union\u2019s TCSEC-comparable infosec specification. (Wikibooks, 2019) Part of the documentation outlines seven security assurance requirements: <\/p>\n\n\n\n
Level E0 is essentially security failure, or \u201cinadequate assurance\u201d 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. <\/p>\n\n\n\n
Level E1 is considered part of \u201cConstruction Phase: The Development Process.\u201d 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. <\/p>\n\n\n\n
Level E2 is considered the first level in \u201cPhase 1: Requirements for Content and Presentation\u201d. 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. <\/p>\n\n\n\n
Level E3 is described as \u201cPhase 1: Requirements for Evidence\u201d. 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. <\/p>\n\n\n\n
To achieve level E4, or \u201cPhase 1: Evaluator Actions\u201d, 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) <\/p>\n\n\n\n
When achieving level E5 of assurance, also described as the first level of \u201cPhase 2: Architectural Design: Requirements for Content and Presentation,\u201d the chat app will exhibit close correspondence between the detailed security architecture and the actual source code. <\/p>\n\n\n\n
Level 6 of the assurance model may be considered \u201cPhase 2: Architectural Design: Requirements for Evidence.\u201d 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. <\/p>\n\n\n\n
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 \u201cCommon Criteria<\/a>\u201d<\/mark> (Staff, n.d.) <\/p>\n\n\n\nTo compare the two schemas in a chart, the similarities become most obvious. <\/h3>\n\n\n\n