LEGAL AND SECURITY

UCX Information Security Policy & HIPAA Compliance

Last updated: August, 2019

Introduction

Cloud computing, as an active evolving paradigm, including its use cases, technologies, challenges and benefits is being refined in day to day business by both public and private sectors. The definitions used in this document will evolve over time, but it will serve as a basis of understanding of the cloud computing and multi-cloud architecture used at UCX to provide top-notch services around a world of multiple cloud service providers and its customers. According to NIST (National Institute of Standards and Technology) cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources such as networks, servers, storage, applications and services that can be rapidly provisioned and released with minimal management effort or service-provider interaction for virtualized compute resources. This Information Security Policy document touches all aspects of security, company confidential information and access to sensitive information. UCX is a cloud company and before moving on to the heart of the information security policy there is a need to iterate through cloud computing, its definition and security, first couple of paragraphs establish the definitions for which the policies further protect.

Cloud Computing Definition

Cloud computing is composed in five distinct essential characteristics, on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service based on NIST (National Institute of Standards and Technology).

NIST Essential Characteristics

On-demand self-service – A consumer can provision computing resources such as virtual server, network storage and other services provided by a Cloud Service Provider as needed without requiring a human interaction.

Broad network access – Compute resources are available over the network and accessed through standard mechanisms that allow multiple client access such as personal computer, mobile phone or tablet computer.

Resource pooling – Cloud Service Provider’s compute resources are pooled to serve multiple consumers at a time using a multi-tenant model that consists of different physical and virtual software and hardware resources that are dynamically assigned and reassigned to support consumers’ needs. There is a level of location independence that the customer only has a high-level access to specify location (such as country, state or data center). Software and hardware resources include storage, processing power, memory, network bandwidth, virtual machines and operating system.

Rapid elasticity – Compute resources and capabilities can be rapidly, elastically and in some cases automatically provisioned to enable customers to quickly scale in or out. Provisioning capabilities often appear to be unlimited and that can be purchased in any quantity at any time.

Measured service – Cloud systems provide automatic resource control and optimization by leveraging metering capabilities in a level of abstraction depending on service types such as storage, processing, bandwidth or disk utilization). Compute resources can be monitored, controlled and reported by providing transparency for both the provider and consumer of the utilized service. At UCX there is a cloud-agnostic approach to measured (or metered) service that UCX offers to its customers using a licensed WAC algorithm.

Service Models

Software as a Service (SaaS)

According to ITU-T (International Telecommunications Union – Telecommunication Standardization Sector of ITU) recommendation Y.3500, SaaS is defined as a service category where customers have an application available from the cloud service provider whereas NIST has a more complete definition in SP 500-291 where SaaS is defined as an application provided to a user which is available from different clients and an application user does not manage cloud computing infrastructure. The term Software as a Service (SaaS) is associated with business applications such as Atlassian Jira, Google Drive and Dropbox, to name a few. SaaS applications are charged in a form of user fee.

From the end user’s perspective SaaS is the visible part of the Cloud Computing environment’s perspective. To control that application and environment users have access in the form of a dedicated application that, in most cases, resides on the web. There are numerous benefits of a web application, but the most prominent one is that users do not have to install a client application which reduces the maintenance costs for the provider and saves frustration from the user, it only requires a web browser that is already installed as a standard on all modern operating systems.

Another benefit of SaaS to the user is that the entire application is run by the provider, that means that the user does not have to be concerned about updating or backing up data, this is done by the application provider. This does not only benefit users, its benefits developers in the form of maintenance and updating the application, developers just apply the update in the data center environment, and it is released for all users at the same time, and not having to go through software repairs and maintenance on each users’ computer via software updates. This ensures that all users are running the exact same version without having to manually maintain and update. Furthermore, testing applications doesn’t need to be tested on multiple platforms, on some applications algorithms and computations vary on operating system and processor architecture they are running on, with applications running in a data center on a unified operating system and processor architecture ensures that the computations are optimized for all users and are independent from users’ computer hardware.

Platform as a Service (PaaS)

In recommendation Y.3500, ITU-T defines PaaS (Platform as a Service) a service category where customers have a platform from the provider, whereas on NIST in SP 500-291 states that PaaS is the ability to run custom applications on Cloud Computing infrastructure allowing customers to use programming languages, libraries, services and utilities supported by the provider. In PaaS users are free from managing, maintaining and updating the infrastructure on which users’ application are running on, but at the same time has full administrative access to its application. Platform as a Service (PaaS) provides the user a platform where user can run their own range of applications, according to NIST’s recommendation users can develop and run their own application on the Cloud Computing platform.

