Secure Software Development Policy

Secure Software Development Policy

  1. 1. PRESENTATION AND OBJECTIVES
  2. 2. DATA STORAGE
    1. 2.1 Procedures and Media for Data Storage
    2. 2.2 Permissions for Accessing Information in Databases
    3. 2.3 Password Management and Distribution for Data Access
  3. 3. PASSWORD MANAGEMENT AND DISTRIBUTION FOR DATA ACCESS
    1. 3.1 Authorization and Authentication of Users
    2. 3.2 Authentication on Web Systems
  4. 4. SECURE COMMUNICATION
  5. 5. ATTACKS ON SYSTEMS AND THEIR DEFENSES
  6. 6. AUDITING, TRACKING AND LOGS
    1. 6.1 Examples of events that can be logged:
    2. 6.2 Examples of information that can be stored, related to each event:
  7. 7. PREVENTION, REACTION AND MITIGATION OF SECURITY BREACHES
    1. 7.1 Backups
    2. 7.2 Tests
    3. 7.3 Incidents
  8. 8. DEVELOPMENT ENVIRONMENT
    1. 8.1 Source Code Access
    2. 8.2 Separation of Environments
  9. 9. DATA PROTECTION
    1. 9.1 Cryptography and Hashing
    2. 9.2 Passwords
  10. 10. SOFTWARE LIFE CYCLE
    1. 10.1 Design
    2. 10.2 Coding
    3. 10.3 Maintenance
    4. 10.4 Personnel

1 - PRESENTATION AND OBJECTIVES

This document is a guide to secure software development within Epimed Solutions. Its objective is to serve as a guide of good practices to be adopted by analysts and software developers, making the process of designing systems more reliable, auditable, stable and protected against threats. The guidelines contained herein are aimed at everyone involved in the software development process within the scope of Epimed Solutions.

Epimed Solutions is concerned with protecting the confidentiality of Personal Data and/or Sensitive Personal Data from Patients or customers that are obtained in any way through its software, in accordance with General Data Protection Regulation (EU) 2016/679 (“GDPR”). For this reason, Epimed Solutions has established the Personal Data Protection and Privacy Policy. All guidelines contained in this document must be interpreted in accordance with the guidelines of the Personal Data Protection and Privacy Policy, which will always prevail in any eventual conflict with the guidelines of this document.

2 - DATA STORAGE

This section presents definitions and guidelines that deal with the storage of confidential or non-Sensitive Personal Data information and its availability. It describes procedures for the secure storage of information in databases. It details the management of access permissions and distribution of passwords to be adopted for the operationalization of these structures.

 

2.1 Procedures and Media for Data Storage

  • You should not use a storage medium that does not have access for reading and writing restricted by password.
  • You should preferably store encrypted data.

2.2  Permissions for Accessing Information in Databases

  • Applications should not have access to any database utilizing a user login with root permissions.
  • Applications should not have access to any database utilizing a user login with permissions to execute commands in Data Definition Language (DDL).
  • Applications should not have access to any database utilizing a user login with permissions beyond those strictly necessary for its operation.

2.3 Password Management and Distribution for Data Access

  • The creation of passwords that do not follow the standards established by Epimed Solutions should not be allowed. Passwords must have at least 6 (six) alphanumeric characters, using special characters (@ # $%).
  • Password storage in source code should not be used.
  • User data and systems using each password provided must be securely stored.
  • The same passwords should not be used for development, testing, homologation and production environments.

3 - PASSWORD MANAGEMENT AND DISTRIBUTION FOR DATA ACCESS

This section presents definitions and guidelines that deal with controlling access to data and assigning the necessary permissions.

 

3.1  Authorization and Authentication of Users

  • Passwords should not be stored in plain text without using a salted secure hash algorithm.
  • Nominal user and password control must be used to determine the user’s identity.
  • Authentication via AD should be used whenever possible to authenticate internal users.
  • Users must be made aware of the permissions and levels of access they have.
  • Active Directory (AD) groups should be used to determine access policies and user roles.

 

3.2 Authentication on Web Systems

  • Since HTTP is a stateless protocol, which uses cookies to maintain user sessions, it is necessary to guarantee both the security of the exchange of credentials and also that of other pages accessed by users of web systems. The HTTPS protocol aims to contribute to ensuring that security is guaranteed. 
  • Thus, HTTPS must be used in all system screens

4 - SECURE COMMUNICATION

This section presents definitions and guidelines that deal with the secure transmission of Sensitive Personal Data between systems, in order to safeguard the integrity, authenticity and other attributes pertinent to the use of communicated data.

  • A communication channel with control of duplication and loss of information/messages must be used. Thus, HTTPS must be used in all system screens.
  • A communication channel that provides integrity control of transmitted data (HTTPS) must be used.
  • A communication channel with authentication control (HTTPS, digital certificates generated by trusted authorities, VPNs) must be used.
  • The data to be transmitted at both ends of the communication must be securely stored.
  • A communication channel that provides confidentiality of the transmitted data (HTTPS and VPNs) must be used.

5 - ATTACKS ON SYSTEMS AND THEIR DEFENSES

This section provides guidelines for enhancing system resilience to attacks against systems and applications. It is recommended that the main known attacks be prevented, in order to prevent malicious attacks from compromising the security of the system, exposing Sensitive Personal Data and performing unauthorized operations, among other possible vulnerabilities.

  • SQL injection attacks (SQL Injection) must be prevented.
  • SQLs should not be created by concatenating textual parameters from non-secure sources, such as parameters filled in by users or even stored in the database.
  • Access permissions to the database for application users must be restricted.
  • It is necessary, whenever possible, to pass parameters in SQL commands (DML or DDL) using prepared statements. Queries that cannot be parameterized should receive special treatment, such as escapes or hexadecimal coding.
  • HTML and Javascript injection attacks must be prevented.
  • Cross-site scripting (XSS) attacks should be prevented.
  • Broken Authentication and Session Management attacks must be prevented.
  • Systems must be subjected to intrusion testing tools.

6 - AUDITING, TRACKING AND LOGS

This section presents guidelines for the maintenance of records/logs for subsequent auditing, tracking and consultation of incidents related to system security. Each system has a different criticality in terms of data access restriction, non-repudiation and history of operations carried out in the database. For this reason, this section does not define what information should be audited, but rather suggests possible items that can be audited, tracked or logged. These items, then, must be evaluated by product managers.

 

6.1 Examples of events that can be logged:

  • Login and logout operations;
  • Access to certain screens or sections of the system;
  • Access to information with some restrictions (For example: confidential documents, personal data);
  • Operations for the inclusion, alteration or deletion of records in the database;
  • Change of access profile (for systems that have access with different profiles);
  • Execution of jobs and automated tasks.

6.2 Examples of information that can be stored, related to each event:

  • Date and time; 
  • User who performed the operation;
  • IP address;
  • User session identifier (when applicable, for example: cookies);
  • Screen (page) of the system in which the operation was performed;
  • Instance identifier (for clustered systems);
  • For insertion, alteration or deletion operations, the type of operation, name of the table that was manipulated, record ID and, if applicable, previous and current values for each field;
  • Parameters informed by the user (Examples: GET or POST parameters), being careful not to store Sensitive Personal Data, such as passwords;
  • System response time;
  • To execute jobs and automated tasks, store the result of the operation; failure, success, cancelation, etc.

7 - PREVENTION, REACTION AND MITIGATION OF SECURITY BREACHES

This section presents guidelines for carrying out procedures that guarantee an adequate reaction to the occurrence of security breaches. The use of backups, tests and event handling is detailed below.

 

7.1 Backups

  • The specification of the need and the assignment of the responsibility for making backups of the database and of the system source codes, as well as the access policies for this backup, must be included in the project plan.
  • A structured procedure for restoring backups must be defined.
  • Personnel in charge of the recovery of backups must be properly designated and trained.
  • Baselines of the system versions must be created, facilitating the agile recovery to a previous version.
  • Simulation of data restoration must be carried out continuously.

 

7.2 Tests

  • Manual security tests must be carried out before each version of the software that changes its structure (login screens, unauthenticated services, new forms with user interaction, etc.).
  • It must be ensured, through automated tests, that the services and confidential data are protected and available only to the users who hold the information.
  • A specific testing policy must be developed, whether automated or not, aiming at guaranteeing non-vulnerability to the main known attacks on systems.
  • Test scenarios should be defined to guarantee the non-functional software requirements, preferably carried out by a test team different from the software development team, in order to avoid bias.
  • Test scenarios should be defined, mainly in terms of security, for cases of updates to the system architecture (application servers, database, browser versions, operating system versions, etc.).

 

7.3  Incidents

  • A planned procedure must be maintained for immediate system unavailability and corrective maintenance.
  • A specific policy to foster the follow-up on security breach incident response must be defined.
  • Lessons learned from past incidents should be used to review the testing policy and increase system security.

8 - DEVELOPMENT ENVIRONMENT

This section provides guidelines for installing, configuring and managing system development environments.

 

8.1 Source Code Access

  • A version control system with access control and recovery in case of failures must be used. (For example: Microsoft Team Foundation Server).

 

8.2 Separation of Environments

  • The Development/Testing/Homologation environments must be separated from the Production environment.
  • Different databases must be used for each environment.
  • Different application/web servers must be used for each environment.
  • Access to the Development/Testing/Homologation environment should only be provided to members of the development team and to those interested in the project (stakeholders).
  • Periodic tests must be carried out to ensure the security of the development/testing/homologation environment.
  • Developers should not be provided with passwords to access the production environment.

9 - DATA PROTECTION

This section provides guidelines for configuring Sensitive Personal Data protection. Parameters for encryption, hashing and password management are detailed below.

 

9.1 Cryptography and Hashing

  • A cryptographic method that follows the Kerckhoffs‘ Principle should be used. The encryption method and its parameters must be public and documented, only the cryptographic key must be kept confidential.
  • An encryption that admits a known method for breaking the cryptographic key (brute force), based on trial and error, should not be used.
  • Electronic codebook (ECB) block encryption mode or less secure modes should not be used. 
  • A key size of less than 128 bits (symmetric encryption) or 1024 bits (asymmetric encryption) should not be used.
  • The hash function should not be used without some type of salt.
  • Algorithms that are considered obsolete for cryptography and cryptographic hashing should not be used. Examples: MD5, SHA1, DES/3DES, RC2, RC4, MD4.
  • A key size of less than 192 bits (symmetric encryption) or 2048 bits (asymmetric encryption) should not be used.
  • Cryptographic keys should not be distributed without the use of a public key infrastructure and, therefore, without the use of asymmetric encryption.
  • A key size of less than 256 bits (symmetric encryption) or 4096 bits (asymmetric encryption) should not be used.

 

9.2 Passwords

  • Password size: Passwords with less than 6 characters should not be used.
  • Variation of symbols: At least upper and lower case letters must be used, together with at least one type of character (digit, symbol).
  • Randomness: Passwords should not be created without the aid of random password generator software, configured to meet the parameters established below:
  • Tests: You should not use a password that has not been validated by password strength checker software.
  • Change frequency: Same passwords should not be used for more than 6 months.
  • Password change and recovery: The use of the same password validation channel should not be allowed. The old password should not be sent to users, under no circumstances.
  • Storage (user): You should not store a password that is not encrypted following the standard level of encryption set out in this document.
  • Number of attempts: Password validation rate should not be allowed to exceed 5 attempts per minute. Passwords must be blocked in case of a maximum of 5 consecutive validation errors and its recovery must rely on a specific process.

10 - SOFTWARE LIFE CYCLE

This section presents guidelines for enhancing software security at different stages of its life cycle; design, coding and maintenance. It also provides guidelines for application with those involved in the different phases.

 

10.1 Design

  • The software design model should include the following:
    • Threat modeling stage;
    • Clear definition of security risks;
    • Severity level that the compromise of Sensitive Personal Data would bring to the system and institution.
  • It should not be omitted, during the system development design and its execution, the definition of responsibilities for system data security and how this responsibility will be verified. 
  • A design schedule that includes security check points of the system developed during its construction must be used.

 

10.2 Coding

  • Protective measures applied in the source code must be documented, including in the application code, in order to indicate precisely the procedure used and its peculiarities.

 

10.3 Maintenance

  • Automatic updates of software or components used in the construction of a system should not be enabled, otherwise security breaches may, inadvertently, come up.
  • Third party software should not be modified, except when strictly necessary. Internal security controls can be invalidated. This change should be made by the original system developer whenever possible.

 

10.4 Personnel

  • Training and qualification of programmers should be provided for the acquisition and review of computer security principles and the development of secure software.