Ruslan Rakhmetov, Security Vision
One of the main directions of requirements for ensuring information security of financial technologies, defined in the regulations of the Bank of Russia, is to ensure information security of application software through vulnerability analysis.
In particular, this requirement is formulated in the following regulations (already in force and those that will come into force in the near future) of the Bank of Russia:
- Regulation of the Bank of Russia No. 719-P dated 4 June 2020 ‘On Requirements to Information Protection in the Process of Money Transfers and on the Procedure of Control by the Bank of Russia over Compliance with Requirements to Information Protection in the Process of Money Transfers’. Paragraph 1.2 of this act requires money transfer operators, bank payment agents (subagents), information exchange service operators and payment infrastructure service operators to use application software of automated systems and applications that are distributed to customers or interact directly with the Internet (in essence, a client-server) that has been certified in the certification system of the Federal Service for Technical and Export Control or conformity assessment of the Federal Service for Technical and Export Control (FSTEC). Methods and means of ensuring security. Criteria for assessing the security of information technologies. Part 3. Security trust components’. Organisations (except for bank payment agents, subagents) must engage external verification organisations to carry out conformity assessment.
- Regulation of the Bank of Russia No. 757-P dated 20 April 2021 ‘On Establishing Mandatory Requirements for Non-Credit Financial Institutions to Ensure Information Protection in the Course of Activities in the Field of Financial Markets for the Purpose of Counteracting Illegal Financial Transactions’. Clause 1.8 for non-credit financial institutions implementing enhanced and standard levels of information protection specifies a requirement similar to the above mentioned requirement for the use of application software distributed to clients or available for interaction via the Internet, which has passed certification or conformity assessment according to GDS 4. At the same time, conformity assessment of application software may be carried out either independently or with the involvement of an external verification organisation.
- Regulation of the Bank of Russia No. 683-P of 17 April 2019 ‘On the Establishment of Mandatory Requirements for Credit Institutions to Ensure Information Protection in Banking Activities in order to Counteract the Transfer of Funds without the Customer's Consent’. Paragraph 4.1 also specifies a similar requirement for credit institutions (but with some peculiarities that will most likely be eliminated through amendments), while paragraph 4.2 stipulates that credit institutions must engage organisations licensed to carry out activities on technical protection of confidential information to conduct analysis.
Thus, the task of providing analysis of application software for credit and financial institutions is a challenge, which, in accordance with the requirements, can be solved by certification according to FSTEC requirements or conformity assessment according to OUD4. In this case a third-party organisation should be involved.
It is obvious that in the current realities software (especially in terms of interaction with clients) changes very often. Carrying out certification is very problematic, will increase the time of release of new software versions and, in fact, will lead to loss of competitiveness both due to the long lead time of new products and due to the cost of certification. From this point of view (economic efficiency), it is interesting to note the draft Bank of Russia's Decree ‘On Amending the Bank of Russia Regulation No. 683-P dated 17 April 2019 No. 683-P...’ published in June 2021 on the Federal Portal of Draft Regulatory Legal Acts, in which one of the changes concerns the possibility of conducting conformity assessment independently. It is likely that similar changes and approaches will be ‘standardised’ across all acts of the Bank of Russia and will allow organisations to build secure development entirely in-house.
The acts specify conformity assessment in accordance with GOST R ISO/IEC 15408-3-2013 ‘Information technology. Methods and means of ensuring security. Criteria for assessing the security of information technology. Part 3. Security trust components’, but the general nature of GOST and the need to define requirements that take into account the specifics of the financial sector, prompted the Bank of Russia to develop a methodological document - a protection profile (which is provided for by GOST R ISO/IEC 15408-3-2013, where the introduction states: “The security trust components defined in ISO/IEC 15408-3 are the basis for security trust requirements reflected in the protection profile (PP)”). The full name of the methodological document is "PROTECTION PROFILE for application software of automated systems and applications of credit organisations and non-credit financial organisations ’ (hereinafter - Protection Profile) and, in all likelihood, it will be one of the main methodological documents for departments of financial and credit organisations ensuring secure development.
The Protection Profile is a rather voluminous document (155 pages). Let us consider its main sections.
From the general provisions it is obvious that this document is to be used for certification and conformity assessment both by the organisations of the financial and credit sphere themselves and by external organisations involved. It is pointed out that the document takes into account the provisions of national standards of the Russian Federation (we would like to separately note GOST R 57580.1-2017 and GOST 34.603-92 mentioned in the document), industry recommendations (RS BR IBS-2.6-2014) and regulations of the Bank of Russia - in general, the developers of the document tried to convey all the specifics of the mega-regulator's requirements to its supervised entities.
It follows from the introduction that the document has been developed for the assessed confidence level 4 (OUD4), reinforced by a number of components. It should be noted that 719-P and the draft amendments to 683-P provide for the confidence level 5 for smaller organisations (e.g. non-systemically important) - perhaps this document will be updated soon. This section also includes terms and definitions, agreements (operations ‘refinement’, ‘selection’, ‘assignment’ and ‘iteration’ on components of security requirements) and an abstract of the assessment object.
The annotation of the assessment object (AO) contains a detailed description and, in principle, it can be used as an explanation of the object to which requirements from the Bank of Russia regulations on conformity assessment or certification are applied. For the GS it is explained what it is, in which technological areas it is used and what functional safety requirements (FS) are imposed. Properly implemented (and subsequently periodically checked) FTBs will ensure the exclusion of typical defects of application software:
- user data protection (restricting access to platform hardware resources, protected information storages, network communications);
- security management (use of configuration mechanisms, definition of default configuration parameters, assignment of management functions);
- protection of personal identification information;
- protection of OO security functions (restricting the use of supported services, preventing the use of security vulnerabilities, ensuring integrity during installation and update, restricting the use of third-party libraries);
- use of a trusted data transmission path/channel.
The next section of the Protection Profile is dedicated to the relevant external documents (15408 series standards, RS BR IBS-2.6-2014) and is called ‘Compliance Statement’. Special attention can be paid to subsection 3.5, which deals with the strict compliance of the organisation's documents (developed, in turn, on the basis of the Protection Profile) with all the requirements of the Protection Profile, but not limited to them (i.e. the organisation's documents can and should be broader, increasing the detail and taking into account the specifics of the application software used in the organisation). Where strict compliance is not possible, there should be a justification, in line with a risk-based approach, of how the relevant information security breach risk has been handled.
The next section, ‘Defining the security problem’, breaks down the threats that must be considered:
- the threat of information intrusion with vulnerabilities on the organisation's side, through access to equipment;
- the threat of information interception during transmission between components of the automated system with the possibility of viewing or modifying the transmitted information;
- the threat of software exposure on the client side, mainly through the use of malware.
Also in this section is a set of relevant security policies to be implemented for the OO and assumptions about how to use the OO securely. Together, the implementation of the policies and the adaptation of the assumptions should minimise the likelihood of threats being implemented.
Figure 1. Matrix of matching goals to threats and policies
In the next section, the ‘Security Goals’ for the AO and the operating environment are presented, along with a matrix (see Figure 1) that demonstrates which AO security goals are necessary to meet the previously identified threats and to implement security policies. Only the security objectives for the CBO are considered, as the requirements are mainly focused on the application software itself, as specified in clause 2.3.3 of the Protection Profile. The following security objectives for GS are given (one could say that the whole document is aimed at achieving these objectives):
- Security Objective GS-1. The OO shall provide integrity control of its installation and service packs, and effectively use the integrity violation prevention methods provided by the runtime environment, effectively use the documented and supported capabilities provided by the runtime environment. Provide access control (role-based, discretionary, mandated) to objects under the control of the software.
- OO-2 Security Objective. The OO shall provide users and the runtime platform with consistent interfaces for security and maintenance-related management and configuration.
- Security Objective GS-3. The GS shall provide the user with the ability to control the level of disclosure of any personal identifying information.
- Security Objective GS-4. The GS shall use a trusted channel for the transmission of protected information and protect the protected information stored, processed, and transmitted to the components of the PPO.
- Security Objective GS-5. The GS shall ensure that GS security functions are logged and accounted for and prevent the use of platform hardware and software resources that are not accessed by the GS.
- Security Objective GS-6. The GS shall provide for the identification, authentication and authorisation of users of the PPO as required.
The sections defining the functional security requirements and security trust requirements of the OO (as well as definitions of their extended components) provide the corresponding requirements and explanations (see Figure 2) of how fulfilment of the functional security requirements leads to the achievement of the previously identified security objectives.
Figure 2. Matrix of correspondence between functional safety requirements and achievable safety objectives
Let us list the areas (classes) to which the functional safety requirements are dedicated:
- Security audit
- User data protection
- Identification and authentication
- Security management
- Privacy
- FWB Protection
- Access to FBOs
- Trusted route/channel
OO security trust classes (taken from GOST R ISO/IEC 15408-3-2013):
- Security Assignment Assessment
- Development
- Guidelines
- Life Cycle Support
- Testing
- Vulnerability Assessment
- Trust Support
Our brief overview gives an idea of the document's structure and a ‘top-down’ view of the main approaches. Its practical adaptation and application of all requirements can be done by subject matter experts of organisations with a deep understanding of the assessment object. Mastering this document and developing the relevant local documents of the organisation may take quite a long time, but it is intended to raise to a proper level the secure development of application software of financial institutions.