When it comes to manage databases, synchronize files and increasing the limit of compute resources, PaaS offers an additional benefit at a cost by leaving users free of applications they can deploy but applying quotas as upper limitations of the compute resources (CPU, RAM, HDD, Bandwidth), for databases enables them to utilize and manage their own databases but it provides additional services to backup or replicate the database either in its entirety or partially at an additional cost. As described previously quotas are upper limitations of compute resources that can be used by individual users and agreed to terms with the Cloud Service Provider prior when a contract with CSP has been established.

Security in Cloud Computing

While cloud computing is a new era that enables businesses move quicker and integrate with different services that accelerate building, deployment and hosting of their own services, it does not come without a major challenge which is security.

While the majority of challenges are technical in nature, there is also the human factor that needs to be handled and not overlooked. While UCX provides software development and hosting services to customers, this document provides definitions and policies used throughout the organization.

Cloud Service Provider

At UCX the cloud service provider of choice is Google Cloud Platform (GCP in short), UCX has chosen Google as a preferred cloud provider due to Google being one of the pioneers in security and offers various security services by default, without custom configuration.

Data Encryption at rest

UCX platform relies on Encryption at Rest approach from Google Cloud Platform on multiple layers, Google Cloud Platform encrypts customer content stored at rest without any further action from its customers. However there are cases that are not currently stored as encrypted such as Serial console logs from virtual machines in Google Compute Engine, core dumps written to local drives when a process fails unexpectedly, debugging logs written to local disk, temporary files used by storage systems and some customer content metadata, while these may contain sensitive data UCX platform is built on top of Docker and Kubernetes and that combination does not allow persistent information to be stored on disks therefore the temporary sensitive information is not stored at all.

Google uses several layers of encryption to protect data. Google successfully encrypts the Application, Platform, Infrastructure and Hardware layers. Google uses AES256 as a default encryption algorithm (with AES128 being another supported algorithm). Based on our above-mentioned NIST recommendations, both AES256 and AES128 are recommended by NIST.

Moreover, data that are to be stored is split into chunks and each chunk is encrypted with unique data encryption key that is stored alongside data on disk and encryption keys are exclusively stored on Google’s central Key Management Service that is redundant and globally distributed. Data is stored encrypted at the storage level using either AES256 or AES128. However, UCX does not encrypt each database column in addition to what is being provided by Google, for current UCX needs the encryption capabilities offered by Google are sufficient unless it is otherwise requested.

Information Security Policy

UCX is committed to respecting the privacy of all its customers while protecting customers’ data from outside parties, UCX does this while maintaining a secure environment in which access to any data can meet UCX commitment. UCX personnel handling sensitive information should ensure the following:

  1. Handle sensitive information in such manner that fits with their sensitivity;
  2. Limit use of personal communication systems (such as personal phones, IMs etc.) in order to ensure they do not interfere with job performance.
  3. For personnel that has access to customers’ sensitive information UCX reserves the right to monitor, access, review, audit, copy, store or delete any electronic communications, equipment, systems and network traffic for any purpose;
  4. Use of email, internet and other UCX resources to engage in any action that is offensive, threatening, discriminatory, defamatory, pornographic, obscene, harassing or illegal is strictly prohibited;
  5. Disclosing any sensitive information without prior authorization is prohibited;
  6. Keeping credentials (passwords and account information) secure is mandatory;
  7. Request prior approval from management before installing a new software, hardware o accepting third-party connections from the outside;
  8. Installing unauthorized software or hardware, including modems, USB keys and wireless access points is strictly prohibited without explicit management approval;
  9. Clearing desks of sensitive information and locking computer screens when leaving the desk unattended is mandatory;
  10. Information security incidents must be reported immediately without any delays. Each personnel who handles sensitive information is responsible for ensuring UCX systems and data are protected from unauthorized access and improper use.

Acceptable Use Policy

UCX has a culture of openness, trust and integrity but at the same time it is committed to protecting employees, partners and itself from illegal or damaging actions by individuals, either knowingly or unknowingly. UCX personnel with access to sensitive information:

  1. Ensures that they have appropriate credentials and have the right to be authenticated to use certain technology.
  2. Ensures that they have taken all necessary steps to prevent unauthorized access to confidential and sensitive information.
  3. Ensures the use of technologies on acceptable network locations.
  4. Keep passwords secure and do not share any sensitive credentials.
  5. Are responsible for the security of their own credentials (passwords and account information).
  6. Should ensure that all computer systems should be password protected and should activate a password protected automatic lock (via a screensaver or time based automatic activation feature).
  7. Should have special attention for smartphones and tablets because they are most vulnerable and they should not be taken outside of premises without prior approval by management.
  8. Should ensure that posts to newsgroups, forums and social media from a UCX email address should contain a disclaimer stating that the opinions expressed are strictly their own and not necessarily those of UCX, unless posting is in the course of business duties.
  9. Must be vigilant and must be cautious when opening and/or downloading email attachments received from unknown senders, they may contain viruses and other malicious binaries.

