Non-Functional Requirements - Data

Protection
This document contains NFRs categorized under Data Protection. Each NFR is numbered
sequentially.

NFR No. Requirement

NFR-DAT-001 Appropriate backup mechanisms to ensure compliance with identified
requirements for recovery of data created at the hosting/solution
provider assuming loss of both PROD/COB online environments must
be implemented
NFR-DAT-002 RBAC – Role Based Access Control. RABC must be featured in the
application to control the incoming identity using logic of App Roles,
Group Roles or any custom data roles
NFR-DAT-003 Data encryption in transit: For data moving between on-premises
infrastructure and Cloud or transferring from one location to another
location, appropriate safeguards such as HTTPS or VPN features needs
to be enbled. When sending encrypted data between two locations
over the public internet, use VPN Gateways. This must isolate the data
during processing (editing, viewing, analysing, transferring etc.) by
placing it in a protected, encrypted enclave
NFR-DAT-004 Data encryption in Storage: Use any encryption feature to make sure
the contents of files cannot be accessed by unauthorized users. Ensure
Controlling access to and hardening the security of databases is
implemented. Developers must classify the data in case tenant/Shared
Databases
NFR-DAT-005 The application must data loss or data corruption preventions:
Establish the secure features, including secure coding practices and
also secure deploy/releasing of an application features to Prevent
Data Loss or corruption. For example, Whitelisting of Dynamically
Executed Code, HTTPS/SSL 2-way end to end encryption etc.
NFR-DAT-006 Password encryption: Since password is the key authentication factor
to access any system or application, password must be stored in
encryption mode
NFR-DAT-007 The application must password Based Encryption (PBE): Passkey
used for Password Based Encryption (PBE) must have the following
length/complexity: Information classified as Confidential, or higher
relating to a single customer sent to that customer (including
eStatements): minimum 8 alphanumeric characters including at least
one upper and one lower case letter. In cases where character case is
not supported, minimum length of 9 alphanumeric characters. All
other instances of Information classified as Confidential, or higher
including sending the information relating to the multiple
users/customer/individuals, complexity of the password will be
defined.
NFR-DAT-008 The application must prevent any encryption keys or passkey for
 PBEs from being included in the source code or configuration files.
NFR-DAT-009 Key Backup and Archiving. If the application is subject to supervisory
or data retention requirements, there must be a process in place for
backup and archiving of the data (including passkeys, basic info of the
user/customer) used to encrypt the data which is being retained.
Recovery must be enforced, such that all encrypted messages or data
can be decrypted and recorded in the log for audit evidences
NFR-DAT-010 The application must prevent storing of confidential and above data
that persistently stored on a system in the DMZ. Persistently stored
means storage beyond the session lifetime.
NFR-DAT-011 Database Password Protection in Storage: Database connection
strings contain authentication data and, therefore, must be encrypted
in storage. Encrypted connection strings and encryption keys must be
protected. The function of decrypting connection strings should not be
a standalone utility to prevent the connection strings from being
decrypted and displayed in the clear. Instead, it must be embedded
into or fully integrated within the application
NFR-DAT-012 Database Authorization: If the application uses a common database
Functional ID, the application must conduct authorization checks on
user actions for more granular user access control to the database
NFR-DAT-013 The application must sensitive Data Protection at Rest. Does the
application encrypt sensitive data such as PII, authentication data and
business sensitive information during storage?
NFR-DAT-014 Token based Authentication Mechanism If the application makes use
of SAML, Oauth, or JWT token for on-going Authentication; it must
prevent token's insecure storage. Any application that changes the
authorization state at the backend such as from pre-authentication to
post logged-in session; must have a different session ID associated
with each state.
NFR-DAT-015 Push Notification Controls: The application must introduce/modify
push notification like Apple, Firebase or some other third party cloud
based event mechanism. Acceptable Criteria: - TLS appropriate
version in place per Company standards. Content signing used to
validate the origination of the push notification. Authentication and
authorization mechanism in place between the client app, push
notification service and application server. The credentials are
managed independently by a dedicated group, not development. Data
classified confidential PII or higher must have payload encryption in
addition to the transmission level encryption.
NFR-DAT-016 The application must broken Access Control; 94% of applications
were tested for some form of broken access control. The 34 Common
Weakness Enumerations (CWEs) mapped to Broken Access Control
had more occurrences in applications than any other category.