Brand Cloudlines’ (“Cloudlines”) security measures are compliant with relevant International policies adopted by most Software as a Service (“SaaS”) products on the market. Here’s a rundown of all measures that are in place:

1. Web Application Development

   Cloudlines follows recommendations given by the OWASP Top 10 awareness document. We make sure our websites are delivered without any of these ten most common vulnerabilities.

2. Hosting

   Cloudlines’ web server configuration prevents intrusion and limits the impact of potential vulnerabilities. We follow security practices based on secure configuration guides that are widely available and respected by the industry.

   1. General requirements

      1. All servers deployed are owned by the operational group that is responsible for system administration. Our approved server configuration guides are established and maintained by Cloudlines’ Technical team. We monitor configuration compliance and implement an exception policy tailored to the environment. Our team has established a process for changing the configuration guides. The following items must be met:

         • Servers must be registered within Cloudlines’ management system. As a minimum, the following information is required to positively identify the point of contact:
           • Server contact(s) and location, and a backup contact 
— Hardware and Operating System/Version
           • Main functions and applications, if applicable
         • Information in Cloudlines’ management system must be kept
 up-to date.
         • Configuration changes for production servers must follow the appropriate change management procedures

      2. For security, compliance, and maintenance purposes, authorised personnel may monitor and audit equipment, systems, processes, and network.

   2. Configuration Requirements

      1. Services and applications that will not be used must be disabled where practical.
      2. Access to services should be logged and/or protected through access-control methods such as a web application firewall, if possible.
      3. The most recent security patches must be installed on the system as soon as practical, the only exception being when immediate application would interfere with business requirements.
      4. Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication is sufficient.
      5. Always use standard security principles of least required access to perform a function. Do not use root when a non-privileged account will do.
      6. If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec).
      7. Servers should be physically located in an access-controlled environment.

   3. Backups

      Cloudlines conducts:

      • Daily server & database backups
      • Permanent snapshots of the system

   4. Monitoring

      1. All security-related events on critical or sensitive systems must be logged and audit trails saved as follows:

         • All security related logs will be kept online for a minimum of 7 days.
         • Daily backups will be retained for at least 7 days.
         • Weekly full backups of logs will be retained for at least 1 month.
         • Snapshots will be retained for a minimum of 6 month.

      2. Security-related events will be reviewed by the system administrators and will report incidents to the Technical team. Corrective measures will be prescribed as needed. Security-related events include, but are not limited to:

         • Port-scan attacks
         • Evidence of unauthorised access to privileged accounts
         • Anomalous occurrences that are not related to specific applications on the host.

   5. EU Hosted Infrastructor

      The platform infrastructure is hosted on servers based in the European Union. This allows us to meet specific regulatory and compliance requirements of organisations in Europe. Our data centre provider AWS is located in the United Kingdom and Ireland. AWS maintains multiple certifications, including SOC 1, SOC 2, SOC 3 and ISO27001.

   6. Data Centre Security

      Our cloud hosting providers maintain multiple certifications for its data centers, including ISO 27001 compliance, PCI certification, and SOC. For details about their certification and compliance, please visit the Amazon AWS security site.

3. Database policies

   In order to maintain the security of Cloudlines’ web application databases, access by software programs must be granted only after authentication with credentials. The credentials used for this authentication must not reside in the main, executing body of the program’s source code in clear text. Database credentials must not be stored in a location that can be accessed through a web server.

   1. Specific Requirements

      1. Storage of Database Usernames and Passwords

         • Database usernames and passwords may be stored in a file separate from the executing body of the program’s code. This file must not be world readable or writable
         • Database credentials may reside on the database server. In this case, a hash function number identifying the credentials may be stored in the executing body of the program’s code.
         • Database credentials may be stored as part of an authentication server (i.e., an entitlement directory), such as an LDAP server used for user authentication. Database authentication may occur on behalf of a program as part of the user authentication process at the authentication server. In this case, there is no need for programmatic use of database credentials.
         • Database credentials may not reside in the documents tree of a web server.
         • Pass through authentication (i.e., Oracle OPS\$ authentication) must not allow access to the database based solely upon a remote user’s authentication on the remote host.
         • Passwords or passphrases used to access a database must adhere to the Password Policy.

      2. Retrieval of Database User Names and Passwords

         • If stored in a file that is not source code, then database user names and passwords must be read from the file immediately prior to use. Immediately following database authentication, the memory containing the user name and password must be released or cleared.
         • The scope into which you may store database credentials must be physically separated from the other areas of your code, e.g., the credentials must be in a separate source file. The file that contains the credentials must contain no other code but the credentials (i.e., the username and password) and any functions, routines, or methods that will be used to access the credentials.
         • For languages that execute from source code, the credentials’ source file must not reside in the same browseable or executable file directory tree in which the executing body of code resides.

      3. Access to Database Usernames and Passwords

         • Every program or every collection of programs implementing a single business function must have unique database credentials. Sharing of credentials between programs is not allowed.
         • Cloudlines’ Technical team have a process in place to ensure that database passwords are controlled and changed in accordance with the Password Policy. This process must include a method for restricting knowledge of database passwords to a need-to-know basis.

4. Password Policy

   1. Application development

      We ensure that our programs contain the following security precautions:

      • Applications must support authentication of individual users, not groups.
      • Applications must not store passwords in clear text or in any easily reversible form.
      • Applications must not transmit passwords in clear text over the network.
      • Applications must provide for some sort of role management, such that one user can take over the functions of another without having to know the other’s password.

   2. Password construction

      1. All strong passwords should meet or exceed the following guidelines:

         • Contain at least 8 alphanumeric characters
         • Contain both upper and lower case letters
         • Contain at least one number (for example, 0-9)
         • Contain at least one special character (for example, !\$%^&*()_+|~-=`{}[]:”;’<>?,/).

      2. Poor, or weak, passwords have the following characteristics:

         • Contain less than eight characters.
         • Can be found in a dictionary, including foreign language, or exist in a language slang, dialect, or jargon.
         • Contain personal information such as birthdates, addresses, phone numbers, or names of family members, pets, friends, and fantasy characters.
         • Contain work-related information such as building names, system commands, sites, companies, hardware, or software.
         • Contain number and patterns such as aaabbb, qwerty, zyxwvuts, or 123321.
         • Contain common words spelled backward, or preceded or followed by a number (for example, "terces", "secret1" or "1secret" or versions of “Welcome123” “Password123” “Changeme123”)

5. Communcation

   All user data is transported securely, as all traffic is encrypted in transit via SSL. Encrypting data in transit protects it from unauthorised snooping, modification, and man-in-the-middle attacks. We use 256-bit SSL/TLS.1.2 encryption, utilising the RSA algorithm.