Disciplinary Action

Violation of the standards, policies and procedures written in this document will result in disciplinary action for that employee, these range from warnings, suspending and leads up to termination of employment. Claims of ignorance, good intentions or using poor judgment will not be used as an excuse for non-compliance.

Sensitivity Levels

All data and media containing data (sensitive or insensitive) must always be labelled to indicate sensitivity level described below:

  • Confidential Data includes information assets that contain legal requirements for preventing disclosure that includes any data that would cause severe damage to UCX if disclosed or modified. Confidential data includes all data including what may seem not relevant up to UCX customers’ data.
  • Internal Use Data may include information that the owner of the data, or UCX customers feel should be protected unauthorized disclosure.
  • Public Data is the information that can be freely distributed and is considered public.

Access to sensitive data

All access to sensitive data should be controlled and authorized. All job functions that require access to this data should be clearly defined and authorized prior to accessing the sensitive data.

  1. Any display of UCX customers’ sensitive information should be restricted at a minimum display information, these data must be sanitized before being displayed.
  2. Access rights to privileged users should be restricted only to the degree that is necessary for them to perform job responsibilities.
  3. Privileges should be assigned to job classification and function, this should ensure proper role based access control is applied on all systems including Google Cloud Platform.
  4. Access to sensitive information, personal information, business data and the like are strictly forbidden and employees that need to have access to such confidential data should have a legitimate need to have access to this information.
  5. No other employees should have access to the sensitive and confidential data unless they have genuine need and explicit approval.
  6. UCX will ensure a written agreement that includes an acknowledgement that UCX as a service provider will be responsible for the sensitive information it possesses and stores.

Physical Security

Access to sensitive information in both hardware and software must be physically restricted to prevent unauthorized individuals from obtaining sensitive data, while UCX platform and architecture is based on GCP, the following excerpt is taken from Google’s own infrastructure whitepaper:

Excerpt from “Google Infrastructure Security Design Overview – Security of Physical Premises”:

“Google designs and builds its own data centers, which incorporate multiple layers of physical security protections. Access to these data centers is limited to only a very small fraction of Google employees. We use multiple physical security layers to protect our data center floors and use technologies like biometric identification, metal detection, cameras, vehicle barriers, and laser-based intrusion detection systems. Google additionally hosts some servers in third-party data centers, where we ensure that there are Google-controlled physical security measures on top of the security layers provided by the data center operator. For example, in such sites we may operate independent biometric identification systems, cameras, and metal detectors.”

Moreover, Google went a couple of extra steps to have custom hardware design by Google and use various technologies that use cryptographic signatures over low-level components such as BIOS, bootloader, kernel and the base operating system image.

Excerpt from “Google Infrastructure Security Design Overview – Hardware Design and Provenance”:

“A Google data center consists of thousands of server machines connected to a local network. Both the server boards and the networking equipment are custom-designed by Google. We vet component vendors we work with and choose components with care, while working with vendors to audit and validate the security properties provided by the components. We also design custom chips, including a hardware security chip that is currently being deployed on both servers and peripherals. These chips allow us to securely identify and authenticate legitimate Google devices at the hardware level.” Excerpt from “Google Infrastructure Security Design Overview – Secure Boot Stack and Machine Identity”: “Google server machines use a variety of technologies to ensure that they are booting the correct software stack. We use cryptographic signatures over low-level components like the BIOS, bootloader, kernel, and base operating system image. These signatures can be validated during each boot or update. The components are all Google-controlled, built, and hardened. With each new generation of hardware, we strive to continually improve security: for example, depending on the generation of server design, we root the trust of the boot chain in either a lockable firmware chip, a microcontroller running Google-written security code, or the above-mentioned Google-designed security chip.

Each server machine in the data center has its own specific identity that can be tied to the hardware root of trust and the software with which the machine booted. This identity is used to authenticate API calls to and from low-level management services on the machine.

Google has authored automated systems to ensure servers run up-to-date versions of their software stacks (including security patches), to detect and diagnose hardware and software problems, and to remove machines from service if necessary.”

