[draft awaiting comments - Oct 2023]
Purpose
This Standard of Practice establishes the security requirements for web applications servers running any application that PSI supports under its Platform 2.0 technology stack. The goal of this Standard of Practice is to protect web applications servers from unauthorised access, use, disclosure, disruption, modification, or destruction.
Scope
These Standard of Practice apply to all web applications servers operated by PSI or maintained by PSI Digital Health Management department. It is also to be followed for installations done in infractures for other organisations as part of PSI’s contracted services. The Standard of Practice covers the following areas:
Architecture: - private/ public.
Authentication: how users and clients are verified and granted access to the web application server.
Authorization: how permissions and roles are assigned and enforced for different users and clients.
Encryption: how data is encrypted in transit and at rest to prevent interception or tampering.
Backup: how data is backed up and restored in case of loss or corruption.
Disaster recovery: how the web application server is prepared and recovered from natural or man-made disasters.
Logging: how activities and events are recorded and monitored on the web application server.
Auditing: how security incidents and violations are detected and reported on the web application server.
This Standard of Practice applies to both, on-premise installations as well as cloud-based systems.
1. Architecture
what’s exposed/ not xposed.. Private IPs. Firewall. Denial attacks
bastion host
2 different internet connections
cjritical services like authentication should probably be on a redundant setup (cluster)
2. Authentication
Authentication protects the web application server from unauthorised access. The mechanisms that are used to authorise users to access the servers vs the web application are, and considered individually.
Access to the server
Limited to few IT system administrators requiring server level access to provide maintenance to the underlying OS and services like proxy, backup, logging and similar. The access at server level should be authorized by _____________.
Access is to be controlled by the use of SSH (Secure Socket Shell), a protocol that allows remote login and command-line execution over public internet. Server administrators will need to provide a copy of their public key, which will be installed on the server.
Access to the web application
For all users, including web application administrators, supervisors and all other users.
If IAM is used - please refer to Keycloak Realm Configuration Guidelines
If user accounts and passwords are to be set at the web application level (e.g. IAM is not being used)
All users must use a strong password to authenticate to the web application server composed of at least 8 characters, 1 uppercase, 1 lowercase, 1 symbol, 1 number.
If PII is stored in the system, the application must provide a MFA mechanism. Once MFA is enable, password do not expired
If 2FA is not supported by the application (and IAM is not being used), users must change their password every 90 days.
Users should be locked out of their account after 5 failed login attempts
App to App authentication (app integrations)
preferably use tokens specific for the integration
if you need to use username/password, ensure that it is transmitted over a secure channel
xxxx
Under no circumstances the token, usernames or password must be on the main code - instead they should be on private .env file
Sharing of password with external vendors or users.
They should be shared as a one-time secret
never be shared via email or chat application
Onboarding and Offboarding of users
write about this
2. Authorization
An authorization Standard of Practice for a web application server is a set of rules that determine which users and groups are allowed to access which resources or processes on the web application. Authorization policies can be based on a variety of factors, such as the user's role and user group membership. You will need to consider the security needs of your application and the types of users who will be accessing it. You should also make sure that your authorization Standard of Practice is aligned with your business policies and procedures.
In general, you should use the principle of least privilege: only grant users the permissions they need to perform their job duties.
You should review your authorization policies regularly to make sure they are still up-to-date and align with your security needs. This is particularly important during the application updates, which may introduce new authorizations/ user roles.
Responsibilities:
Review of the roles should be performed by
3. Encryption
Encryption is used to ensure that all data transmitted to and from the web application server to the client’s application (normally a web browser or a mobile app) is protected from unauthorised access if the transmission is eavesdropped. Additionally, data at rest is encrypted, so if access to the storage is gained by an unauthorised party, the data is illegible.All application servers are expected to:
use HTTPS to encrypt all communication between the server and the client application.
web application data stored in the server or mobile applications (data at rest) should be encrypted. This is dependant on the application design.
data transmitted to and from the web application server (data in transit) must be encrypted at all times.
Implementation
To implement HTTPS, the web application server must be configured with a valid SSL/TLS certificate.
To encrypt sensitive data at rest, the web application server must use a strong encryption algorithm, such as AES-256.
To encrypt sensitive data in transit, the web application server must use a secure transport protocol, such as TLS 1.2 or higher.
Key Management
All encryption keys must be stored securely.
Encryption keys must be rotated on a regular basis.
Access to encryption keys must be restricted to authorised personnel.
4. Backup Standard of Practice
Web application servers must be backed up on a daily basis. Backups must be stored on at least two different media or services, one of which must be stored off-site. Backups should be encrypted to protect them from unauthorised access.
The following data must be backed up:
Web application files
Database files
Configuration files
Application logs
Backup storage
on premise, on cloud
Backup retention
Backups must be retained for at least 365 days, daily for the last 30 days, and then monthly for the period between day 31 to day 365. For the monthly backups, the last day of the last 12 months should be retained.
Backup Testing
Backups must be tested on a monthly basis to ensure that they are working properly. Testing should involve restoring a backup to a test environment and verifying that the data is complete and accessible.
Backup Restoration
In the event of a disaster or data loss, the IT department will restore the most recent backup to the affected web application server. When possible, this restore procedures should be partially or completely automated as scripts. The IT department will work with the appropriate stakeholders to minimise downtime and disruption to business operations.
Responsibilities:
Testing of the backups should be performed by the designated party.
5. Disaster recovery
Disaster recovery is the process of restoring systems and data to a working state after a disaster. A disaster can be a natural event, such as a flood or earthquake, or a man-made event, such as a cyberattack.
For on-premise installations/ natural disaster
An active, secondary location that is at least 300 kms/ 200 miles away from the primary site must be ready to go live in case of disaster. The computing capacity must be equivalent to at least 80% of the primary site. Alternatively, a cloud setup can be used as a disaster recovery location (see below).
For cloud base installations/ natural disaster
A secondary zone that is 300 kms/ 200 miles aways must be contracted (or easy to instantiate) with the current provider or with an alternative cloud provider. The computing capacity must be equivalent to the same, or at least 80% of the primary site. In both cases the cloud providing account must allow for the contracting to be done online, which involves pre-authorize financial arrangements.
For man-made/ cyberattack
The origin of the attack must be determined with certainty and the necessary patches must be applied before restoration of the service is attempted. Normally the review of the logs before the attack will provide invaluable information to diagnose the source and cause of the attack (see 6. Logging)
6. Logging
The purpose of logging is to collect and store information about system events and activities in order to detect and respond to security incidents, as well as to facilitate the investigation and troubleshooting of system problems (performance or bugs).
All systems must generate logs that capture a sufficient level of detail to support the purposes listed above.
Logs must be collected and stored in a secure location. They should be on a tamper-proof format.
Logs must be retained for a period of time that is appropriate for the application in question. This is normally between 30 and 90 days.
Access to logs must be restricted to authorised personnel, normally only system administrators.
Ideally they should be transmitted to the centralised log management system using a secure protocol.
Logs must be part of the backed strategy (see above, 4. Backups).
Logs must be regularly reviewed and analysed to identify potential security incidents and system problems.
Security incidents and system problems identified in the logs must be investigated and resolved promptly.
7. Auditing
Web application auditing is the process of examining a web application to identify security vulnerabilities and compliance risks.
break this into 2 levels
Server
Application
All web applications must be audited on a regular basis. The frequency of audits will depend on the criticality of the web application and the risks associated with it.
Web application audits must be performed using a variety of tools and techniques, including automated tools, manual code review, and penetration testing.
Web application audits must cover the following areas:
Security vulnerabilities: The audit should identify any security vulnerabilities in the web application, such as SQL injection, cross-site scripting, and broken authentication.
Compliance risks: The audit should identify any compliance risks associated with the web application, such as violations of PCI DSS or HIPAA requirements.
The findings of the web application audit must be documented and classified according to their severity.
Remediation plans must be developed and implemented to address any security vulnerabilities or compliance risks identified in the web application audit.