Information Security Policy

Policy Statement

This policy addresses how Winter, Jülg und Gellweiler – Software Engineering GbR handles security requirements.

This policy reasonably adheres to industry standards and best practices and reasonably provides safeguards against accidental or unlawful destruction, loss, alteration, or unauthorized disclosure or access to covered data. It is designed to provide a consistent application of security policy and controls for Winter, Jülg und Gellweiler – Software Engineering GbR, and all Winter, Jülg und Gellweiler – Software Engineering GbR customers.

Protection of Winter, Jülg und Gellweiler – Software Engineering GbR proprietary software shall be addressed to ensure the continued availability of data and programs to all authorized parties and to ensure the integrity and confidentiality of impacted data and configuration controls.

Product Security

Encryption

To provide data confidentiality in the event of accidental or malicious data loss, all Customer Data should be encrypted. Encryption of data at rest should use at least AES 256-bit encryption. Strong cryptography and security protocols, such as TLS 1.2 or IPSEC, are required to safeguard Customer Data during transmission. The key exchange must use RSA or DSA cryptographic algorithms with a minimum key length of 2048 bits and a minimum digest length of 256. Digital signatures must use RSA, DSS with a minimum key length of 2048 bits, and minimum digest length of 256. Hashed data must use bcrypt for the hashing algorithm. Bcrypt incorporates a salt to protect against rainbow table attacks and is an adaptive function. As such, the iteration count should be balanced to ensure appropriate security vs. performance balance in order to resist brute-force search attacks. The use of any other hashing algorithm must meet industry best practices.

Development

All code should be managed through a version control system to allow viewing of change history and content. All web and cloud applications should be based on secure coding best practices. At a minimum, prevention of common coding vulnerabilities in software development processes should be covered, including the following:
– Injection
– Broken Authentication
– Sensitive Data Exposure
– Security Misconfiguration
– Cross-Site Scripting (XSS)
– Insecure Deserialization
– Using Components with Known Vulnerabilities
– Insufficient Logging & Monitoring

Security Testing

Only Deidentified and Strongly Pseudonymized Data should be used for testing and/or development. Test data and accounts must be removed before production systems become active. Change control procedures should be followed for all changes to system components. The procedures should include testing of operational functionality.

Reliability

Availability and Redundancy

We host all of our cloud applications with AWS. Their data centers have been designed and optimized to host applications, have multiple levels of redundancy built-in, and run on a separate front-end hardware node on which application data is stored.

Our Atlassian Plugins are hosted with Amazon Web Services (AWS), the industry-leading cloud hosting provider, resulting in an optimal performance with redundancy and failover options globally.

Backups

We use AWS Backup as a fully managed backup service that allows us to centralize and automate data protection across our AWS services.

Business Continuity Plan

The aim of this plan is to provide a reference tool for the actions required during or immediately following an emergency or incident that threatens to disrupt normal business activities. An emergency is an actual or impending situation that may cause injury, loss of life, destruction of property, or cause the interference, loss, or disruption of an organization’s normal business operations to such an extent it poses a threat. An incident is any event that may be, or may lead to, a business interruption, disruption, loss, and/or crisis. The plan will help to ensure the continuation of business-critical services by minimizing the impact of any damage to staff, premises, equipment, or records.

The plan will help to include an adequate level of detail used to maintain the business and:

* To ensure a prepared approach to an emergency/incident.
* To facilitate an organized and coordinated response to an emergency/incident.
* To provide an agreed framework within which people can work in a concerted manner to solve problems caused by an emergency/incident.

The plan will also help to identify actions that could be taken in advance of an emergency or incident to reduce the risk of it happening.
As the plan contains personal data we keep it confidential.

Operational Security

Access to databases containing customer Data should always be authenticated. This includes access by applications/services, administrators, and all other users or sources. Authentication is done via individual passphrase-protected public keys. Unauthorized or inappropriate access to customer data is treated as a security incident. Development, test, and production environments must be segregated. Separation of duties must exist between development, test, and production environments. All administrative access should be encrypted. Access via unencrypted protocols (i.e. Telnet / FTP) should be avoided, where possible. Limit the number of concurrent connections to two, where possible.