However, the following restrictions are applied when it comes to on premise computer system and/or smart phone access for UCX personnel with access to sensitive information:

  1. Are responsible for exercising good judgment regarding the reasons for using personal equipment.
  2. Should ensure they have appropriate credentials and are authenticated with the right user before using the cloud console and other related technologies.
  3. Should be cautious and take necessary steps to prevent unauthorized access to confidential data which includes customers’ sensitive information.
  4. Should ensure that technologies should be installed and used in an acceptable network locations
  5. A list of devices that have access to the database or the location where the sensitive data is located should be maintained.
    1. The list should include type, model and location of the device.
    2. The list should have the serial number or a unique identifier of the device who is accessing the information.
    3. The list should be updated when devices are added, removed or the owner is changed.
  6. Should verify the identity of any third-party personnel claiming to repair or run maintenance tasks using the devices, installed new software and/or hardware.
  7. Keeping credentials (passwords and account information) secure is mandatory.
  8. Any media (including printed or handwritten paper, backup tapes, USB sticks, External Hard Drives or internal computer hard drive) is considered a media.
  9. A media that contains sensitive information must be handled and distributed by trusted individuals.
  10. Media that contains sensitive information should not be left in a public office desk that can be seen by others.
  11. Visitors must always be escorted by a trusted employee or HR personnel when in areas that hold sensitive information.
  12. Network jacks and Wi-Fi networks located in public and areas accessible to visitors must be disabled for internal network access and enabled only when internal network access is explicitly authorized. These should route visitors on an isolated and monitored network.
  13. Should ensure that all computer systems should be password protected and should activate a password protected automatic lock (via a screensaver or time based automatic activation feature).

Data Protection

In-Transit Data Protection

If sensitive data must be transported physically or electronically it must be securely protected.

  1. Sensitive information must never be sent over the internet via email, unsecured instant chat or any other end user technologies.
  2. If there is a business need to send sensitive information via internet or any other modes then it should be done using secure mechanisms, end-to-end and strong encryption using AES encryption, PGP encryption, SSL, TLS etc.
  3. Transfer of media containing sensitive information must be authorized by management and logged.
Data Disposal Regulations

All sensitive information that are no longer required must be securely disposed, regardless of media type whether it is physical or electronic.

  1. An automatic process exists to permanently delete electronic data when they are no longer required.
  2. All hard copies of sensitive information must be manually destroyed when no longer required.
  3. Hard copy materials such be crosscut shredded, destroyed completely or turned into a liquefied pulp so they cannot be reconstructed.
  4. A documented procedure for electronic media destruction is in place:
    1. All sensitive data on electronic media must be rendered unrecoverable when deleted through electronic wiping technologies that does secure deletion, or the physical destruction of the media where the sensitive information is stored.
    2. If the deletion procedure is being done using software, the process includes industry accepted standards to be followed for secure deletion.
  5. All documents that are awaiting to be physically destroyed must be on a locked container marked “To be destroyed” and access to these documents must be restricted and highly protected.
Employee Awareness

The policies and procedures outlined in this document are incorporated into company practices such that it maintains a high awareness of security practices within the company. Protection of sensitive data requires regular training of all employees and third party contractors, listed below are procedures to ensure proper maintenance of high awareness of security practices are met:

  1. Review sensitive information procedure handling and conduct periodic security awareness meetings such that they become a routine in day to day company practice.
  2. Distribute this security policy to personnel who is eligible to handle sensitive information. It is required that employees who handle and/or are involved with sensitive information to confirm that they understand the content of this security policy document by signing an acknowledgement form attached with this document.
  3. All employees that handle sensitive information will undergo background checks (such as criminal and credit record checks within the limits of the local law where the personnel are located) before they commence with the employment.
  4. UCX Information Security Policy must be annually reviewed and updated accordingly.
Network Security

UCX operates solely on the cloud, there are no local on premise servers that are installed to do any kind of deployments, even in the cloud only certain IP addresses of UCX offices are allowed to be connected to the cloud infrastructure, a limited number of UCX personnel have access to production infrastructure. Below is the list of items and procedures to ensure best security practices:

  1. Firewalls are implemented to ensure the access to cloud infrastructure is limited to a few UCX office IP addresses.
  2. Multiple network interfaces are being used on Google Cloud Platform to ensure proper DMZ implementation and restrict access to the actual infrastructure while keeping only public facing services accessible via the internet.
  3. A firewall on Google Cloud is configured to restrict connections between untrusted networks and internal systems where sensitive information is being kept.
  4. All inbound and outbound traffic is restricted to and from where the sensitive information is being stored.
  5. All infrastructure inbound traffic has to be authorized by management, restrictions must be documented prior to authorization and all access has to be logged with a timestamp.
  6. No direct connections can be made to the data store where sensitive information is being kept.
  7. All infrastructure access must be done via the UCX offices IP addresses, employees, vendors, contractors and other third parties who are given access must connect to UCX offices via VPN and their access will be monitored.
System and Password Policy

