Security

Application Security

Ensuring strict, yet agile processes for releasing code, building safe and secure applications and interfaces, and having restricted and limited access to production environments, helps to reduce the likelihood of compromising consumer data and sensitive information. 

Evidencing your environment via data flows and application diagrams also ensures an equal understanding of these environments at a high level.  These documents should include details of connected APIs, gateways, services, infrastructure, support systems, and vendors.  In the data flow and application diagram, indicate names of tools and partners with their responsibilities and functions.  In any instance where Personally Identifiable Information (PII) or card data is managed outside the Synctera ecosystem (e.g. via the use of KYC and screening tools outside of the Synctera ecosystem), diagrams and details for how PII or card data is collected, managed, and stored, as well as what controls are enforced for proper data security must be defined. Note that Companies that choose to separately store or use customer PII and card data will have increased Sponsor Bank expectations surrounding the control requirements and independent testing/certification.

Companies that have completed a SOC 2 Type 2 Report should provide a copy of that report as part of the due diligence process.

AppSec Policy

The Company should also have an Application Development & Security (AppSec) policy that includes requirements for secure development, code reviews, vulnerability scanning, and penetration testing. The AppSec policy must fit an organization’s size and business model. An AppSec policy establishes acceptable security and protection boundaries developers and security teams can operate as they develop new software.  API security scanning and monitoring policies should be documented within the application development program. This includes an established Software Development Lifecycle standard.

Although many of these components are documented processes, enforcement of these standards are of the utmost importance.  For example, establishing consistent and frequent checks and balances including executing regular vulnerability scanning and contracting external resources to perform manual and automated penetration testing, will help to ensure known vectors of entry can be patched and addressed quickly before a breach occurs.  

Software Development Lifecycle Policy

A FinTech’s Application Development & Security Policy must include specific steps, controls, governance, and processes tied to the SDLC method deployed at the organization. An application security policy establishes acceptable security and protection boundaries, including connected APIs which are used by cloud-native application developers and security teams as they develop new software.

An SDLC Policy must detail the necessary checks and balances that occur and when. It shall include the details for each stage and the life gates that need to be met to progress through the next stage in the process. If you utilize any tools in the tracking of the development lifecycle, there may be additional resources from those systems.

An SDLC Policy for a smaller organization may be consolidated into fewer steps. However, an SDLC Policy, regardless of the size of the organization, must include standards such as static code analysis (whether automated or manual) and industry best practices such as code authors being prevented from merging their own pull requests (PRs) in production or live environments. Automated processes for simple static repositories and code rollbacks should also be developed.

Standards and controls tied to software development must be established from an early stage and must be documented prior to the transfer of funds, regardless of whether the transactions are considered external test users or live customer transactions. It is required that a formal SDLC Policy is established and enforced prior to accepting any external users (including Friends and Family)

How to start an AppSec Program with the OWASP Top 10 is a great guide to the development of an Application Security Program, along with additional resources including What is the SDLC and How You Should Approach the Secure Development Lifecycle. This may include additional applicable processes, such as software change management, code reviews, vulnerability scanning, and penetration testing.

General details such as separation between test and production must be detailed such as "Development work must include a separation between production, development, and test environments, and at a minimum have at least a defined separation between the development/test and production environments unless approved by the product owner."

If a separate change management policy has not been developed, add an additional section to include details on how changes are managed, including scheduled and emergency changes.

Details for how exceptions are managed must be included for example: "exception to this policy must be reviewed and approved by the Technical Lead or above assigned to the project. Any employee or contractor who violates this policy may be subject to disciplinary action for misconduct and/or performance based on the administrative process appropriate to their employment."

Although recommendations and guidelines have been included in this memo, this list is not exhaustive of free of charge and publicly available resources that are accessible via Google. Additional templates and guidelines may be found via publicly available sources.

Application & Data Flow Diagram

Data flows and application diagrams should include details of connected APIs, gateways, services, infrastructure, support systems, and vendors (3rd Parties).  In the data flow and application diagram, indicate names of tools and partners with their responsibilities and functions.  In any instance when PII data is managed outside the Synctera ecosystem (e.g. via the use of KYC and screening tools outside of the Synctera ecosystem), diagrams and details for how Personally Identifiable Information is collected, managed, and stored, as well as what controls are enforced for proper data security must be defined.  If a SOC 2, Type II report is available, please share.  

See a sample diagram below:

AppSec Controls

