| NR | Description ENG |
| 1. | For each calling system, a dedicated port must be provided, within which only the minimum set of channel services required by the system is visible (port in Deny by Default mode).
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 2. | Data encryption / signing in the message layer, if used, should be performed using secure algorithms and protocols (e.g. using WS-Security). The use of encryption at the message layer does not absolve you from having to fulfill 3.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 3. | Incoming and outgoing communication from the integration platform must always be encrypted in the transport layer using TLS 1.3 and using secure algorithms. If it is not possible to implement TLS version 1.3, it is allowed to implement TLS version 1.2
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 4. | All incoming and outgoing calls from platforms must always be authenticated using an appropriate mechanism in a given case:
•Two-way SSL,
•OAuth2.0,
•OpenID,
•SAML,
•WS-Security,
•Kerberos.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 5. | Incoming communication from systems outside the internal network of VIG, through the public network (Internet, unsecured with a VPN tunnel) should take place using the Enterprise Gateway component located in the DMZ network. For such communication, all the above-mentioned points must be met.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 6. | Passwords used on the integration platform must be stored in the integration platform password stores (outbound passwords, WebService alias, global variables, JDBC connections, etc) or, after agreeing with VIG IT, in a dedicated configuration database.
Passwords used on the integration platform cannot be hardcoded in the service code, saved in unencrypted configuration files, saved in logs, sent in messages to the queuing system. Passwords must be encrypted with an uncompromising salt hash function
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 7. | Session cookies have the Secure attribute.
Session cookies have the httpOnly attribute.
The application cannot provide session cookie request parameters, CSRF tokens and other sensitive data related to application security.
Session cookies meet the testing requirements of NIST SP800-22.
The application has been successfully tested according to the current edition of the OWASP Testing Guide.
The transmission of data in http requests occurs exclusively via a POST request.
The HSTS mechanism is used.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 8. | Service invocations on the integration platform, after authentication, must be performed in the context of a dedicated (per calling system) user. The user should be defined in Active Directory. We do not define normal and application users on the integration platform.
The user in the context of which the services are performed must be granted the minimum required scope of rights (at least a set of channel services required by a given system), using the ACL mechanism, based on groups in Active Directory to which users belong.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 9. | Each operation in the system is subject to authorization.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 10. | Ability to dump logs to the central log collection system. Related to the requirement 17.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 11. | Access to the application is via an encrypted communication protocol. Data transmission inside and outside the company must be encrypted. The solution must work properly without dangerous communication protocols, e.g. SSL version 3 or lower (data exchange with external systems based on secure protocols).
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 12. | Providing access to all source codes, together with their transfer to the Ordering Party.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 13. | Each user must have an individual account. This applies to system users who handle forms.
Argumentation: Mitigating the risk of cybercriminals attack. Ability to ensure accountability of activities. |
| 14. | It is not possible to establish connection from the application via an unencrypted protocol.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 15. | The solution should provide resistance to known attacks that may compromise the confidentiality, integrity or authenticity of data processed by the application. Disclosed (also by a third party) application weakness or a vulnerability to an attack described in publicly available sources will be treated as a failure of the application with the highest priority.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 16. | Log cleaning registration from the application level - integration with SIEM. Registration of events in SIEM.
Argumentation: The ability to ensure the integrity and authenticity of the history of operations performed. |
| 17. | Ensuring accountability of all user activities. The application allows you to generate reports containing information about the operations performed by a given user in a given period of time or transmit logs to SIEM 16.
Argumentation: The ability to ensure the integrity and authenticity of the history of operations performed. |
| 18. | Use of strong cryptographic algorithms with a symmetric key of at least 256 bits and an asymmetric key of at least 4096 bits.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 19. | The system meets the requirement of using the least necessary privileges for the work of users and applications, e.g. the application does not require that the database account must have database administrator privileges when connecting to a database.
Argumentation: Mitigating the risk associated with too much access to data. |
| 20. | It is possible to define user rights to individual functions of the application. Permissions according to the RBAC methodology.
Argumentation: Mitigating the risk associated with redundant access to data. |
| 21. | Ensuring that all user actions are authenticated. The system must ensure the management of user credentials according to functional requirements formulated separately.
Argumentation: Ability to ensure accountability and authenticity. |
| 22. | Ability to automatically close inactive user sessions for a configurable length of time.
Argumentation: Confidentiality can be ensured. |
| 23. | Ensuring compliance of the application with security updates of the operating system, database and other system components.
Argumentation: Mitigating the risk of cybercriminal attacks. |
| 24. | Compliance with OWASP requirements.
Argumentation: Possibility of ensuring compliance with accepted safety standards. |
| 25. | The IT systems used in the field of electronic access channels are designed in a way that minimizes the probability of accidental initiation of operations by authorized users. In particular, it includes:
customers using the services provided by the company with the use of electronic access channels, in particular performing operations, e.g. on the account of units in the case of insurance contracts with an insurance capital fund,
▪ change of customer data,
▪ all limits granted to the client and authorizations to exceed them, resulting from the concluded insurance contract.
Arguments: Ensuring that the KNF requirements for Electronic Access Channels are met |
| 26. | Secret credentials will not be transmitted in clear text over an unencrypted network connection, particularly the Internet, public or wireless networks. It is required to use two-factor authentication (2FA) |
Богдан Androidteam 16 марта 2022