All users, including contractors and vendors with access to UCX systems are responsible for taking appropriate steps and be responsible for system and password policy outlined below.

  1. A system configuration standard is in place with industry accepted hardening standards based on NIST.
  2. System configurations must include common security practices and settings.
  3. All vendor, operating system and other systems’ accounts and passwords have to be changed at provisioning time.
  4. All unnecessary system services, protocols, daemons etc., should be disabled if not in use.
  5. All patches for protocols, daemons, services in use have to be applied.
  6. In cases where patches are not yet released for any protocol, daemon, service it must be documented and justified accordingly.
  7. All unnecessary default accounts must be removed or disabled before provisioning into UCX infrastructure.
  8. No password access should be allowed via Secure Shell (SSH) service. Only via public SSH key generated for each specific user.
  9. All unnecessary functionality such as scripts (bash, awk, sed), drivers, kernel modules, subsystems, file systems, web servers etc. must be removed.
  10. All users with access to any sensitive information should have a unique identifier, current implementation requires users to be identified with company email while having access to cloud infrastructure.
  11. All terminated users must be deactivated and removed immediately.
  12. All system and user level passwords must be changed at least quarterly.
  13. A minimum password history of four last used passwords must be implemented.
  14. For each new user, a unique password must be generated and users must be prompted to change on their first login. This is mainly applied to the GSuite account which is the key account for accessing infrastructure.
  15. Shared passwords and other authentication credentials that are used to administer systems are forbidden.
  16. All console and non-console administrative access will use appropriate secure technologies such as VPN, SSH, SSL etc.
  17. Insecure services such as telnet are strictly forbidden.
  18. Administrator access through web based Google Cloud Platform management is encrypted using the latest and greatest encrypted connection.
  19. A strong password policy must use the following combination:
    1. Should be longer than 6 characters.
    2. Should include mixed-case letters.
    3. Should contain at least one digit.
    4. Should contain at least one punctuation mark.
    5. Should not contain any personal information.
Anti-virus Policy
  1. All Windows machines should run the Windows Defender that comes with Windows 10 and should ensure that Windows Defender is running in the background at all times.
  2. All machines running MacOS should have FileVault 2 encryption enabled for all hard drives.
  3. All machines running MacOS should have the default Gatekeeper option to only allow downloads from trusted app distributions from the Apple Mac AppStore.
  4. All removable media (such as USB sticks, external hard drives, external phones connected to computers) must be scanned for viruses and trojan horses before being used.
Patch Management Policy
  1. All software systems and their components owned by UCX must have up-to-date security patches installed to protect assets from known vulnerabilities.
  2. Where applicable, all systems must have automatic software updates enabled.
Remote Access Policy
  1. It is the responsibility of UCX employees, contractors, vendors and other third parties with remote access privileges to UCX infrastructure and corporate network to ensure their remote access is given the same consideration as being on UCX premises without any exception.
  2. Secure remote access must be strictly controlled via two factor authentications via OTP (one-time password) where applicable or public/private key combination where applicable.
  3. Contractor, partner, vendor or any other third party with access to UCX network and/or infrastructure will only be enabled for the time it is requested and accepted by UCX management and removed immediately when no longer required.
  4. All VPN users that are connected to the company’s internal networks must be monitored on a regular basis.
Cloud Configuration Standards
  1. All cloud systems must be configured according to Google Cloud Platform Best Practices for Enterprise Organizations.
  2. Before being deployed to production, a system must be certified in accordance to the applicable configuration standard.
  3. Updates to network device operating system and/or configuration settings that fall into UCX standards are applied and announced by UCX DevOps team. Updates must be applied within the appropriate time frame identified by the DevOps team.
  4. All network device configurations must be audited at least annually to ensure the configuration continues to meet required standards.
  5. For other devices, a quarterly audit will be performed.
  6. All discrepancies will be evaluated and remediated by UCX DevOps team.
Audit Process
  1. This procedure covers all logs generated by UCX platform systems, the following components generate logs that are stored in ELK (ElasticSearch, Logstash & Kibana) stack:
    1. Operating System Logs (system events and root access logs)
    2. Database Audit Logs
    3. Firewall Logs
    4. Kubernetes Pod Logs
    5. General Kubernetes Logs
    6. IDS Logs
    7. Java JVM logs
    8. Java SpringBoot Logs
    9. UCX Platform Logs
    10. Application Logs
  2. Audit logs must be kept at least for 3 months for immediate view and analysis and 12 months offline.
  3. Log review is carried by the ELK stack, Prometheus and other network monitoring systems that are controlled by UCX and installed on servers located within UCX data center location(s).
  4. Only management, DevOps and a very limited number of personnel (including developers and QAs) have access to company logs and that is only for job-related needs.
  5. The network monitoring system is configured to alert UCX DevOps team to any suspicious system alerts and system changes.
  6. Email and SMS alerts will go directly to UCX DevOps team with incident information.
  7. Following OS events are configured for logging and are monitored by UCX DevOps team:
    1. All user account additions, modifications or deletions.
    2. All failed login attempts.
    3. Any system file modification.
    4. Any access to the server where application containing sensitive information is running.
    5. Any access to the server where database containing sensitive information is running.
    6. Any actions taken by the root or administrative privileges, this includes a trail from which user root access has been obtained.
    7. Any user that has access to audit logs.
  8. The following database events are configured for logging and will be monitored by UCX DevOps team:
    1. Any failed user access attempts to log in to the PostgreSQL database.
    2. Any login that has been added or removed as a database user to the production or any other system-level database.
    3. Any login that has been changed, added or removed from a specific role.
    4. Every password that has been changed in the system.
    5. All new database creations, changes or dropped.
    6. Actions will be taken by UCX DevOps team.
