Policies and Procedures: Department Specific Policies

Open Source Policy

The Open Source Policy is in place to establish guidelines in terms of when and under what circumstances the utilization of open source software is acceptable within the organization.

The use of open source software is permitted at Ripple Treasury. Prior to using open source software within Ripple Treasury applications, proper approval must be attained.

Licensing

An evaluation of the licensing used by the open source software will be undertaken to identify any requirements imposed on Ripple Treasury as a condition of its use. A list of open source software will be maintained by the technology team and reviewed on an annual basis.

Approval Process

The use of any open source software within the Ripple Treasury application must be approved by the CTO or technology management.

Cookies Policy

The Ripple Treasury policy explains what cookies are and how Ripple Treasury uses cookies.

Cookies are small pieces of data sent by a web browser to a user’s device while the user is browsing online. Cookies can be used to remember arbitrary pieces of information about a user, while they can also be used by web servers to know whether a user is logged in or which account they are logged in with. Ripple Treasury uses cookies both in the Treasury Management System and from a Marketing standpoint.

Use of Cookies in Treasury Management System

Within the Ripple Treasury application, cookies are used for various purposes.

Load balancing web requests
Session authentication
Providing an improved user experience

Use of Cookies in Marketing

Ripple Treasury will use cookies according to the Ripple Treasury Privacy Policy.

No personally identifiable information, or information regarded to be of a secure nature, will be stored in Ripple Treasury cookies.

Connection Security

This policy describes the security requirements around transmissions between the application and client back offices. They are designed to ensure the confidentiality, integrity and non-repudiation of sensitive information entering and leaving the application.

All data must be transmitted using SFTP or FTPS
FTP authentication must use one of the following:
- ID and Key
- ID, Key and Password
All data must use PGP signing and encryption
Key exchange must use DHE SHA2 group or higher
Encryption must use AES 128 or higher with CBC, CTR or GCM modes
Message Authentication Code (MAC) must use SHA2 group or higher
Keys and certificates must have a maximum expiration of 2 years
Unique PGP keys are used for each client

These requirements do NOT apply to non-sensitive information e.g. transmissions of public information, country code lists, etc. They equally do not apply to transmissions to and from banks, who will apply their own standards.

Exceptions to the above standards to support client capabilities must be approved by the security team.

Cryptography Standard

All processing, storage, and transmission of sensitive data within, to, or by Ripple Treasury must meet the following standards unless an exception is approved by the security team.

Asymmetric cipher algorithm	RSA 2048 bits or longer
Symmetric cipher algorithm	AES128 or higher GCM, CBC, CTR, CNT or CCM modes AES256 is recommended. GCM mode is recommended.
Hash function	SHA3 SHA2
Data authentication algorithm	HMAC-SHA256
Digital Signature	RSA (2048 bits or higher) of a SHA256 digest (or higher)
PKI certificate	X509v3, meeting requirements above
Key exchange algorithm	ECDH-256 or DHE (2048 bits)
TLS	TLS 1.3 TLS 1.2
Password hash	ARGON2 PBKDF2 BCRYPT SHA256 SHA512 SHA functions are not recommended for password hashing without tuning.

Firewall Policy

The purpose of this policy is to ensure that rules used on firewall systems within Ripple Treasury networks are accurately documented and maintained. In addition, this policy is required to adhere to Payment Card Industry (PCI) standards.

This policy applies to hardware firewalls installed within the Ripple Treasury office network, along with Azure and Rackspace networks.

All installations, implementations of and modifications to a Network Firewall and its Configuration and Rule set are the responsibility of DevOps. All Network Firewalls must conform to the standards defined by the DevOps Management team. All firewall implementations must adopt the position of “least privilege”.

Firewall rules will be verified for accuracy on a quarterly basis by DevOps & IT Management and discrepancies resolved. Results of firewall reviews will be maintained by the DevOps & IT teams for an indefinite period.

The test results will be reviewed and approved by the DevOps and/or IT management and forwarded to the Security & Compliance team for review.

Key and Certificate Management Policy

The scope of this policy includes all personnel who are responsible for the request, generation, storage, use or management or private keys and certificates used on Ripple Treasury servers or by Ripple Treasury applications.

Certificates

All Ripple Treasury certificates should be generated by a recognized certificate authority with a minimum key length of 256 bits. The private key files will be stored in a secured area of the Ripple Treasury file server, with access permitted to domain admins and specific employees as determined by senior management. The files will be stored in PKCS12 format (PFX) and assigned a password stored in a secure area of the Ripple Treasury password tool.

