Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Current »

Scope

This policy applies for our employees and (at least partly) vendors. Having this cybersecurity policy we are trying to protect Purde Software’s data and technology infrastructure.

This policy applies in addition to the Privacy policy and the Service level agreement.

Please note that due to the size of our company (3 part-time employees) this policy might not be as detailed as for other companies.

Protection of our own infrastructure (PCs, laptops etc.)

Email

We do not open attachments of senders we do not trust.

USB drives / SD cards etc.

We do not insert USB devices, SD cards etc. we do not trust.

Virus scanner

We use a state-of-the-art virus scanner on all devices.

Passwords

On our development PCs we have a password policy in place which requires passwords of a certain strength and expiration date. On mobile devices we use passwords or bio-metric access protection.

Transferring data

When transferring data from and to our clients we try to use our Jira ServiceDesk whenever possible. A transfer of confidential data via email should be avoided.

Protection of our cloud servers

Our cloud servers are protected as follows:

  • For all servers we implement a two-factor-authentication.

  • We only used well established providers (Heroku and AWS).

  • The servers are located in the EU.

  • We only offer an https interface to the clients.

  • The cloud servers are hardened - the open ports are minimized.

Protection of our apps

Cybersecurity design guidelines

As we are a small company a full-blown quality management system has not been established. However we adhere to the following principles during development and any change:

  • Our Cloud apps follow the security requirements set by Atlassian.

  • All user input (e.g. via dialogs) must be escaped before its output.

  • All data transferred from the client to the server (e.g. cache data) has to be escaped before its output.

  • All REST interfaces or servlets contain a check whether the current user has the appropriate permission before executing any actions.

  • GET requests shall be avoided in case data is updated - risk of forged requests.

  • All permission checks are done on the server not the client.

  • When a request collects data from multiple content entity objects we check that the current user has a view permission on them before including them in the result.

  • We only include the necessary information the responses.

  • We minimize the number of 3rd party libraries in our apps.

  • In case we use 3rd libraries we check the published anomalies list before using them and regularly after release.

  • Cloud only: we do not store customer data within our servers except those date needed to setup the service.

  • Log outputs shall be minimized to the minimum.

Cybersecurity audits

We perform cybersecurity audits depending on the criticality:

  • Protection of our infrastructure: once per year

  • Protection of cloud servers: once per year

  • Protection of apps: at every relevant change or at least once per year for every app

The results are kept here: /wiki/spaces/PLUG/pages/1765998612 (for internal use only).

Static Code analysis

All our apps will undergo a continuous static code analysis with the focus on security. We are using Snyk for this.

Dependency checks

The source code of all apps is hosted in Bitbucket. There we use the Snyk plugin to scan for vulnerabilities of dependencies. Vulnerabilities in dependencies will be fixed as soon as an update of the dependency is available (under the condition that the new dependency is still compatible with our app).

Penetration tests

Our cloud apps which are labeled “Cloud Security Participant” undergo a penetration test before applying for the program. In case of bigger changes the penetration test will be repeated.

Protection of data in logs

A certain level of logging is needed to help our customers in case of problems. However the following rules apply:

  1. Logs shall be deleted as early as possible (typically 7 days).

  2. As already indicated in the design guidelines: log outputs shall be minimized to the minimum .

Cybersecurity issue fixing

The timelines to fix security related issues is outline in the Service level agreement. It is our target to fix found issues as fast and efficient as possible.

In case we identify an issue we inform Atlassian via: https://ecosystem.atlassian.net/servicedesk/customer/portal/14/group/84/create/435

Disaster recovery

Internal own infrastructure

In case we loose own infrastructure like a laptop used for development we only have to reinstall the development tools and pull the source codes from Bitbucket. Our Jira Service Desk and Confluence instance is sufficiently protected by Atlassian.

Cloud apps

As we don’t store any customer data (apart from installation information) on our systems a total loss of an app only means that we have to re-build the environment and let customer reinstall the app in case we also lost the database backup. A re-build should be completed within 48 hours.

CAIQ-Lite

Our own assessment regarding the CAIQ-Lite questionnaire can be found here.

  • No labels