Secure Cloud Application Development
  1. Application development policy for security implementation across development is a plan of action to guide UCX developer’s decisions and actions during software development to ensure proper software security implementation. This policy is designed to be language and platform agnostic so that is applicable across all software development principles within UCX.
  2. To comply with Secure Cloud Application Development Coding Policy is a requirement for all UCX software development and trusted contractor that work with UCX.
  3. Each software development phase is mapped with security activities listed below:
    1. Design
      1. When designing requirements, identify security needs and look from security perspective.
      2. When doing software architecture reviews, include a security review and try to identify architectural security flaws.
      3. Include security perspective on design reviews.
      4. Implement threat modeling when on design phase.
    2. Coding
      1. Code against best practices that involve security.
      2. Perform Static Analysis.
    3. Testing
      1. Vulnerability Assessment
      2. Fuzzing
    4. Deployment
      1. Server Configuration Review
      2. Kubernetes Deployment Scripts Review
      3. Infrastructure Configuration Review
      4. Network Configuration Review
  4. All written code need to be checked and validated against the current UCX Coding Standards. All developers need to verify their code is in accordance with the coding standards. All code reviewers must also verify whether the colleagues’ code is in full compliance with the coding standards.
  5. Only validated code will be merged into production environment. A review and validation will ensure that code implements fundamental security properties.

Application developers will:

  1. Ensure that their written code meets the level of confidence that the software is free from exploitable vulnerabilities regardless of whether they are already designed from the beginning or a component has been written during its life cycle.
  2. Ensure that their written code provides predictable execution such that when executed, will provide security functionality as intended.
  3. Apply standard coding techniques address injection vulnerabilities, particularly SQL injections, buffer overflows, XSS (cross site scripting), improper access control (including directory traversal and URL restrictions), CSRF (cross site request forgery), session management and authentication/authorization issues.
  4. Never trust incoming data therefore must be checked and never trusted.
  5. Disable debug error messages that can potentially reveal system information.
  6. Ensure full use of object oriented techniques such as inheritance, encapsulation and polymorphism where applicable.
  7. Be careful when using environment variables and always check for boundaries and buffers.
  8. Applications must do both server and client side user input validation to ensure its security aspect and also the meaning.
Third party access
  1. All third-party companies providing critical services to UCX must provide an agreed Service Level Agreement.
  2. All third-party companies/partners providing hosting facilities must comply with UCX’ Physical and Access Control Policy.
  3. All third-party companies which have access to sensitive information must:
    1. Comply with UCX security requirements.
    2. Acknowledge their responsibility for securing sensitive information.
    3. Acknowledge that access to sensitive information must only be used for assisting the completion of job duties.
User Access Management
  1. Access to UCX is controlled through a formal user registration process that begins with formal notification from UCX management.
  2. Each user has their own unique ID in the form of email so each action can be linked and made responsible for their actions.
  3. By default, a standard level of access is provided; other services can be accessed when specifically authorized by a UCX management.
  4. Job position and title decides the level of access to sensitive information.
  5. A request for service must be made in writing via email by every new employee to UCX management (this goes through their project manager and escalated accordingly). The request format is not specified but must include the following information:
    1. Full name of the person making the request
    2. Job title of the person and team name
    3. Start date
    4. Services required
  6. Project manager or a higher UCX management position must always be CC’d in the request.
  7. Upon abrupt employment termination, all users’ system logins must be immediately revoked.
  8. For every termination process appropriate, UCX management will inform UCX DevOps team about who left the company and the date of leaving.

HIPAA Compliance Policy

HIPAA Security Procedures