SSH Keys

All Ripple Treasury SSH keys are generated as 2048-bit RSA. The private key files will be stored in a secured area of the Ripple Treasury file server, with access permitted to domain admins and specific employees as determined by senior management. The files are stored in .ppk format and assigned a password stored in a secure area of the Ripple Treasury Unified tool.

PGP Keys

All Ripple Treasury-owned PGP keys are generated as 2048-bit RSA. The private key files will be stored in a secured area of the Ripple Treasury file server, with access permitted to domain admins and specific employees as determined by senior management. The files will be stored in .gpg keyrings and assigned a password stored in a secure area of the Ripple Treasury Unified tool.

Cryptographic Keys

In compliance with PCI, all cardholder data should be encrypted using cryptographic keys. The generation of strong cryptographic keys is done by DevOps. Cryptographic keys – including associated SSL, PGP, and SSH assets - are stored in designated secure repositories and associated passkey/passphrases stored in designated secure credential management software, both accessible only to designated DevOps. Key distribution is initiated by reviewed and approved requests through a ticketing software, and the distribution is handled by DevOps. Management of expiring and/or renewing key assets is also handled by DevOps using the same request ticketing and approval process as employed for key distribution. Certificates and keys should expire within 2 years. All DevOps members are required to formally acknowledge their responsibilities as key custodians on an annual basis.

Unauthorized Access

Private keys and certificates are used to uniquely identify Ripple Treasury, and any unauthorized access to this information may result in a third party being able to impersonate the company and its processes. Any suspected breach of confidentiality should be immediately reported to the Security & Compliance team to determine whether the breach warrants revocation and replacement of that key or certificate.

Logical Access Policy

This policy will establish guidance regarding logical access to the Ripple Treasury Network, Production Network, and SWIFT Secure Zone.

Office Network Policy

All logical access to machines on the office network will be secured by domain authentication. Every legitimate user will be assigned credentials based on the groups that their position requires, as requested by management via ticket. Group permissions will be assigned to servers as determined by the IT team. As a rule, no access is permitted to servers outside of the Ripple Treasury technical teams (IT, DevOps). Permissions will be reviewed on a quarterly basis.

Ripple Treasury Access to Client Environments

Clients are responsible for providing access to Ripple Treasury personnel on a business need basis as well as giving access to their own personnel on a business need basis. Ripple Treasury is responsible for determining which Ripple Treasury personnel need access to client data to fulfill their responsibilities. User access will be reviewed and approved by management on a quarterly basis.

Production Network Policy

All access to the Production network will be via VPN tunnel from the Ripple Treasury office network. Additional validation of credentials will be required before any RDP traffic can be sent over the tunnel, and the tunnel itself will be limited to ports and protocols necessary for the support and monitoring of the Production servers and applications. Access is limited to members of the DevOps & IT teams.

All logical access to machines on the Production networks will be secured by domain authentication. This domain will not be related to the Ripple Treasury office domain. Users will be assigned credentials based on the groups that their position requires, as requested by DevOps management via ticket. Group permissions will be assigned to servers as determined by DevOps management.

All access to servers will be via bastion servers which will enforce multi-factor authentication.

Network Review Policy

Network diagrams will be updated and reviewed by a senior manager with knowledge of the network on a quarterly basis, including a Firewall Review. A copy of the network diagrams along with comments and a sign-off should be forwarded to the Compliance team on a quarterly basis.

The diagrams should be reviewed specifically in the following areas:

Any changes from the previous review.
Any security implications or recommendations associated with the network configuration.
Any opportunities to upgrade based on expected EOS/EOL (end of sales/end of life) dates for hardware.

Security & Patch Management

Ripple Treasury has established a formal policy and detailed procedures concerning security patch management. It is evaluated on an annual basis to ensure its adequacy and relevancy regarding Ripple Treasury’s needs and goals.

Patch management of all servers will be overseen by DevOps and IT management working in conjunction with Data Center Support.

Note that this policy does NOT apply to scheduled updates of the Ripple Treasury application (which are scheduled by the Ripple Treasury product team) except for third-party tools and libraries as detailed below.

Operating Systems

Ripple Treasury will only use operating systems supported by the vendor. Only operating systems under mainstream support should be used. All operating systems should be patched on a monthly basis with fixes released by the vendor. At the discretion of DevOps and IT management, specific patches may be excluded if they are deemed a significant risk, or if problems have been identified. Certain critical vulnerabilities may require a faster response and should be applied as soon as that fix has been verified to not cause additional issues. Ripple Treasury will work expeditiously to address critical vulnerabilities as quickly as possible. Non-critical items will be deployed after the updates within the patch have been verified by the Ripple Treasury IT or DevOps team.

