Are you looking into CareerBot but wondering if you‘re even allowed to use it? Is CareerBot safe? Don‘t worry. Data security and infrastructure are an integral part of CareerBot technology. We’re committed to ensuring all necessary security precautions are taken and we comply with the leading standards, security certifications and penetration testing available.
It is a part of our company’s core values to value and protect any information entrusted to us about our customers. This policy describes how we will safeguard personal and company information, to ensure peace of mind when dealing with our company. It is our policy that:
The purpose of this policy is to establish a protocol for creating and maintaining infrastructure and processes that will protect the security of our customers, and to create processes that will enable us to adequately assess potential risks, and respond to incidents or events that impact the security of CareerBot and its clients data or networks.
Our policies for information security at CareerBot our guided by the CIA triad model. In this context, confidentiality is a set of rules that limits access to information, integrity is the assurance that the information is trustworthy and accurate, and availability is a guarantee of reliable access to the information by authorized people.
Our primary technical procedures for CIA compliance include:
In order to ensure confidentiality, we take a number of measures to ensure that access to sensitive data is restricted to individuals that have relevant training and authorisation to view the data in question, as well as taking measures to secure and protect data through encryption. Further details regarding CareerBot’s confidentiality policies can be found in the ‘Access & Authorization’ and ‘Data Encryption & Protection’ sections of this document.
In order to maintain data integrity, we maintain version, access and encryption controls that ensure that data is kept consistent and accurate at rest and in flight. Furthermore, we maintain backups of data to ensure that in a contingency event, affected data can be returned to its correct state.
In order to ensure data availability, our software and servers are architecture uses high-availability clusters, along with failover controls and adaptive disaster recovery, as detailed in the ‘Disaster Recovery’ section of this document. We take additional security measures to monitor and guard against downtime and unreachable data that can be caused by malicious actions such as denial-of-service attacks.
The CareerBot security model further addresses additional security considerations raised in the Parkerian Hexad model, by maintaining authenticity or non-repudiation of data through logging of data access, and ensuring adequate data possession through the access and authorization controls details under “Access & Authorization”
We manage user access and authorization through an authentication process that is is designed to confirm the identity of entities accessing the database. In this context, entities are defined as:
At CareerBot, secure access and authorization is managed through the following policies and practices:
Security Credentials - Separate login credentials for each entity that will need access to the database, and avoid creating a single “admin” login that every user shares.
Supporting In-Database and Centralized User Management - care is taken to ensure that only the minimal set of privileges is provided.
Control Access to Sensitive Data - Sensitive information, such as personally identifiable data, is restricted to users who have been given adequate training and appropriate security clearance.
We use block level encryption to ensure that all CareerBot data is encrypted whenever it is in transit or at rest.
Our data encryption procedures ensure that only authorised entities are able read our data, and that our data will be protected in the event that eavesdroppers or hackers gain access to the server, network or database.
The protection and encryption of data stored by CareerBot for its users is ensured through the following guidelines and processes:
All physical access to data centers by AWS employees is logged and audited routinely, as per the guidance and certification provided athttp://aws.amazon.com/security/
Further information about the AWS global infrastructure can be viewed here:https://aws.amazon.com/about-aws/global-infrastructure/. In addition to the physical infrastructure safeguards that are in place with AWS, the actual configuration of the platform architecture is monitored by the AWS Config service; this service reports on any configuration changes and provides a detailed audit trail of actions taken relating to the underlying system architecture. In addition any changes are sent via alerts to selected staff members to act upon.
CareerBot will conduct a periodic internal review at least once a year to evaluate our security program. This review is intended as a comprehensive risk assessment to identify all of the reasonably foreseeable internal and external threats to the security, confidentiality, and integrity of Personal Data.
We leverage data from AWS Trusted Advisor and use the Audity Security Checklist provided by AWS (https://d0.awsstatic.com/whitepapers/compliance/AWS_Auditing_Security_Checklist.pdf ) and where relevant, we will adjust our security programme in line with recommendations based on:
In the event of a disaster, we employ and leverage a number of resources and features to ensure business continuity. This enables to significantly minimize any potential impact on your data, our system, and our overall business operations. Backups can be recovered on any cluster on which they are taken.
CareerBot higher-level services, such as Amazon Simple Storage Service (S3), and Amazon Elastic Load Balancing (ELB), have been built with fault tolerance and high availability in mind. Services that provide basic infrastructure, such as Amazon Elastic Compute Cloud (EC2) and Amazon Elastic Block Store (EBS), provide specific features, such as availability zones, elastic IP addresses, and snapshots, that a fault-tolerant and highly available system must take advantage of and use correctly. For reference seehttp://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_ftha_04.pdf
The failover algorithms implemented by Amazon Route 53 are designed not only to route traffic to endpoints that are healthy, but also to help avoid making disaster scenarios worse due to misconfigured health checks and applications, endpoint overloads, and partition failures. The CareerBot clusters for Mongo and Deis will bring up new nodes in event of failed node.
Our application is distributed across multiple availability zones, which provides us the ability to remain resilient in the face of most failure modes, including natural disasters or system failures, such as by moving between availability zones in the event of a failed node.
The continuous copying of data from a database in order to maintain a second version of the database, usually for disaster recovery purposes.
CareerBot uses services and features that support data migration and durable storage, because they enable us to restore backed-up, critical data to secure cloud storage. The essential infrastructure pieces include DNS, networking features, and various Amazon Elastic Compute Cloud (Amazon EC2).
We leverage Simple Storage Service (Amazon S3) to provide a highly durable storage infrastructure designed for mission critical and primary data storage. Objects are redundantly stored on multiple devices across multiple facilities within a region, designed to provide a durability of 99.999999999% (11 9s). We provide further protection for data retention and archiving through versioning in Amazon S3, AWS multi-factor authentication (AWS MFA), bucket policies, and AWS Identity and Access Management (IAM)
All data is transferred using the HTTPS protocol which provides end to end encryption. HTTPS uses the SSL/TLS protocol, which uses public-key cryptography to prevent eavesdropping, tampering, and forgery. We use a highly available and scalable DNS service and deliver content to our end users with low latency at high data transfer speeds with a content delivery web service.
Through Amazon Elastic Load Balancing access logs, we obtain information about each HTTP and TCP request processed by our load balancer. This includes the IP address and port of the requesting client, the backend IP address of the instance that processed the request, the size of the request and response, and the actual request line from the client (for example, GET http://www.example.com: 80/HTTP/1.1). All requests sent to the load balancer are logged, including requests that never made it to back-end instances.
When servers are decommissioned their associated disks are deleted (destroyed). Database disks are encrypted AWS Elastic Block Store volumes (EBS). Server disks are non-encrypted EBS volumes running Docker containers and as such never hold data.
When a storage device has reached the end of its useful life, our procedures include a decommissioning process that is designed to prevent customer data from being exposed to unauthorized individuals. We uses the techniques detailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual “) or NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process. All decommissioned magnetic storage devices are degaussed and physically destroyed in accordance with industry-standard practices.
We have internal controls over data access and authorisation to ensure that vendors receive only data required to supply services and the data transfer process is secure
Prior to selecting a 3rd party provider, CareerBot will specify CIA requirements for data as per the guidelines in the CIA section of this document
We will identify the control measures in place at the vendor that are designed to meet CIA requirements
We will assess whether the vendor is capable of meeting these selection requirements going forward, and will ensure that these are guaranteed by contractual requirements.
We will monitor the access control to and CareerBot data, and will maintain reviews for the configuration of our custom Identity and Access management (IAM) policy for the AWS keys that we use for any 3rd party service providers
Effective: 15th August 2016