Does Fininly conduct penetration testing of its network, infrastructure, and services?

Penetration testing is conducted to measure the security posture of Fininly Services and Infrastructure. Fininly has an external penetration test performed at least once per calendar year.

The objective of those penetration tests is to identify design or functionality issues in Fininly Services that could expose Data or Customers to risks from malicious activities.

Each external penetration test is performed by an internationally recognized, independent third-party software security testing company.

Each penetration test:

• encompasses both the internal and external network and authenticated application layer,
• includes at least 80 hours of manual effort by the testing company,
• probes for weaknesses in network perimeters or other infrastructure elements and any weaknesses in process or technical countermeasures relating to Fininly’s Services that could be exploited by a malicious party, and
• identifies (at a minimum) the following security vulnerabilities: invalidated or unsanitised input; broken access control; broken authentication and session management; cross‐site scripting (XSS) flaws; buffer overflows; injection flaws; improper error handling; insecure storage; denial of service; insecure configuration management; proper use of SSL/TLS; proper use of encryption; and anti‐virus reliability and testing.

Can customers conduct their own penetration tests?

Customer-led penetration testing can be conducted upon request at security@fininly.com and is subject to conditions prior to carrying out the tests.

Does Fininly conduct vulnerability scanning of its network, infrastructure, and services?

Vulnerability scanning is performed on a continuous basis by Fininly in accordance with the vulnerability management policy. Technologies used are:

WhiteHat Security scanning for 24/7 web application dynamic application security testing (DAST),

SonarCloud for static application security testing (SAST) before each release,

Software Composition Analysis 24/7. We scan the libraries and dependencies used in our products to identify vulnerabilities and ensure the vulnerabilities are managed.

Renovate for ensuring that open-source dependencies always are the latest available version.

Azure Security Center and Azure Monitor for daily infrastructure, network, and application vulnerability scanning. Retests and on-demand scans are performed on an as-needed basis.

Is there a formal Software Development Life Cycle (SDLC) process?

Fininly’s software development practices across each of the engineering teams are aligned with the Secure Development Lifecycle (SDLC) methodology and follow Scrum and Agile approaches.

Detailed policies and processes for the development of the Fininly Services have been designed with optimal security and quality in mind.

The principles of security by design and default are implemented and rooted in training, coaching, pair programming, code review comments, coding tools, and branch policies in Azure DevOps.

Fininly has implemented segregated environments for development, testing, and production as a means to support the segregation of duties and prevent unauthorized changes to production.

In addition, production data is not used or copied to non-production environments. Test scripts and synthetic data are created for use in the development and stage environments.

How does Fininly manage changes in the platform?

All application code changes are tested, peer-reviewed, and approved prior to implementation into production. The production and non-production environments are deployed in their own Azure Active Directory and their own Azure Subscriptions, thus completely separated, and changes are tested according to the nature of the change in an environment separate from production prior to deployment into a production release.

Tests include functionality unit testing, integration testing, smoke tests, manual regression testing, and load testing. Extensive security testing is conducted.

All change requests are logged, whether approved or rejected, on a standardized central system. The approval of all change requests and the results thereof are documented. Access to migrate change to production requires formal approval and is restricted to authorized personnel. Code management tools enforce branch protection policies to help ensure users cannot bypass standard change controls.