Best practices and requirements for software
These best practices summarize some of the most important technical principles for software providers based on the controls and implementation guidance of the IBM Cloud Framework for Financial Services. These best practices are not a replacement for the information provided in the Control Implementation Overview templates, which are still the definitive guides to the controls and required evidence for application providers.
If you're a SaaS provider, see Best practices for software as a service.
1. Enable operators to properly configure your application to meet the controls
Requirement: Enable and organization operating your software to meet the controls of the IBM Cloud Framework for Financial Services.
Purpose & value: An operator is responsible for the IBM Cloud Framework for Financial Services controls for every piece of software they run in their management or workload VPCs, whether running in a virtual server instance or in Red Hat OpenShift on IBM Cloud containers. So, the overarching principle for a software provider is to enable their software to be deployed, configured, and managed in a way that could be Financial Services Validated.
Implementation guidance: Provide clear written instructions for an operator to follow in order to deploy, configure, and manage your software on the IBM Cloud for Financial Services.
2. Provide account and access management to enable a zero-trust environment
Requirement: Enable operators to implement a system of zero-trust where account, identity, and access management is based on the principles of separation of duties and least privilege.
Purpose & value: The design of the IBM Cloud for Financial Services is intended to enable a zero-trust model for deployments of the reference architectures. The scope of any one individual operator or administrator is strictly limited to those actions necessary and appropriate to perform their assigned roles. Overlap of duties is minimized or eliminated to prevent the need for privilege escalation that may result in undesired flows of information into or out of the operator's deployment. It is guided by two major principles:
- Separation of duties - No user should be given enough privileges to misuse the system on their own. For example, no one user should have the authority/ability to develop, compile, and/or move object code from non-production environments into production environments.
- Least privilege - Restrict the access privileges of authorized personnel (e.g., program execution privileges, file modification privileges) to the minimum necessary to perform their jobs. Access must be granted based only on a need to know. Access that has not been explicitly permitted is denied by default. Role-based access controls (RBAC) are used to allocate logical access to a specific job function or area of responsibility, rather than to an individual. Administrative access is only granted to individuals whose job roles have been approved for administration responsibilities.
Implementation guidance: As a software provider, you must provide facilities to accomplish these goals as appropriate. As a simple example, if your software provides a database, you should provide the ability to create database users with different roles (e.g., viewer, editor, administrator).
Ideally, you should support integration with an external (to the application) identity and access management provider for validating users and their associated access group membership.
Most Relevant Control Groups or Controls:
| Family | Control |
|---|---|
| Access Control (AC) | AC-2 Account Management AC-3 Access Enforcement AC-5 Separation of Duties AC-6 Least Privilege AC-14 Permitted Actions without Identification or Authentication |
3. Enable ability to capture audit events
Requirement: Provide technical capability within the application to capture audit events.
Purpose & value: It is important that the operator has access to audit logs to be able to investigate abnormal activity as well to comply with regulatory audit requirements. With a proper audit logging system, an operator can be automatically alerted to potential problems. This allows the operator to be proactive and check into potential security issues shortly after they've occurred.
Implementation guidance: You must log critical events related to administering your software that can be accessed by the operator. Many examples of auditable events are listed in the AU-2 control from the IBM Cloud Framework for Financial Services, including:
- Access, downloading, revisions to confidential information
- Access to or update to any financial transaction data
- Any changes to consumer accounts
- Login/logoff event successes and failures
- etc.
The audit events that are generated should comply with the Cloud Auditing Data Federation (CADF) standard using the system time for timestamps.
The software should buffer audit logs locally in the event that the central audit facility is unavailable, and if the capacity for buffering the audit records is exceeded and audit events are discarded, the developer should send an audit event indicating the loss of audit records once the central audit facility is accessible.
You must provide the technical capability to ensure only permitted users have access to audit records.
Most Relevant Control Groups or Controls:
| Family | Control |
|---|---|
| Audit and Accountability (AU) | AU-2 Audit Events AU-3 Content of Audit Records AU-5 Response to Audit Processing Failures AU-8 Time Stamps AU-9 Protection of Audit Information AU-10 Non-repudiation AU-11 Audit Record Retention AU-12 Audit Generation |
4. Follow secure development processes and ensure software integrity
Requirement: Ensure that security engineering principles are applied in the design, development, implementation, and modification of your software. Maintain software integrity by using signed images, applying security patches, doing vulnerability scans, etc.
Purpose & value: It is critical to follow security engineering principles and manage changes to your software using a system development life cycle (SDLC) that incorporates information security considerations. Doing so minimizes the risk of introducing code or configuration changes that undermine your software's security.
Lack of software integrity leaves your operator vulnerable to security problems. So, it is critical for you to be able to assert the origin of all software components in your application and to keep software components up to date.
Most Relevant Control Groups or Controls:
| Family | Control |
|---|---|
| System and Services Acquisition (SA) | SA-8 Security Engineering Principles SA-11 Developer Security Testing and Evaluation SA-12 Supply Chain Protection SA-14 Criticality Analysis SA-15 Development Process, Standards, and Tools |
5. Ensure consumer data can be encrypted at rest and in transit
Requirement: Ensure operator can configure your software so that consumer data can be encrypted properly at rest and in transit.
Purpose & value: Consumers do not want their data to be accessible to bad actors. Protecting consumer data against unauthorized disclosure, modification, or destruction throughout the data lifecycle is of paramount importance in the IBM Cloud for Financial Services. Encryption is a major component of this protection, and operators must be able to configure your software to meet the data encryption requirements of the IBM Cloud Framework for Financial Services.
Implementation guidance:
- You must implement and document application capabilities and configuration requirements in accordance with the cryptographic specifications provided in the Supplemental Guidance for Cryptography section of the CIO template.
- You must implement and document application capabilities and configuration requirements related to using cryptographic keys provided via Hyper Protect Crypto Services to protect data in transit and at rest.
Most Relevant Control Groups or Controls:
6. Enable software to be run in a highly available manner
Requirement: Design your software so that operators can meet the IBM Cloud Framework for Financial Services requirements for high availability.
Purpose & value: Operators SaaS offerings are required to be highly available so that consumers do not face downtime of critical applications. Typically, high availability is addressed mostly by the operator, but you will need to provide documentation if your software or software deployment pattern includes enhanced availability capabilities (such as replication, active-active, active-passive, etc.).
Most Relevant Control Groups or Controls:
| Family | Control |
|---|---|
| System and Communications Protection (SC) | SC-6 Resource Availability |
Next steps
If you haven't already, you should learn about the three reference architectures for the IBM Cloud for Financial Services where your software would be deployed: