To ensure that all software implemented through the SDLC is as free from vulnerabilities as possible, Sm8rtHealth has added a layer of defensive security-related measures to the existing SDLC phases:
| Vulnerability risk assessment | |
| Based on Sm8rtHealth’s understanding of the requirements and the anticipated scope of work for Sm8rtHealth, a ‘vulnerability risk assessment’ will be carried out during the ‘Requirements’ phase of the SDLC. The purpose is to identify what ‘vulnerabilities’ are likely to emerge if the anticipated software changes/additions are implemented. | |
| Context for vulnerability assessment | Sm8rtHealth provides: (i) an on-line process (‘e-application’) for individuals applying to an insurer for a life insurance policy and (ii) ability for staff/agents of insurance companies signing into the platform as users to access various features. During the application process the applicants disclose personal details, some of which are health-related which may be highly sensitive, and this means the Sm8rtHealth platform must be protected from vulnerabilities. |
| Vulnerability checklist | The following checklist is used to identify possible vulnerabilities in relation to Sm8rtHealth: – An unauthorised person gaining access to an applicants’ personal data; – A person manipulating data either during or after the e-application process; – Will the software change introduce a vulnerability causing the Sm8rtHealth online service to be disrupted or made unavailable for any user – When any vulnerability assessment is carried out, Sm8rtHealth will proactively check for the emergence of any publicly-known security patches associated with the technology components that make up Sm8rtHealth. |
| Vulnerability assessment | If ‘yes’ to any of the above, then an assessment will be made to identify the nature and severity of those potential vulnerabilities, by considering: 1) The likelihood of the vulnerability being exploited by an attacker, and 2) The potential damage to any tenant if the vulnerability is exploited |
| Scope of work for security mitigation | This assessment will result in a determination as to what security-related effort should be added to the scope of work during the design, development and testing phases of the SDLC. i.e.: what additional work is required in each of these phases to ensure that the vulnerabilities are mitigated to an acceptable level. |
| Cyber-security design review | |
| Introduction | During the ‘Design’ and ‘Development’ phases of the SDLC, the software design and the code will be reviewed (i.e.: a cyber-security design review). The extent of the review will be driven by the ‘vulnerability risk assessment’ carried out during the previous phase. The purpose of this review is to ensure that potential vulnerabilities are addressed and mitigated as early as possible in the SDLC through careful adherence to the ‘Secure by Design’ principles set out earlier in this document, thus ensuring that changes and additions made to Sm8rtHealth from time to time will keep the platform free from vulnerabilities. The Sm8rtHealth software team will use the following checklist as a basis for the cyber-security design review, to ensure that (i) cyber-security has been fully considered and (ii) secure-design principles have been applied to the software through the SDLC design/ implementation phases: |
| Authentication | Authentication policies, processes and logging in Sm8rtHealth (i.e.: username/ password controls) must always correctly identify the true owner of a user id and password, while ensuring that unauthorized users and attackers will be denied access to the Sm8rtHealth platform, including to all its features and modules. All Sm8rtHealth password credentials must be stored and transmitted securely (e.g.: using one-way hash). Logon transaction should be encrypted with SSL. |
| Authorization and access control | User roles and permissions within the Sm8rtHealth platform must be defined and set up for all users on a “least privilege” basis. If a user role will not be modifying data, then the role should not be granted rights to edit, delete, or add data. Users should not be able to ‘browse’ past their user role rights or gain access to features or data by entering a file path into a URL.A users’ activity should not be cached when handling sensitive/ personal information. User roles and administration roles should be clearly and separately defined with appropriate permissions. |
| Session management | The Sm8rtHealth software design and implementation must effectively protect all user account credentials and session tokens, in particular against interception, prediction, brute-force and fixation session id attacks. Sessions should be encrypted, e.g.: randomly assigned session ID’s, large key spaces, forcing assignment/frequent regeneration of session ID’s . Token key spaces should be as large as possible to combat guessing and other attacks. Session ID’s should be unique to users and issued only after successful authentication. They should be randomly generated using a respected randomization source. Session ID’s should not contain personal information. Session ID’s should always be assigned, never chosen by end user. Session ID’s should be protected throughout their life cycle to prevent hijacking and should have a time-out set for inactive sessions. Active sessions should also have a set time to expire and regenerate a new session token. Session ID’s should be protected with SSL. Session ids should change routinely and always during major transitions, i.e., when moving to and from an SSL and when authenticating. On log out, Session ID’s should be over-written. State mechanisms should be used to separate and maintain an individual’s user activities within a session. State mechanisms should not be used to authenticate users. Cookies should not be transmitted in clear text and cookie contents must not contain or be used to obtain sensitive information. |
| Data and Input validation | Attackers must be prevented from bypassing Sm8rtHealth security mechanisms and adding malicious code to open parameters within the Sm8rtHealth platform. i.e.: the platform must ensure that any data entered through an input field is solely ‘expected’ data, and unexpected data is discarded. The server-side software should always provide for input validation against known criteria (rather than the client), with client-side validation used as a primary validation to reduce round trips to the server, but not as the security defence. Canonicalization should be used. The server should know what to expect in every field, with data input reduced to pure format as expected by the server and database. Integrity of data entry must be confirmed by use of field validation (e.g.: input constraints, type, length, format and range validation, ‘known’ bad inputs always rejected and input sanitization such as stripping null from end of a user-supplied string and HTML or URL encoding to wrap data and treat as literal). |
| Command injection flaws | The Sm8rtHealth design and code must prevent attackers from relaying malicious code (including whole scripts/SQL injection) through Sm8rtHealth to a tenant’s system, or to a third-party system. In particular, SQL injection can take the following forms and must be prevented: Authorization, select statement, insertion and SQL server stored procedures. All Sm8rtHealth parameters should be examined for calls to external sources and the code reviewed for instances where input from an HTTP request could be written into an external call. Code should include filters/checks to verify that only expected data is included, with symbols (if required) converted to HTML and a quote prepended and appended to all user input. Users should be given access only to SQL stored procedures that are required. The design and implementation should avoid shell commands and system calls (where a language library can perform the same functions (without using a system shell interpreter). Where shell commands cannot be avoided, the code should validate the input against a valid input list to ensure that it does not include malicious code. All supplied inputs should be considered as data to reduce (not eliminate) external calls. In the event of data that is not acceptable, there should be a mechanism in place to block and time out the session. |
| Buffer overflows | Buffer overflow attacks must be prevented in Sm8rtHealth. (i.e.: an attack in which a large quantum of data is sent, exceeding the quantity expected within a given field, causing Sm8rtHealth to abandon its normal behaviour and begin executing commands on behalf of the attacker). All Sm8rtHealth code that accepts input from users via an HTTP request should ensure that it can identify large data input, and if identified, the activity should be logged, and the data discarded. All Sm8rtHealth data input fields should have reasonable field lengths and specific data types, with the amount of text allowed in free form fields limited to the maximum amount required. |
| Insecure use of Cryptography | Sm8rtHealth encryption schemas will use a commercial solution with strong cryptography algorithms. Encryption should be applied to all data or files that are deemed sensitive or classified. However, because encryption can cause latency, application of encryption should be applied prudently and not indiscriminately. |
| Error handling | Errors should be planned for at all points in the Sm8rtHealth platform with error messages designed with appropriate information (whether the errors are caused by software, interfaces or users) and a known programmatic response to the error. However, due consideration should be given to the information content of error messages, since unauthorised persons and attackers can learn a significant amount about how Sm8rtHealth’s file structures, permissions and features work from error messages. Therefore, care should be taken regarding which errors should trigger a response to the end user. (In other words, error messages should reflect enough information to the end user to be helpful, but without giving the user information about the code, the file system, or permissions). Errors should be logged to an event log, including time and date, user ID, an error code or description and if possible, the software code line. Error event logs should be encrypted (since they can contain sensitive information such as PII). When an error occurs that causes Sm8rtHealth (or a component of Sm8rtHealth) to fail, it is vital that the Sm8rtHealth will ‘fail closed’, thus blocking unauthorized users from accessing the system, and the action that caused the error should be logged and then blocked. |
| Logging | Logging should be implemented within Sm8rtHealth as far as possible (i) to track unauthorized access, (ii) to help identify if any access attempts were successful, (iii) to provide individual accountability and (iv) to reconstruct events leading to a program failure. Sm8rtHealth servers should be synchronized to a time server to ensure time and date stamps must are accurate. Logs should include date and time, the initiating process, process owner/user and a description. Logs should include: – All administrator activity; – All authentication and authorization events, logging in, logging out and failed logins. (These logs should include date/time, success/failure, resources being authorized, the user requesting the authorization, and if appropriate, an IP address or location of the authentication attempt); – Any modification to data characteristics, including permissions, location or field type; – Any deletion of any data. All log files should be regarded as confidential data and must therefore be protected against deletion or modification. The files should be subject to an archiving procedure and the archived files may be encrypted. |
| Security testing | |
| External tester Phew | Security testing will be carried out from time to time as needed, based on the assessment made in the Vulnerability Risk Assessment. Security testing will likely be required if the scope of work involves software changes or additions are extensive or are otherwise likely to create vulnerabilities in Sm8rtHealth. Since it preferable to carry out security testing using specialised testing tools and with personnel that have the appropriate expertise, Sm8rtHealth will engage Phew, (an independent cyber security specialist) to carry out such testing, as and when required, with test scope defined according to the nature and extent of the software changes and the anticipated risks. |