Software / Applications

Software installed on Ripple Treasury servers will, from time to time, be subject to updates and patches released by the appropriate vendor. These updates should be reviewed on a regular basis (by the DevOps team and IT) in order to identify the criticality and risk (of applying or delaying the patch). Ripple Treasury will work expeditiously to address critical vulnerabilities as quickly as possible. Non-critical items will be deployed after the updates within the patch have been verified by the Ripple Treasury DevOps team and IT.

Third Party Tools

The Ripple Treasury application may, at the discretion of the development team, make use of third-party tools and libraries. These products should be reviewed at least annually in order to identify whether updates are necessary. The use of third-party tools and libraries must be approved by the CTO or technology management.

Vulnerability Testing and Scanning

Vulnerability scans will be run against all client facing servers (internal and external scans) and Ripple Treasury office servers (external only) on a weekly basis. Results should be analyzed at least once per month and recommendations made to remediate any identified vulnerabilities.

Timing

Ripple Treasury will rely on external assessments of vulnerabilities or patch criticality but may adjust the assessment based on mitigating factors.

Criticality	Description	Expected Time to Address
Critical	Items with high impact and high exposure	Within 7 days (subject to vendor patch availability)
High	Items with high impact or high exposure	Within 31 days, typically next patch window
Medium	Items with low probability of exploit	Within 90 days
Low	Items that are generally mitigated by other factors	Within 180 days as resources are available

Virtual Private Network

Approved Ripple Treasury employees and authorized third parties (customers, vendors, etc.) may utilize the benefits of VPN, which are a "user managed" service.

All fixed site to site VPN tunnels must be IKE v2 format at minimum.
All fixed site VPN tunnels should have a minimum key length of 17 characters.
All fixed site VPN tunnels should exchange pre-shared keys verbally (in person or via telephone).
All VPN tunnels must be documented by the IT team with regard to purpose, configuration settings, and ports/protocols allowed.
VPN tunnels must use AES256 encryption, SHA256 authentication, and Diffie-Hellman Group 21 key exchange.
Key lifetime should not exceed 43200 seconds (12 hours).
Replay detection and Perfect Forward Secrecy should be enabled if available.
Tunnels should allow only ports and protocols that are necessary.
Authorized VPN users must be configured with the appropriate permissions at the time of VPN setup.
VPN use is to be controlled using domain credentials.
VPN gateways will be set up and managed by Ripple Treasury IT.
Users of computers that are not Ripple Treasury owned equipment must configure the equipment to comply with Ripple Treasury's Acceptable Use Policy.
Only Ripple Treasury approved VPN clients may be used.
By using VPN technology with personal equipment, users must understand that their machines are a de facto extension of Ripple Treasury’s network, and as such are subject to the same rules and regulations that apply to Ripple Treasury owned equipment, i.e., their machines must be configured to comply with Ripple Treasury security policies.
Any Ripple Treasury client, affiliate or third party requesting a VPN connection with Ripple Treasury must be approved by senior technology management. Data exchanged via VPN must be in an encrypted format.

Vendor Vetting & Supplier Review

As a part of the vetting process in establishing a new relationship with a potential vendor or supplier, at Ripple Treasury’s discretion, the potential partner/vendor’s security certifications may be reviewed (e.g. SOC, PCI, etc.) to confirm viability and acceptance.

Vendors and suppliers that partner with Ripple Treasury should adhere to all applicable Ripple Treasury policies and procedures regarding security, availability, confidentiality and privacy.

Risk Categories

Vendors are categorized into two main categories, either sensitive or other. Most vendors with whom Ripple Treasury works with will be classified into the other category. Vendors may be categorized as sensitive based upon access to facilities, data, insurance or fall subject to compliance.

For any vendor classed as sensitive, Ripple Treasury may annually review the partner/vendor’s security certifications (e.g. SOC, PCI, ISO, etc.). Data Center provider SOC reports must be reviewed and signed off on by the Security & Compliance team on an annual basis. Ripple Treasury will conduct an analysis of responsibilities for both the vendor and Ripple Treasury in terms of security and compliance, PCI, GDPR and/or SWIFT.

Vendor Review

Vendors should be re-evaluated and reassessed on an annual basis. The Security & Compliance team will partner with the owner of the applicable vendor relationship(s) to review the vendor classification, vendor relationship and any necessary security documentation (such as SOC, PCI, or ISO certifications).