Security Practices

Last Updated: 29 March 2019

At Audacix, security and general and especially the security of our applications is not a destination, but a never-ending journey. It is a journey comprised of processes, people and products that helps to keep your sensitive and private information secure.
For this reason security is at the heart of every conversation we have, irrespective of whether we're building our own products or test scripts for you. This page lists some of the steps we take to ensure that security is at the core of all our actions.

Security starts from the first discussion

Architecture

The Qsome Cloud has been architected with the most recent security recommendations in mind. Every update to our cloud environment is quality checked to ensure that our practices are always informed by the latest industry standards and frameworks like ISO27001 and SOC2.

Our security decisions are made with a view to giving you an effective balance between flexibility, integrity and service availability. At the heart of striking this balance is our commitment to keeping your data secure.

Network

Security controls are built in to each layer of our technology stack. The services you use are divided by zones and environments to make sure we comply with your local data security requirements and so that the risk of your data travelling to unknown and unwanted places is minimised.

We implement zone restrictions that limit office, data center, and platform network traffic. Development and production environments are separated and firewalled. Authentication whitelists are used to give explicit authorisation for communications between services.

We deploy software defined and rule-based protocols to control access to our networks. We ensure that all connections are encrypted by default. Our intrusion detection and prevention systems help us identify security issues in both our office and production networks.

Staff connectivity requires device certificates, multi-factor authentication, and use of proxies for sensitive network access. Access to customer data requires explicit review and approval from our management team.

Application

One of the first activities we conduct when designing new features in our applications is threat modelling. Threat modelling allows us to intuitively understand how the new feature or product will affect security.

We use Microsoft's oft-recommended STRIDE framework for this threat modelling exercise. STRIDE allows us to assess our threats from the following perspectives:
  • Spoofing
  • Tampering
  • Reputation
  • Information Disclosure
  • Denial of Service
  • Elevation of Privilege
The information discovered during this process informs our design and development process and also allows us to conduct rigorous and targeted vulnerability testing prior to shipping the new feature.

Keeping our platforms secure

Security isn't just an activity on a checklist, it's in our culture. Within this culture our teams constantly make decisions between speed, flexibility and responsiveness to your needs. Our culture dictates that security is never compromised when performing this balancing act.

So as a minimum, we employ the following security controls in our platforms:

Encryption & key management

All data sent between your systems and our applications is encrypted in transit. Transport Layer Security (TLS) 1.2+ with Perfect Forward Secrecy (PFS) is used to encrypt all data that we send over public networks.

While TLS can be configured in many ways, we employ strong ciphers and key-lengths where these are supported by browsers. Such controls enable us to minimise the likelihood of modification by or disclosure to unauthorised actors.

Google Cloud and AWS are our cloud partners and we use their products to store your data. These providers use physical controls as well as transit level encryption to protect data and our cloud security team is satisfied that this level of protection is currently best-in-class.

Our team pays special care to managing encryption keys. Each key is managed by a single owner and that person follows physical and virtual security protocols to keep the keys secure.

We constantly monitor the changing cryptographic landscape and promptly upgrade our systems to respond to new cryptographic weaknesses as they are discovered and implement best practices as they evolve.

Platform vulnerability management

Being providers of cybersecurity solutions to innovative software teams around the world, we understand that point-in-time vulnerability assessments have serious limitations. We actively promote the shift to constant and consistent vulnerability assessment operating structures and we drink our own kool-aid in this regard.

Accordingly, security is not just the responsibility of our in-house security team or external security partners. It baked into each of our team members' processes and responsibilities, from architects to infrastructure engineers to developers to our QA team. This doesn't happen by magic, it takes concerted effort and empowerment.

Internal platform security testing

As you already know, this process starts from the product architecture phase and continues throughout the life of our platforms and applications. From the development phase internal security testing includes static and dynamic code analysis through code scanning tools. Such tools allow us to identify compromised or otherwise insecure code.

During the testing phase we employ adversarial techniques to break our products and find vulnerabilities that can be exploited by hackers. Such processes use both specialised automated vulnerability scanning tools and manual exploitation enumeration techniques.

