Threats
Threats | Description of threats |
T.TSF_FALURE | Security mechanisms of the TOE may fail, leading to a compromise of the TSF. |
T.UNAUTORIZES_UPDATE | A user may gain unauthorized access to the TOE data and TOE executable code. A malicious user, process, or external IT entity may masquerade as authorized entity in order to gain unauthorized access to data or TOE resources. A malicious user, process or external IT entity may misrepresent itself as the TOE to obtain identification and authentication data. |
T.UNAUTHORIZED_UPDATE | Malicious party attempts to supply the end user with an update to the products that may compromise the security features of the TOE. |
T.USER_DATA_REUSE
T. WEAK_CRYPTOGRAPHY | User data may be inadvertently sent to destination not intended by the original sender. Adversary may attack a weak cryptography algorithms or attempts cryptographic against the key space. To brake the cipher john ripper or brute force attack. In CybSec uses the john ripper to obtain the password and gain the information on MYSQL databases. |
T.UNAUTHORIZES_ADMINISTRATOR_ACCESS | An adversary can attempt to attack administrator access that may be operate and manage MYSQL and the database. it could be allows malicious action that ompromisec the security of the application to gain into the data. |
T. ACCESS
| Unauthorised Access to the Database. An outsider or system user who is not (currently) an authorised database user accesses the DBMS. This threat includes: Impersonation – a person, who may or may not be an authorised database user, accesses the DBMS, by impersonating an authorised database user (including an authorised user impersonating a different user who has different – possibly more privileged – access). |
T.DATA | Unauthorised Access to Information. An authorised database user accesses information contained within a DBMS without the permission of the database user who owns or who has responsibility for protecting the data. |
T.ATTACK | Undetected Attack. An undetected compromise of the DBMS occurs as a result of an attacker (whether an authorised user of the database or not) attempting to perform actions that the individual is not authorised to perform. This threat is included because, whatever countermeasures are provided to address the other threats, there is still a residual threat of a violation of the security policy occurring by attackers attempting to defeat those countermeasures. |
Assumptions
Assumption | Description of assumption |
A.NO_TOE_BYPASS | Information cannot flow onto the network to which the vpn clients hosts is connected without passing through the TOE. |
A.PHYSICAL | Physical security, commensurate with the value of the TOE and the data it contains, is assumed to be provided by the environments |
A.TRUSTED_ADMID | TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. |
A.PROPER_USER | the client of the application is authorised program in compliance with the connected undertaking security policy. |
A.PROBER_ADMIN | In the CybSec company the administrator of the application is trusted to manage the program within compliance of the provide the security policy. |
A.SECURE_LOCATION | It is assumed that the place of server in secure location. |
A.NETWORK | When required by the TOE, in a distributed environment the underlying network services are assumed to be based on secure communications protocols which ensure the authenticity of users. |
A.ACCESS | The underlying system is configured such that only the approved group of individuals may obtain access to the system. |
A.COMMUNICATION | The communication interconnections between the TOE and all non-TOE components and systems, are protected by the environment – by physical or logical security measures – against disclosure as appropriate regarding the need for information disclosure of the clients |
Security objective
O.ACCESS The TOE must provide end-users and administrators with the capability of controlling
and limiting access, by identified individuals, or grouping of individuals, to the data or
resources they own or are responsible for, in accordance with the P.ACCESS security
policy. To this end the TOE has the following more specific objectives:
O.ACCESS.CONTROL The TOE must allow database users who own or are responsible
for data to control the access to that data by other authorised
database users.
O.ACCESS.OBJECTS The TOE must prevent the unauthorised or undesired
disclosure, entry, modification, or destruction of data and
database objects, database views, and database control and
audit data.
O.ADMIN.TOE The TOE, where necessary in conjunction with the underlying system, must provide
functions to enable an authorised administrator to effectively manage the TOE and its
security functions, ensuring that only authorised administrators can access such
functionality.
O.AUDIT The TOE must provide the means of recording security relevant events in sufficient
detail to help an administrator of the TOE to:
- a) detect attempted security violations, or potential misconfiguration of the TOE
security features that would leave the database open to compromise; and
- b) hold individual database users accountable for any actions they perform that are
relevant to the security of the database in accordance with P.ACCOUNT.
Environmental Security Objectives
O.ADMIN.ENV The TOE, where necessary in conjunction with the underlying system, must provide
functions to enable an authorised administrator to effectively manage the TOE and its
security functions, ensuring that only authorised administrators can access such
functionality.
O.FILES The underlying system must provide access control mechanisms by which all of the
DBMS-related files and directories (including executables, run-time libraries, database
files, export files, redo log files, control files, trace files, and dump files) may be
protected from unauthorised access.
O.PHYSICAL Those responsible for the TOE must ensure that those parts of the TOE that are critical
to the security policy are protected from physical attack.
O.TRUST Those responsible for the TOE must ensure that only highly trusted users have the
privilege which allows them to:
- a) set or alter the audit trail configuration for the database;
- b) alter or delete any audit record in the database audit trail;
- c) create any user account or modify any user security attributes;
- d) authorise use of administrative privileges.
O.AUTHDATA Those responsible for the TOE must ensure that the authentication data for each user
account for the TOE as well as the underlying system is held securely and not disclosed
to persons not authorised to use that account. In particular:
- a) The media on which the authentication data for the underlying operating system
and/or secure network services is stored shall not be physically removable from
the underlying platform by unauthorised users;
- b) Users shall not disclose their passwords to other individuals;
- c) Passwords generated by the system administrator shall be distributed in a secure
manner.
Security requirement
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:
- a) Start-up and shutdown of the DATABASE audit functions;
- b) All auditable events for the basic level of audit, AS IDENTIFIED IN TABLE 4
BELOW; and
- c) [assignment: other specifically defined DATABASE auditable events].
FAU_GEN.1.2 The TSF shall record within each DATABASE audit record at least the following
information:
- a) Date and time of the DATABASE event, type of DATABASE event, DATABASE
subject identity, and the outcome (success or failure) of the event; and
- b) For each DATABASE audit event type, based on the auditable event definitions of
the functional components included in the PP/ST, [assignment: other DATABASE
audit relevant information].
FAU_GEN.2.1 The TSF shall be able to associate each auditable DATABASE event with the identity of
the DATABASE user that caused the event.
FAU_SAR.1.1 The TSF shall provide authorised DATABASE users with the capability to read all
database audit information from the DATABASE audit records.
FAU_SAR.1.2 The TSF shall provide the DATABASE audit records in a manner suitable for the
DATABASE user to interpret the information.
FAU_SAR.3.1 The TSF shall provide the ability to perform searches and sorting of DATABASE audit
data based on DATABASE user identity [assignment: additional criteria with logical
relations].
FAU_SEL.1.1 The TSF shall be able to include or exclude auditable DATABASE events from the set of
audited DATABASE events based on the following attributes:
- a) event type;
- b) DATABASE subject identity;
- c) DATABASE object identity;
- d) [assignment: list of additional attributes that DATABASE audit selectivity is based
upon].
FAU_STG.1.1 The TSF shall protect the stored DATABASE audit records from unauthorised deletion.
FAU_STG.1.2 The TSF shall be able to prevent modifications to the DATABASE audit records.
FAU_STG.4.1 The TSF shall prevent auditable events except those taken by the authorised user with
special rights and [assignment: other actions to be taken in case of audit storage failure]
if the audit trail is full.
5.1.2 Class FDP – Security Attribute Based Access Control
FDP_ACC.1.1 The TSF shall enforce the DATABASE OBJECT access control SFP on
- a) DATABASE subjects;
- b) DATABASE objects;
- c) ALL PERMITTED operations ON DATABASE OBJECTS BY A DATABASE SUBJECT
covered by the SFP.
FDP_ACF.1.1 The TSF shall enforce the DATABASE OBJECT access control SFP to DATABASE objects
based on:
- a) the identity of the owner of the database object; and
- b) the object access privileges to the database object held by the database
subject; and
- c) the database administrative privileges of the database subject.
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled
DATABASE subjects and controlled DATABASE objects is allowed:
- a) if the user associated with the database subject is the owner of the database
object, then the requested access is allowed; or
- b) if the database subject has the database object access privilege for the
requested access to the database object, then the requested access is allowed;
or
- c) otherwise access is denied, unless access is explicitly authorised in
accordance with the rules specified in FDP_ACF.1.3.
FDP_ACF.1.3 The TSF shall explicitly authorise access of DATABASE subjects to DATABASE objects
based on the following additional rules:
- a) if the database subject has a database administrative privilege to override
the database object access controls for the requested access to the database
object, then the requested access is allowed;
- b) [assignment: rules, based on DATABASE security attributes, that explicitly
authorise access of DATABASE subjects to DATABASE objects].
FDP_ACF.1.4 The TSF shall explicitly deny access of DATABASE subjects to DATABASE objects based
on the FOLLOWING ADDITIONAL RULES: [assignment: rules, based on DATABASE security
attributes, that explicitly deny access of DATABASE subjects to DATABASE objects].
FDP_RIP.2.1 The TSF shall ensure that any previous information content of a DATABASE resource is
made unavailable upon the allocation of a resource to all DATABASE objects.
5.1.3 Class FIA – Identification and Authentication
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual
DATABASE users:
- database user identity,
- b) database object access privileges,
- c) database administrative privileges,
- d) [assignment: list of security attributes].
FIA_UID.1.1 The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the
DATABASE user to be performed before the DATABASE user is identified.
FIA_UID.1.2 The TSF shall require each DATABASE user to be successfully identified before allowing
any other TSF-mediated actions on behalf of that DATABASE user.
FIA_USB.1.1 The TSF shall associate the appropriate DATABASE user security attributes with
DATABASE subjects acting on behalf of that DATABASE user.
5.1.4 Class FMT – Security Management
FMT_MSA.1.1 The TSF shall enforce the DATABASE OBJECT access control SFP to restrict the ability
to modify the DATABASE OBJECT security attributes [assignment: list of DATABASE
security attributes] to [assignment: the authorised identified DATABASE roles].
FMT_MSA.3.1 The TSF shall enforce the DATABASE OBJECT access control SFP to provide restrictive
default values for DATABASE OBJECT security attributes that are used to enforce the
DATABASE OBJECT ACCESS CONTROL SFP.
FMT_MSA.3.2 The TSF shall allow [assignment: the authorised identified roles] to specify alternative
initial values to override the default values when A DATABASE object or information is
created.
FMT_MTD.1.1 The TSF shall, ACCORDING TO TABLE 5, restrict the ability to PERFORM OPERATIONS
on TSF data to database administrative users.
FMT_REV.1.1 The TSF shall restrict the ability to revoke security attributes associated with the
DATABASE users and DATABASE objects within the TSC to:
- a) authorised database administrators for (users and objects);
- b) authorised database users (only for the database objects they own or
database objects for which they have been granted database object access
privileges allowing them to revoke security attributes).
- c) [assignment: the authorised identified roles].
FMT_REV.1.2 The TSF shall enforce the rules:
- a) revocation of database object access privileges shall take effect prior to all
subsequent attempts to establish access to that database object;
- b) revocation of database administrative privileges shall take effect prior to
when the database user begins the next database session;
- c) [assignment: specification of revocation rules].
FMT_SMR.1.1 The TSF shall maintain the DATABASE roles:
- a) database administrative user;
- b) database user;
- c) [assignment: the authorised identified DATABASE roles].
FMT_SMR.1.2 The TSF shall be able to associate DATABASE users with DATABASE roles.
5.1.5 Class FPT – Protection of the TOE Security Functions
FPT_RVM.1.1 The TSF shall ensure that TSP enforcement functions are invoked and succeed before
each function within the TSC is allowed to proceed.
FPT_SEP.1.1 The TSF shall maintain a security domain for its own execution that protects it from
interference and tampering by untrusted DATABASE subjects.
FPT_SEP.1.2 The TSF shall enforce separation between the security domains of DATABASE subjects
in the TSC.
5.1.6 Class FRU – Resource Utilisation
FRU_RSA.1.1 The TSF shall enforce maximum quotas of the following resources: [assignment:
controlled DATABASE resources] that an individual DATABASE user can use over a
specified period of time.
5.1.7 Class FTA – TOE Access
FTA_MCS.1.1 The TSF shall restrict the maximum number of concurrent DATABASE sessions that
belong to the same DATABASE user.
FTA_MCS.1.2 The TSF shall enforce, by default, a limit of a [assignment: default number] DATABASE
sessions per DATABASE user.
Rationale
Security Objectives Rationale
This section provides a demonstration of why the identified security objectives (Paragraph
are suitable to counter the identified threats and meet the stated security policies
(Paragraph 3.3), as stated in Table 1. The rationale for environmental security
objectives is provided by
.
6.1.1 T.ACCESS Rationale
61 T.ACCESS (Unauthorised Access to the Database) is directly countered by
O.I&A.TOE which ensures the TOE can protect the global data and resources of the
database from access by persons not authorised to use that database. O.I&A.TOE
ensures the TOE, in conjunction with the underlying operating system, has the means
of authenticating the claimed identity of any user. O.ACCESS.CONTROL,
O.ADMIN.TOE and O.RESOURCE provide support by controlling access to database
control data and administrative functionality that might otherwise enable circumvention
of database access controls. O.SEP, O.FILES and O.I&A.ENV together
prevent bypass of the TOE.
6.1.2 T.DATA Rationale
62 T.DATA (Unauthorised Access to Information) is directly countered by
O.ACCESS.OBJECTS. O.ACCESS.OBJECTS ensures access is controlled to information
contained within specific database objects. O.ACCESS.RESIDUAL ensures
access is prevented to residual information held in memory or reused database
objects. O.I&A.TOE provides support by providing the means of identifying the user
attempting to access a database object. O.ACCESS.CONTROL and O.ADMIN.TOE
provide support by controlling access to database control data and administrative
functionality that might otherwise enable circumvention of database object access
controls.
6.1.3 T.RESOURCE Rationale
63 T.RESOURCE (Excessive Consumption of Resources) is countered directly by
O.RESOURCE, which ensures the TOE has the means of limiting the consumption of
such resources, including the enforcement of limits on the number of concurrent sessions
an individual may have. O.I&A.TOE provides support by providing the means
of identifying the user attempting to use resources. O.ACCESS.CONTROL and
O.ADMIN.TOE provide support by controlling access to database control data and
administrative functionality that might otherwise enable circumvention of resource
utilisation controls.
6.1.4 T.ATTACK Rationale
64 T.ATTACK (Undetected Attack) is countered directly by O.AUDIT, which ensures the
TOE has the means of recording security relevant events which could be indicative of
an attack aimed at defeating the TOE security features. O.I&A.TOE provides support
by reliably identifying the user responsible for particular events, where the attacker is
an authorised user of the database. O.ACCESS.CONTROL and O.ADMIN.TOE provide
support by controlling access to audit configuration data which only highly
trusted individuals must be allowed to view and modify
T.PHYSICAL
67 T.PHYSICAL is directly provided by O.PHYSICAL, which protects critical parts of
the TOE from physical attack.
P.ACCESS Rationale
69 P.ACCESS is satisfied by O.ACCESS.OBJECTS and O.RESOURCE.
O.ACCESS.OBJECTS ensures that the subjects using the TOE are able to control
access to the objects which they own or for which they are responsible.
O.RESOURCE ensures that the TOE is able to control the consumption of resources.
T.ABUSE.USER Rationale
65 T.ABUSE.USER (Abuse of Privilege) is countered directly by O.AUDIT, which
ensures the TOE has the means of recording security relevant events which could be
indicative of abuse of privilege by an authorised user of the database (whether intentional
or otherwise). O.I&A.TOE provides support by reliably identifying the user
responsible for particular events, thus ensuring that the user can be held accountable
for actions for which he or she is responsible. O.ACCESS.CONTROL and
O.ADMIN.TOE provide support by controlling access to audit configuration data
which only highly trusted individuals must be allowed to view and modify.
P.ACCOUNT Rationale
70 P.ACCOUNT is directly satisfied by O.AUDIT which ensures that the subjects using
the TOE are accountable for their actions by recording details of attempted security
violations and other actions which have been configured for auditing. P.ACCOUNT is
also indirectly satisfied by O.ACCESS which ensures that the accounting data is protected.
Security Requirements Rationale – OS Authentication
OS Authentication requires that the underlying platform provide an authenticated user
identity to the database. This has been reflected in the security requirements for the IT
Environment (section 5.6).
O.I&A.TOE Suitability
O.I&A.TOE Identification and authentication checks are performed by the underlying
operating system, as is protection of the authentication data.
6.4 Security Requirements Rationale – Database Authentication
6.4.1 Suitability of Security Requirements
Table 11 correlates the IT security objectives to the SFRs which satisfy them (as indicated
by a YES), showing that each IT security objective is satisfied by at least one