14.1 Security requirements of information systems
Objective : To ensure that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems which provide services over public networks.
14.1.1 Information security requirements analysis and specification
In the context of the Service see chapter 14.1.2 and 14.1.3 below.
14.1.2 Securing application services on public networks
Availability of the connection to the Internet of the Service is contractually guaranteed by the hosting Provider through SLAs.
The Service is protected against Distributed Denial of Service (DDoS) that act at the level 3,4 and 7 of the OSI model.
When entering 365Talents' infrastructure, all HTTP requests are filtered by a Web Application Firewall (WAF) as defined in chapter 13.1.1 of 13 - Communications security.
365Talents can manage domain names, owned by the Customer, technically delegated by the Customer (website and/or domain name for sending e-mail). In this case, 365Talents will provide the Customer with all the information required to set up DNS delegations.
14.1.3 Protecting application services transactions
Data transfers performed through data exchange services between the Clients and 365Talents over the Internet are :
- Encrypted by SSH mechanisms (sFTP transfers) or TLS (API transfers) as defined in 10 - Cryptography
- Authenticated by usage of a pair of public/private keys in the case of sFTP transfers as defined in 9 - Access control.
- Authenticated by various mechanisms in the case of API transfers as defined in 9 - Access control.
All HTTPs connections to any 365Talents.com domain (*.365Talents.com) use a certificate signed by a certification authority (no self-signed certificate).
Connection and usage of the Service by the Users is performed over the Internet and :
- Communications are encrypted by TLS as defined in 10 - Cryptography.
- Users are authenticated either by the Client's SSO or by providing their credentials and their authentication is maintained by the use of a JWT token as defined in 9 - Access control.
- The usage of HTTPs is made mandatory by the implementation of HTTP Strict Transport Security (HSTS) as defined in 10 - Cryptography.
- Integrity of the requests of creation, modification or deletion of data is protected by the use of an anti Cross-Site Request Forgery (CSRF, XSRF), either they are made by a standard User of an Administrator of the Service.
- At the moment the Service doesn't use any cookie but 365Talents keeps the right to do so in the future. In this case, cookies will be secured with the HTTP-ONLY and SECURE options.
Data transfer between 365Talents and its mail provider are performed over the Internet and are :
- Encrypted by TLS (API transfer over HTTPs) as defined in 10 - Cryptography.
- Authenticated by usage of an API Key as defined in 9 - Access control.
365Talents public APIs documentation:
A swagger is available to obtain an inventory of all the public APIs available for the Service, with OpenAPIv3 at https://\
14.2 Security in development and support processes
Objective : To ensure that information security is designed and implemented within the development lifecycle of information systems
14.2.1 Secure development policy
Standard Methodologies are used, including PTES, OWASP…
365Talents has defined secure development best practices, including :
- Storage of the data in standard canonical format
- Encoding string of characters before display
- Data input validation
- Escape of user data before processing requests
- Parameters are isolated from the URL of the request
- Use of an ORM
- Data validation on server side
- No default password
- Non-reversible encryption of password before storage
- Systematic use of HTTPs/TLS for every communication and implementation of HSTS
- Limited session duration
- Session deletion when log-out
- Test on pre-production before going live
- Storage of applicative logs
- Systematic anti-malware scans of all files before treatment of the upload request
- Use of an anti Cross-Site request forgery (CSRF, XSRF) mechanism for all requests of data creation, modification or deletion.
Developers are regularly made aware of these practices. In addition, code quality tools are systematically run each time a developer wants to publish new code. Finally, regular "secret" scans are carried out on deployed images to detect them.
Access to the source code is restricted (see chapter 9.4.5 in 9 - Access control). A code versioning system is in place.
All produced code is peer-reviewed before being pushed into pre-production.
Internal development follow the same principles than the ones for the Service as described above, including Infrastructure-as-code.
14.2.2 System change control procedures
The source code of the Service is stored in a decentralized versioning management system (git). Its access is controlled as described in 9.4.5 of 9 - Access control and changes can be submitted only by authorized users.
Approval for detailed proposals is obtained through various Agile rituals before work commences and in accordance with product requirements for the Service. Changes are accepted in the same way prior to implementation. A change-log is produced for each release and shared among stakeholders before changes are deployed in production.
The system documentation set is updated on the completion of each change as part of the code submission process.
A version control for all software updates is maintain through the use of the versioning management system. The same system ensure an audit trail of all change requests in conjunction with the project management tool.
All changes are tested in the pre-production environment.
Changes on the production infrastructure (components and their configuration) are managed in the same way as 365Talents has deployed an Infrastructure-as-code approach.
14.2.3 Technical review of applications after operating platform changes
Every changes on the Service are tested in pre-production environment before going into production. Any incident due to the changes of the platform are monitored and alerts are raised to the technical teams of 365Talents through dedicated channels.
Every change on internal tools (like the monitoring tools) are reviewed in the same way than for the Service.
14.2.4 Restrictions on changes to software packages
Software packages used by the platform and either vendor-supplied or open-source are used as-is and are not changed, exceptions are limited to strict minimum possible and discouraged.
14.2.5 Secure system engineering principles
Standard development methodologies are used, including PTES, OWASP…
365Talents applies the following Secure-by-design principles :
- Minimize attack surface area by exposing publicly only what is strictly needed
- Establish secure defaults
- The principle of Least privilege : users, developers and DevOps are given privileges limited to what they strictly need
- Fail securely
- Defense in depth
- Separation of duties
- Avoid security by obscurity
- Keep security simple
- Fix Security issues correctly
Secure system engineering principles are the same for internal systems (like monitoring tools).
14.2.6 Secure development environment
365Talents implements a secure development environment by :
- Segregating development, pre-production and production environment
- Deploying per-developper development environment
- Deploying per-client pre-production and production environment with logical segregation between them
- Using anonymized data in non-production environments.
- Requiring proper review before code is merged from development to non-development environments.
- Monitoring changes to the environment and code through the use of versioning control softwares ; every modification to code is recorded with a unique ID, a timestamp, username of the user that has performed the change and explanation of the change.
Development for internal tools follows the same principle
14.2.7 Outsourced development
N/A, 365Talents doesn't outsource developments.
14.2.8 System security testing
Security functionalities of the Service are tested as any other functionalities by 365Talents.
Like any other functionalities, each change to code impacting security functionalities has to be peer-reviewed.
In addition, the Service security functionalities are regularly tested by 365Talents' Clients through pen-tests.
14.2.9 System acceptance testing
System acceptance testing is realized through te deployment of each version of the Service in pre-production environment.
All changes to code have to be peer-reviewed.
14.3 Test data
Objective : To ensure the protection of data used for testing
14.3.1 Protection of test data
By default the data imported from production to pre-production or development environment are automatically anonymized : users' names are hashed and emails are disabled.
The copy and anonymization of the data is performed by an automated workflow, therefore all actions are logged.