UCX provides its software development services to various industries ranging from medical to IT which may involve the observation of various sensitive information including patient records of hospitals, clinics or other health care organizations. For the purposes of this policy, the following items are described:

  1. Definitions below define terms used in the medical field:
    1. Electronic Personal Health Information (EPHI in short) is a subset of Personal Health Information (or PHI) consisting of any PHI that is electronically transmitted media or maintained in an electronic format. UCX is a technology company and in most cases, it handles electronic data formats.
    2. Individual is the person who is the subject of PHI and applies to the same term “individual” defined by HIPAA regulations.
    3. HIPAA Regulations are arranged at Title 45 of the Code of Federal Regulations (or CFR for short) and are related to the privacy and security of PHI.
    4. Personal Health Information (PHI in short) include any information concerning an individual oral or recorded in any form or medium, it further includes the information regardless if it relates to the past, present or future physical or mental condition of the individual, the health care of the individual, or the past, present or future payments for health care of the individual, it further fully complies with HIPAA regulations for full data protection.
  2. Use of PHI is strictly prohibited except as it is necessary to provide the services. UCX hereby agrees that any PHI or any other sensitive information provided or made available to UCX shall not be used or disclosed further other than permitted or what is required by this policy. Furthermore, without limitation UCX agrees:
    1. Not to share PHI or any sensitive information with anyone who is not directly involved with patient’s care treatment or research facility
    2. Not to discuss PHI or any other sensitive information in areas where it may be overheard.
    3. Not store any PHI or sensitive information on a portable device or any other electronic device.
    4. Not take any photos, videos, voice recordings or any other reproduction form of any PHI.
  3. Termination will be taken into effect for any UCX employee that has breached this policy.
  4. State Law Preemption indicates that certain provisions of state law concerning privacy and PHI may not be preempted by and may replace the HIPAA Regulations. With state law provisions not replaced by the HIPAA regulations, UCX shall maintain full and complete compliance with all state privacy requirements.
Risk Analysis and Risk Reduction

UCX acknowledges the potential risks of vulnerabilities that can threaten confidentiality, integrity and availability of EPHI or any other sensitive information that is related with transmitting and storing EPHI, therefore Risk Analysis and Risk Reduction regulations exist to help analyze and mitigate potential risks.

Risk Analysis
  1. UCX personnel that handles sensitive information is responsible for coordinating the risk analysis, the personnel should conduct a thorough analysis of potential risks by:
    1. Developing comprehensive systems inventory that includes the following:
      1. Hardware Inventory (network devices, workstations etc.);
      2. Software Inventory (operating systems, applications, services, etc.);
    2. Identify and document all systems that contain sensitive information and/or EPHI:
      1. Document systems containing sensitive information and/or EPHI;
      2. Identify source of data (created or received from third parties);
      3. In cases where the data has been received from third parties, identify the source and method the data has been retrieved;
    3. Determine whether the data has been forwarded to third parties:
      1. If data is forwarded, identify the receiver of the forwarded data and method of transfer;
      2. Identify how critical the data is in cases data were no longer available;
      3. Determine the sensitivity of the data from the security standpoint
    4. Assess potential data integrity, data confidentiality and data availability risks for EPHI, assessment includes but not limited to the following:
      1. Intentional malicious attacks (including but not limited to network scanning, snooping, backdoor hacking, computer viruses, trojan horses etc.);
      2. Unintentional human errors (including but not limited to application errors, network issues, human nature issues);
      3. Natural threats (including but not limited to tornadoes, earthquakes, floods etc.);
      4. Environmental incidents (including but not limited to fire, power outage etc.);
    5. Risk analysis will be periodically reviewed that includes potential risks and vulnerabilities to the integrity, confidentiality and availability of EPHI and sensitive information.
Risk Reduction
  1. Risk reduction and vulnerability mitigation of EPHI and other sensitive information will follow appropriate security measures that are sufficient to prevent any risks, the team shall:
    1. Continuously assess potential risks and vulnerabilities to any system containing EPHI and/or other sensitive information as a part of periodic review and reasonably update security measures as appropriate.
    2. Identify follow up measures to ensure the security procedures and policies remain adequate and are followed for the protection of EPHI and other sensitive information based on:
      1. Relationship changes (when new EPHI or other sensitive information has been created, changed or removed);
      2. When federal, state or local legislation that is related to EPHI has been added, changed or removed;
    3. Do a thorough review of new/modified policies.
HIPAA Auditing Process

UCX auditing process is in compliance with HIPAA, see Audit Process under Data Protection chapter of this document.

Incident Response Actions

Below are listed incident actions and their corresponding reporting procedures:

  1. Any UCX personnel with access to EPHI and/or sensitive information suspects a security incident, he/she shall immediately inform his/her project manager and department head by email, telephone or in person. If the incident involves viruses, trojan horses, malicious code, network, system attacks or any other attacks to the local network, production networks, Kubernetes cluster, databases etc. he/she will immediately inform head of DevOps and head of the technical department and CTO.
    1. Such employee shall describe the incident to full extent possible that includes date, time and incident details. This information from this point on will be treated as confidential information.
  2. The project manager and department head should immediately work with head of DevOps, head of the technical department and CTO to minimize negative impact of the security incident.
    1. Project manager and/or department head shall describe the incident to full extent possible that includes date, time and incident details. This information from this point on will be treated as confidential information.
  3. Additionally, involved parties (the employee, project manager and/or department head) should fill out the Security Incident Form and the completed form should be escalated to higher level management of the company. A copy should be kept at the affected department or pillar.
    1. Project Manager and/or Department Head should document the following to full extent:
      1. A full assessment to what may have been compromised (hardware, software and/or services).
      2. Any follow up interviews related with the incident.
  4. Project Manager and/or Department Head along with DevOps shall:
    1. Take all necessary actions to limit damage associated with the security incident;
    2. Ensure the incident evidence is safely secured;
    3. Full restoration of the affected systems (hardware, software and/or services);
    4. Implement any remediation measures to reduce (or eliminate if possible) future exposures in the area;
    5. Conduct interviews related to the incident;
    6. Contact law enforcement if necessary;
    7. Prepare a summary report of the incident.