The Company should also incorporate basic app security controls as part of good security hygiene. This includes the following:

• Sign-up process that may include two-factor authentication and one-time passwords (e.g via. text or email confirmation)
• Strong password policy (at least 8 characters)
• Deny-list of most commonly used passwords 
• Lock-out controls after unsuccessful login attempts (8 times maximum)
• Automatic log-out after customer inactivity
• One-time password (OTP)

Additional tools may be implemented to help further strengthen security controls such as (some of these may be required for higher risk customer bases):

• Geolocational data tools (e.g. device ID and IP address)
• Multi-factor authentication for login from unrecognized device or geography
• Biometrics (e.g. face recognition or selfie-check)

Information Security

Building an in-depth information security (InfoSec) program is imperative to the long term success of a Company.   Ensuring strict, yet agile processes while documenting and enforcing standards are the essence of this domain.  InfoSec is a broad construct and overlaps related domains such as AppSec and Business Continuity, to help encapsulate a best practices program for overseeing all data and IT security domains inside and outside of your developed apps.  Furthermore, designing, documenting and enforcing a defense in depth model for InfoSec will not only help to simplify implementation, but also help with due diligence efforts conducted by the Sponsor Banks.

Set expectations that InfoSec is not a “nice-to-have” but a requirement to “go-to-market” and an ongoing requirement for “keep-in-market”.  Sponsor Banks will prevent Companies from going live if they cannot clearly show InfoSec industry standards are being adhered to and enforced.

The Company is required to maintain an Information Security policy that includes a set of rules, conditions, and guidelines that document how information technology (IT) systems, tools, and resources should be used, managed, and protected. It should also include details about Acceptable Use and Cybersecurity / Data Security.

Encryption

The Company must also maintain a plan and procedure detailing the use and administration of cryptographic keys, including utilized methods, PCI requirements, and deprecation.  This is incredibly important if there is localized storage of sensitive data outside of the Synctera ecosystem.  

Vulnerability Scanning

All components of your InfoSec and AppSec programs act as daily hygiene to ensure a Company’s programs are set up for success.  Think of Vulnerability Scanning and remediation planning (more to follow) like brushing your teeth.  

A Vulnerability Scan with the associated report is required for all mobile (iOS and Android) and web application(s), including a detailed tracker used for remediation tracking and plan for any open exceptions.  Scanning is to occur at least monthly while in development (prior to being provided access to the production API key), changing to at least weekly once the app is live and after significant code releases. Vulnerability remediation, mitigation, and tracking is to occur on a daily basis.  

A formally documented remediation plan must be established for any vulnerabilities considered Critical, High, or Medium risk.  This plan must include details, including steps required towards remediation, timelines, and any mitigating factors. If the most recent Vulnerability Scan shows false positives, confirmation and rationale on why the vulnerability is not a risk, must be detailed. 

The Sponsor Bank reserves the right to request more frequent scans if deemed necessary.

Remediation of Discovered Vulnerabilities

Tied to penetration testing, vulnerability scanning, and general AppSec programs, it is important to have a remediation timeline and schedule, including a formally documented remediation plan for any vulnerabilities rated Critical, High, or Medium risk.  This plan must detail steps required towards remediation, timelines, and any mitigating factors. If any vulnerability is determined to be a false positive, confirmation and rationale to why the vulnerability is not a risk, must be detailed prior to closure.  In addition, if the vulnerability has been risk accepted, a similar justification and rationale should be drafted.  

Penetration Testing

Penetration testing can be analogized with regularly visiting the dentist. Even with daily teeth brushing, it is still highly recommended to visit your dentist twice per year. Penetration testing is designed to mimic the behaviors of bad actors, attempting to take advantage of vulnerabilities, and potentially gain access to a Company’s environment and the sensitive data contained within. Penetration testing is designed to ensure a small cavity is caught early and addressed before it becomes a larger infection and requires a much more involved treatment like a full root canal. 

The key is early prevention and detection. Ensuring that the potential vulnerabilities are addressed before more costly events such as a data breach remediation and recovery is needed. Penetration testing acts as a preventative method to help reduce the impacts and the associated expenses of these related events.  

Penetration Testing must be performed by an independent party. The test must include the scope of: developed application(s) and APIs, including connections with relevant partners, and dependent APIs.  In addition, it is recommended that penetration testing occurs prior to being provided access to the production API key and at least twice per year for quickly expanding FinTechs and annually thereafter for more steadily growing FinTechs.