Contents
The target of Evaluation Definition
Security Functional Requirements (SFRs)
Security Assurance Requirements (SARs)
Introduction
The assessment plan of specific security requirements of a given system reports the controls and control improvements to be assessed, established on the goal of the Evaluation, and the developed controls found and discussed in the system security plan. Insecurity audit and certification, the security evaluation process describes the assessment's scope, mainly showing whether a full or partial evaluation will be done and if the assessment aims to support the first pre-authorization activities inter-related with the proposed changed system. Moreover, the security evaluation plan defines the methods used in every control.
In this document, XYZ, an online retail company, has implemented an online store called MyWebstore. The company intends to request common criteria certification for their web-based new system. MyWebstore system operates on top of MySQL database management system (DBMS), which stores the product, user, operational, security, metadata, and development information, in addition, the backend of the newly implemented system runs on top of a no-SQL database that store user reviews. The common criteria in the new web-based system are the consumers, developers, and evaluators in the new system. According to XYZ, the new system backend resides on a Linux-based operating system (Ubuntu), supporting the root user and web application user.
This document has six sections: Introduction, Target of Evaluation (TOE) description, security problems, security objectives, security functional requirements, and security assurance requirements. This section briefly highlights a brief background description of security assessment and the MyWebstore system. The second section entails the target of evaluation overview and description. The third section describes the security problems to be certified in the newly implemented system, including threats and assumptions about the operational environment Of TOE. The security objective section will include objects developing from the problem description. The fifth section describes the functional security requirements, focusing on user data protection and identification and authentication in the MyWebstore system. Finally is security assurance requirements for TOE to enable EAL2 certification.
The target of Evaluation Definition
This section identifies the target of Evaluation, derivative devices configuration possibilities, and the overview of TOE based on the MyWebstore system. The evaluation target is the system or product that is the target topic of the assessment.
TOE identification
The target of Evaluation (TOE) is the Linux (Ubuntu) platform Focal Fossa 20.04, software rev nine and A with a dedicated system MyWebstore.
|
IC Masket Name |
IC Version |
Master Identification number |
Firmware revision |
OST revision |
|
Focal Fossa |
20.4 |
0061h and 0105h |
9 and A |
0022H |
In TOE identification, the IC maskset name is referred to the product hardware identification, the maskset version is reconditioned when the whole maskset is changed. The IC version is modernized for any update in hardware. To make a full TOE identification, the product name, IC version, firmware version, and libraries version must be fully described.
In consumer end requirements on the MyWebstore system, various derivative appliances may need to be configured by either system developer during implementation or the by the end-user on settings during personalization exercise. Both consumer requirements use the same hardware design but different master identification numbers. Derivative user settings configuration may impact NVM memory size, available operating system, the availability of the processor, as entailed in derivative devices configuration probability table:
Derivative devices configuration possibilities
|
Features |
Possible Values |
|
Single wire Protocol |
Active, Inactive |
|
Serial peripheral interface |
Active, Inactive |
|
ISO-7816 Asynchronous Receiver Transmitter |
Active, Inactive |
|
Next Step Cryptography Accelerator |
Active, Inactive |
|
Enhanced DES accelerator |
Active, Inactive |
|
Library protection unit |
Active, Inactive |
|
Non-volatile Memory size |
Configurable by 128 Kbytes aggregation from 1280 Kbytes – 384 Kbytes |
Security problem definition
The definition of the security problem to be observed on MyWebstore's new system. According to common criteria (CC), a security problem is obtaining the security problem description that falls outside the CC's scope. The objective goal of the security problem is to denote the security problem planned to be solved by the Target of Evaluation. However, it should be highlighted that the result importance of an assessment strongly relies on the security target, and the importance of the security target (ST) firmly relies on the excellent definition of security problem. Therefore, XYZ company spends tremendous resources on the MyWebstore web-based system, uses properly established processes, and inspects to acquire an excellent security problem.
Threats
This section of the security problem definition discusses the threats to be faced by the target of Evaluation and its operational environment. In systems, threats include unfortunate actions practiced by a threat agent. In this section, the threats faced by the MyWebstore system and its operational environment include;
Injection Attacks; MyWebstore system is a web-based application that could have vulnerabilities to injection threats through users while they POST feedback in the input field. This could happen by an attacker inputting an attack code and deceiving the server into decoding the codes as a system command and responding as the cybercriminal intended. Injection attacks include Email Header Injection, SQL injections, Cross-Site Scripting, and much more. An injection attack led to unrestricted access to the database and admin privileges.
Data-Modification: this could also be termed as unauthorized data modification. Unauthorized individuals may change the user data stored by the Target of Evaluation. Data modification threat applies to processing the changing codes gotten by the TOE.
Security Misconfiguration: according to the daily analysis collected, security misconfiguration is the most familiar web application security threat globally. The weakness attack exists due to developers and system admins forgetting to use different credentials. Exploiting and detecting default settings has become easy with the new cyber technology; hence implications of such weaknesses can be experienced once the MyWebstore system has been launched.
Unvalidated Redirects and Forwards: every website launched redirects a user to other pages within the website. When the credibility of redirections has been evaluated, the web-based system exposes its vulnerabilities to URL cybercriminals. Unvalidated redirects can easily be seen by a user being redirected by a malicious link to phishing sites or web-holding malware.
System administrator violating user privacy: this could be experienced by an administrator at the MyWebstore system exposing the user information to unauthorized personnel.
Assumptions
This section of the security problem definition discusses the assumptions made on the operational environment to provide security functionality. If the evaluation target is positioned in an operational environment that has not attained these assumptions, the TOE may have a problem giving all security functionality. The assumption may be physical, connectivity, or personnel in the operational environment. Xyz company assumptions on physical aspects of the operational environment include;
MyWebstore system's physical operational environment assumed that the TOE servers would be positioned in a room structured to reduce electromagnetic emanations.
Also, it is assumed that the MyWebstore system administrator consoles will be stationed in a closed, restricted access room.
On personnel aspects of the operational environment, it is assumed that;
The users of the Evaluation target will receive sufficient training on the MyWebstore new system user interface to easily use the Target of Evaluation.
The assumption made from the target of evaluation users is that they are privileged classified information from the TOE.
In addition, it is assumed that customers of the MyWebstore User interface will not be able to copy and paste their passwords while logging in to the system; instead, they will only input by keying in.
It is assumed that operating system administration of platforms where TOE components are running and consumers accessing the local area network is not careless or hostile and will follow and abide by rules and regulations provided by the TOE documentation.
Finally, the connectivity aspect of the operational environment assumption on target of Evaluation include;
It is assumed that the MyWebstore system will require a PC workstation that has at least 10GB of hard disk space for the TOE to run effectively.
It is assumed that the MyWebstore system will not be connected to the untrusted network.
It is assumed that where TOE is located has access to an SQL database server.
In the assessment period, these assumptions are considered; they are true, and they are not put into trial. Therefore, the assumption on TOE can only be assumed in the operational environment.
Security Objectives
The security objective is a brief and abstract simple statement of the prospected solution to the defined problems by the security problem definition.
1. The target of Evaluation shall maintain the confidentiality of all information transmitted between the system and the servers.
2. The TOE shall ensure only authorized users and applications access personal data
3. MyWebstore system shall check user authentication credentials before permitting access to the servers.
4. MyWebstore system shall not permit accessing data according to the Data Acess policy.
5. The TOE shall restrict access to external links access to the user interface.
6. The TOE shall give data encryption, triple data encryption standard, and advanced security functionality standards.
Security objectives rationale
The main goal of this section of the security objective rationale is to include all the security objectives and give a reason or logical basis for a course of action.
|
Assumption / Threat policy |
Rationale |
|
Injection attack |
This assumption is addressed by security which ensures that the server has an up-to-date firewall to harden it for any intended attack on the database. |
|
Data modification |
The assumption is addressed by user privilege, which ensures that only authorized personnel can edit, search, and update /her data |
|
Security Misconfiguration |
This assumption is addressed by an authentication check-up, which ensures no login to the system before the TOE checks credentials from the database and authorizes accessibility. |
|
Unvalidated redirects and forwards |
This assumption is addressed by external link access, which ensures that the TOE shall restrict any external link access to the system. |
|
System administrator violating user privacy |
This assumption is addressed by consumer data protection, which ensures that the TOE shall give data encryption, triple data encryption standard, and advanced encryption standard for the security functionality. |
Security requirements
Security requirements consist of the security functional requirement (SFRs) and the security assurance requirement (SARs).
Security Functional Requirements (SFRs)
These are the translation of the security objectives for the Target of Evaluation. They are a highly detailed level of abstraction, though they have to finish translation and be independent of any particular technological development. The common criteria need this translation into a standardized language. In the TOE, functional security requirements for the security target based on user data protection and identification and authentication consist of the following;
|
Class heading |
Class family |
Description |
|
User data Protection |
FDP_ACC.1 |
Subset access control |
|
FDP_ACF.1 |
Security attribute-based access control |
|
|
Identification and Authentication |
FIA_ATD.1 |
User attribute definition |
|
FIA_SOS.1 |
Verification of secrets |
|
|
FIA_UID.2 |
User identification before any action |
|
|
FIA_UAU.2 |
User authentication before any action |
User Data Protection
FDP_ACC.1 Subset Access Control
The consumer in the MyWebstore security function will enforce the [User Access Control SFP] on [
Subjects: Login, Buy_New_Product, wire_complaint
Objects: User Privileges, User Account Attribute
Operations: Create, Read, Delete, Order]
FDP_ACF.1 Security Attribute Based Access Control
The consumer in MyWebstore security function shall enforce the [User Access Control SFP] to object-based.
Identification and Authentication (FIA)
FIA_ATD.1 – User Attribute Definition
The TOE security function shall maintain the following list of security attributes belonging to each user
[User identity, Authentication Status, Privileges]
FIA_SOS.1 Verification of secrets
The TOE security function shall provide an operation to verify that secret [the following metrics:
User password length at least five characters, including a number, letter, and symbol
Admin assigns the user to change password at first session initiation after password
(Administrator)]
FIA_UID.2 User Identification before any Action
The target of evaluation security function shall require every user/consumer to successfully verified and logged in before any other security function on the user
FIA_UAU.2 User Authentication before Any Action
The TOE security function shall ask every user to be authenticated before allowing any other target of evaluation security function action on behalf of that user.
Security Assurance Requirements (SARs)
These are illustrations of how the target of Evaluation is to be assessed. The SARs for the assessment target is the assurance components of Evaluation Assurance Level 4 (EAL4) augmented with ALC_FLR.1.
|
|
|
|||||||||
|
|
ADV_TDS.3 |
Basic modular design |
|||||||||
|
AGD: Guidance Documents |
AGD_OPE.1 |
Operational user guidance |
|||||||||
|
AGD_PRE.1 |
Preparative procedures |
||||||||||
|
ALC: Lifecycle Support |
ALC_CMC.4 |
Production support, acceptance procedures and automation |
|||||||||
|
ALC_CMS.4 |
Problem tracking CM coverage |
||||||||||
|
ALC_DEL.1 |
Delivery procedures |
||||||||||
|
ALC_DVS.1 |
Identification of security measures |
||||||||||
|
ALC_FLR.1 |
Basic flaw remediation |
||||||||||
|
ALC_LCD.1 |
Developer defined lifecycle model |
||||||||||
|
ALC_TAT.1 |
Well-defined development tools |
||||||||||
|
AST: Security Target evaluation |
ASE_CCL.1 |
Conformance claims |
|||||||||
|
ASE_ECD.1 |
Extended components definition |
||||||||||
|
ASE_INT.1 |
ST introduction |
||||||||||
|
ASE_OBJ.2 |
Security objectives |
||||||||||
|
ASE_REQ.2 |
Derived security requirements |
||||||||||
|
ASE_SPD.1 |
Security problem definition |
||||||||||
|
ASE_TSS.1 |
TOE summary specification |
||||||||||
|
ATE: Tests |
ATE_COV.2 |
Analysis of coverage |
|||||||||
|
ATE_DPT.1 |
Testing: security enforcing modules |
||||||||||
|
ATE_FUN.1 |
Functional testing |
||||||||||
|
ATE_IND.2 |
Independent testing - sample |
||||||||||
|
AVA: Vulnerability Analysis |
AVA_VAN.3 |
Focused vulnerability analysis |
References
Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Sep 2012, Version 3.1, Revision 4, CCMB-2012-09-001
Comments
Post a Comment