Breach Notification and Incident Investigation

Breach Notification

Upon getting information of non-permissible access, use or disclosure of EPHI and/or sensitive information, a breach will be presumed and an investigation will begin alongside appropriate risk assessment to determine the probability of EPHI and/or sensitive information compromise.

Incident Investigation
  1. Every incident (whether a security incident, breach or other malicious activities) will be documented, this includes source of the discovery, discover date, date of breach and PHI and/or sensitive information breached if it is known at the time of the report.
  2. Upon documentation, the investigation team shall determine if impermissible use or EPHI and/or sensitive information disclosure was insecure. Insecure EPHI and/or sensitive information means that the information has not been rendered unusable or unreadable. Methods of rendering EPHI and/or sensitive information as unusable or unreadable include (but are not limited to):
    1. Encrypted data, valid encryption process are those consistent with UCX encryption guidelines, read Data Encryption at rest under Security in Cloud Computing chapter.
    2. Data Disposal, media which EPHI and/or sensitive information is stored or recorded must be destroyed before discarded, read Data Disposal Regulations chapter.
  3. In cases where EPHI and/or Sensitive Information is secure (or was secured as a result of actions) should be documented as such and breach notification review must be appropriately closed and filed.
  4. In cases where EPHI and/or Sensitive Information is insecure, sufficient information will be gathered by technical reviews, employee interviews and other analysis to determine if the breach was expected.
  5. Prohibited use or disclosure of unsecured EPHI and/or sensitive information is classified as a compromise, a four-step risk assessment will be conducted to determine the level of compromise:
    1. Nature and importance of EPHI and/or sensitive information involved;
    2. The unauthorized person(s) who used the EPHI and/or sensitive information or to whom the information has been disclosed;
    3. Whether the EPHI and/or sensitive information was actually acquired (physically or digitally) or it has been only viewed;
    4. The extent to which the risk to the EPHI and/or sensitive information has been mitigated.
  6. Based on the risk assessment a probability of the compromise will be determined:
    1. If the probability of compromise is low:
      1. This will be documented, filed and the investigation will be closed;
      2. The investigation and findings will be reviewed by technical management and company officials.
    2. If the probability of compromise is anything other than low:
      1. Notification of such compromise will be immediate to head of the technical department and company officials;
      2. Determine the level of EPHI, sensitive information and other actions affected by the breach;
      3. Immediate start of the mitigation, review and interviews from technical perspective and human nature;
      4. Start of the disciplinary investigation and take appropriate actions;

References

[1] Encryption at Rest in Google Cloud Platform Whitepaper, https://bit.ly/2O6jy5i

[2] Google Cloud Platform – Best practices for enterprise organizations, https://bit.ly/38Dz3v5

[3] Google Infrastructure Security Design Overview, https://bit.ly/31Zq06h

[4] Cloud Security Alliance, https://cloudsecurityalliance.org/

[5] NIST Cloud Computing Architecture Reference, https://bit.ly/3iNijGr

[6] Google’s Approach to IT Security Whitepaper, https://rb.gy/i9jfct

[7] Google Security Whitepaper, https://bit.ly/3iLhcXH

[8] ISO 27001 Requirements, https://bit.ly/3iSeJLh

[9] Geant Information Security Policy Best Practices Document, https://bit.ly/2VZs4HO

[10] IEEE Information Security Policies: A review of challenges and influencing factors, https://bit.ly/2O6rhQX

[11] Secure the Cloud: From the Perspective of a Service-Oriented Organization, https://bit.ly/38GysbS

[12] HIPAA Breach Notification Rules, https://bit.ly/2ZfCiG1

[13] HIPAA Security Rules, https://bit.ly/38NzFyk

[14] HIPAA Privacy Rules, https://bit.ly/31YgqAu

[15] American Health Care Association’s HIPAA Policy and Procedure Manual, https://bit.ly/38K0q6O

[17] Google Cloud Platform HIPAA compliance, https://bit.ly/38RtGZr