These assessments consider the custom code that our developers write as well as other constituent technologies that we may utilise to deliver you our products and features. Our culture dictates that these techniques are utilised by not just our security testing team, but also our developers.

External platform security testing

This phase starts once our products and features have been completed and deemed ready for deployment into production environments.

Despite having in-house cybersecurity experts, to gain independent validation we contract external security consultants to complete penetration tests on our applications and infrastructure.

Our targeted approach to penetration testing usually includes:
  • Black box: Testers are asked to explore and breach our application and infrastructure without any prior information
  • White box: Testers are provided design documentation and briefings from architects and developers to aid their testing
We generally conduct external security testing when making material changes to the code base or feature set in our applications or where our infrastructure has been replicated to different zones or service providers.

Audit Logs

Our applications automatically log all file and user activities on the application. There is a complete audit trail of all activity within the account. The audit log provides administrator insight into what is being done in the system, facilitates discovery and can demonstrate compliance with relevant industry regulations.

Audit logs are date/time stamped and may be able to be tracked by user name, email address, IP address, and action taken. Our audit logs are stored for at least 6 months.

Operational processes

Any knowledgeable cybersecurity expert will tell you that human error is one of the largest sources of security breaches. We also realise that enterprise-grade solutions like ours must not only have secure applications and infrastructure, but also operational processes that complement the technological security measures we implement.

Access to customer data

Our team members' access to your data is restricted to those who 'need to access' only. 'Need to access' is usually only reserved for technical support teams who respond to your queries or project team members who are working on your projects.

Therefore, only authorised Audacix team members and sub-contractors have access to customer data and usually only for completing either of the activities given above.

Unauthorized or inappropriate access to customer data is treated as a security incident and managed through our incident management process. This process includes instructions to notify affected customers if a breach of policy is observed. Our team members have no physical access to data centres or other storage facilities. VPN access to your systems that we are helping you test is limited by IP address whitelists. Such whitelists only contain the static IP address ranges used in our offices.

Data retention & destruction

We have a data and record retention policy to help us ensure that documents are retained in a uniform format for a specified period of time based on a defined retention schedule.

Our employees, contractors, and directors are responsible for following these policies, which include:
  • Retaining records as necessary for business purposes, including maintaining the continuity and availability of records in the event of a disaster or hardware failure.
  • Retaining records in accordance with applicable local laws.
  • Retaining records relevant to pending or reasonably anticipated legal proceedings, consistent with the company’s legal obligations.
  • Retaining records as necessary for tax purposes.
Our data retention and destruction policy also specifies policies related to the destruction of documents that are no longer required for business, legal, tax, or other reasons. As part of the data destruction policy, the method for proper document destruction and disposal is defined.

Customer data created by us as a part of conducting business falls under this policy and will be managed as such.

Handling client-provided data

Data that you provide to us includes, but is not limited to, business intelligence metadata values and descriptions, database schemas, ETL workflows and routines, data content (in database and text files), database backups, images, user access information, and custom data manipulation code.

Data that you provide to us will be removed from our environment and deleted within 30 days of termination of an agreement.

At the end of your agreement with us, we will make your data available to you for up to 14 days. You will not incur any additional costs to access this data.

Incident management & response

In the event of a security breach, we will promptly notify you of any unauthorised access to your data. We have incident management policies and procedures in place to handle such an event and all our team members are trained in how to handle such breaches.

Further, in the event of a breach our processes dictate that all internal and externally contracted subject matter experts will be mobilised to triage the breach, help patch affected areas and work with our teams to ensure that the probability of future breaches is minimised.

You can report any security incidents to us by emailing your project manager or security@audacix.com.

Backup & disaster recovery

Your data and our source code are automatically backed up nightly. Your data is stored redundantly at multiple locations in our hosting providers' data centers to ensure availability.

Importantly, our backup rules are configured to ensure that your data is never stored on servers outside your region. This helps to ensure that you stay compliant with the regulatory frameworks that affect you and that we deliver on our promises to you.

We have well-tested backup and restoration procedures, which allow recovery from a major disaster. The Operations team is alerted in case of a failure with this system.