Security Architecture

Introduction

Keeping our customers’ data secure is the most important thing that Clinch Talent does. We go to considerable lengths to ensure that all data sent to Clinch Talent is handled securely; keeping Clinch Talent secure is fundamental to the nature of our business.

We want to share some of the details of what we do to keep things secure.

Our team

Our team includes people who’ve played lead roles in designing, building, and operating highly secure Internet-facing systems, such as Internet Banking platforms, cloud services, and payment processing systems for companies such as banks and telecom operators.

Hosting

All of our services and data are hosted in Amazon Web Services facilities in Dublin, Ireland. Further details about the considerable measures Amazon take in securing their facilities and services can be found here: https://aws.amazon.com/security/ and https://aws.amazon.com/compliance/

Auditing changes

We use AWS CloudTail to audit changes made to our production systems configuration.

Service personnel access

Access to production systems is granted on a need basis. All access can only be approved by the CTO.

Service personnel use AWS Identity and Access Management (IAM) service to provide their access to relevant services within our production environment.

All service personnel IAM accounts are protected by Two Factor Authentication; providing protection even in the unlikely event of an account password being compromised. All access and changes are audited by AWS CloudTail.

Logical security architecture


Data encryption in transit

All data sent to Clinch Talent is encrypted in transit. Our API and application endpoints are TLS/SSL only and score an “A+” rating on SSL Labs tests; meaning that we only use strong cipher suites and have features such as HSTS and Perfect Forward Security fully enabled.

Data is encrypted both on its way from the customer's browser to our public-facing load-balancer, and also within our datacenter.

SSL certificates are rotated every 12 months.

You can visit the latest test scores at:  https://www.ssllabs.com/ssltest/analyze.html?d=clinchtalent.com&hideResults=on

Data encryption at rest

Data is stored in four ways within our production service:

  • Within our database.

Our database disk volumes are encrypted using AWS RDS AES-256 encryption algorithm.

  • As BLOBs within our blob store

Our BLOBs are stored on AWS S3 and utilize server-side S3 AES-256 encryption facility.

  • Scratch storage on application server disk volumes (/tmp and /log stores)

Our application server disk volumes are provided by AWS EBS and utilize EBS encryption.

  • Database and disk volume backups

We regularly backup our database and disk volumes. All backups use the same encryption keys that are used for the instance volumes and are therefore backups are stored in an encrypted state.

Where appropriate, we use AWS Key Management Service (AWS KMS) to manage, store and rotate the encryption keys used.

Own domain

By default, customer pages are hosted on our “career-pages.com” domain. For additional security and to meet branding requirements, a customer can host on their own dedicated domain, by use of CNAME’s. For example, “careers.customerdomain.com”, can be provisioned.

Additional costs apply.

Multiple and single tenancy options

By default, customers are hosted on our multiple tenancy platform. This means that the hardware and software architecture is shared with other customers.

Our application security architecture by use of individual customer login accounts and browser cookies ensures that individual customer data are kept separated. The vast majority of our customers are hosted on our multiple tenancy platform.

For additional security peace-of-mind, customers can elect to be hosted on a single tenancy basis. This means that dedicated hardware and software is provisioned for that company. Customers on single tenancy  share neither hardware or data with any other customers.

Single tenancy customers must also elect to use their own domain. Additional costs apply for single tenancy.

Regions

By default, customers are hosted on our multiple tenancy platform located in Dublin, Ireland, within the AWS EU-WEST-1 region.

If a customer has a legal, data-protection or safe-harbor requirement that restricts their use of data being stored in Dublin, they can elect for the single tenancy option in a region of their choice.

Single tenancy customers can request their service be hosted in a AWS datacenter located at:

  • Dublin, Ireland (EU)
  • Frankfurt, Germany (EU)
  • Singapore (Asia Pacific)
  • Sydney, Australia (Asia Pacific)
  • Tokyo, Japan (Asia Pacific)
  • Virginia (USA)
  • Oregon (USA)
  • California (USA)
  • Sao Paulo, Brazil (South America)

Upgrade windows

Customers on multiple tenancy are upgraded on a continuous basis as the platform evolves. Customers who elect for single tenancy can select upgrade windows as part of their on-boarding process.

Security patching

The platform at both OS and application framework level is actively monitored, and security patches are applied as soon as they become available.

Application security

Sessions

We make use of user sessions delivered via secure HTTP cookies. The session id is a 32 byte MD5 hash value. The session id consists of the hash value of a random string. The random string is the current time, a random number between 0 and 1, the process id of the running application and a constant string.

The sessions are marked secure and can only be delivered via HTTPS, greatly reducing the risk of session hijacking.

Cross-Site Request Forgery (CSRF)

All pages, forms and Ajax requests used within the application automatically include a security token to protect against CSRF attacks.

HTTPS/SSL

The application is only available over HTTPS/SSL, there are no plain unencrypted HTTP pages anywhere within the application.

This also includes all customer’s public landing pages.

File uploads

All file uploads (images, resumes, audio media) are filtered to ensure there is no executable code contained within them.

User management

All users need to confirm their email address before their account becomes active. Users can set a new password via a “forgotten password” process that works alongside the users validated email.

User accounts can be locked.

The validity of a user's account is checked with every application request.

Region lockout

The application has the ability to block traffic on a permanent or temporary basis from any region or country, if an increase in nefarious traffic from that region is detected.

Logging

User passwords are filtered out and are never stored in application log files.

SQL Injection

All requests are sanitized to ensure that SQL Injection attacks are not possible.

Cross-Site Scripting (XSS)

All input requests and output of the application are filtered for to ensure any HTML or script inputs are sanitize

Still need help? Contact Us Contact Us