Security in the first place
New GDPR-compliant personal data protection
We are always ready for changes in legislation, and that includes the new General Data Protection Regulation (GDPR). So how are we going to help you ease into the GDPR and how will it affect your work in Teamio?
Tech Specs & Security
Teamio is a fully modular, multi-tenant web-based recruitment workflow management solution.
It facilitates effective info sharing between companies and job seekers. Helps to maintain a recruitment process. Looks for candidates who fit the needs, issues job positions, keeps communication history with involved job applicants, manages job tenders and interviews. And much more. Of course in compliance with EU legislation. It’ s secure. Effective. Comfortable. It’s Teamio.
Software as a Service
Teamio is run as a SaaS (Software as a Service), which simply means:
- it is operated in a private cloud
- it is located at multiple data centers due to high availability
- LMC as an Application Service Provider (ASP) ensures continuous operation
- User data can be accessed only by a restrictive group of authorized staff.
- Concerned to sensitive data, security measures always include a full track of operations and activities associated with the operator identity.
Segregation of Roles
We recognize the following roles from the very nature of the user request handling:
- CustomerCare [40+] - receives customer requirements and try to process (in the first-line)
- Support [20+] - technical support staff (second-line of processing pipeline)
- Business [20+] - to solve functional requirements for products, campaigns, etc. (3rd line)
- System administration [10+] - to maintain tech resources (servers, backups...)
Above described roles have to (or potentially may have) access to a part/complete user data. Indicative numbers of staffing may helps to depict the size of support inevitably accessing sensitive data.
- User data protection is ensured in accordance with EU legislation (notably GDPR).
- User access is provided by encrypted connection - only
- Non-production (development / testing) environment separated out of production-grade data
- User data confined within production, non-production uses synthetic/obfuscated data corpus
- Security-relevant activities on production systems are monitored, logged and timely evaluated
- Activation of components/services (per user request) is always validated at LMC side
- Teamio solution is continuously developed and tested (functionality and security together)
- Updates and patches are released on a daily basis (or faster in case of a serious trouble)
Support requests are collected and registered using HelpDesk and processed by Customer Care in the shortest possible time, obviously during common business hours (Mon-Fri, 08-17 CET).
Compatibility & Minimum Requirements
- Teamio is available through the common Internet connection (speed typical for CDMA/ EDGE or UMTS mobile connection is far enough)
- Web interface is compatible with major browsers (Firefox, Chrome, MS Internet Explorer 11 and above)
Data in Transit
Access to (and from, applicable in both directions) Teamio solution is limited to secured web access (common end-user interaction) and the system maintenance (encrypted SSH protocol with key authentication). Anything else is firewalled out.
Web access allows HTTPS (encrypted) connections only.
- Enforces TLS 1.2 protocol
- The X509v3 SSL certificate is signed by trusted CAs (accepted by all major web browsers)
- The client certificate is not required
Separation of individual client sessions is ensured by the cookie mechanism.
All production system traffic in both directions is filtered and only HTTPS for user interaction and encrypted access (SSH protocol with key authentication) for maintenance / updating of the application is enabled.
User Authentication (Sign-in) involves a single-factor form -based (user/password) mechanism.
User accounts are treated as individual (LMC strongly discourage to share accounts among multiple users).
The plain text password is never stored and is present only in-memory at the time of user login in.
- Passwords are stored in the back-end database in the form of so-called fingerprints („salted“ hashes with the salt generated individually per account).
- Currently we use PBKDF2 framework and continually improve hash function parameters (now seamlessly migrate from HMAC-SHA1 to HMAC-SHA256) and increase number of iteration cycles (by two magnitudes) to reflect the common security state-of-art status.
Logon parameters must meet password policy (complexity).
- The username must be a unique identifier (an email address can also be used)
- The minimum forced password length is set to 6 characters
- A combination of at least two character sets (digits, upper / lower case characters, special characters)
- Trivial passwords (numeric / character series, eg 123456, abcdef) are not allowed
It is enforced to change the initial password (after setting up the user / password setting by the operator) at the next logon.
The number of attempts to log in to the system under a particular user identity is dynamically restricted to protect against brute-force password attacks (e.g. five unsuccessful attempts to log-in blocks the user account for an hour).
Particular user actions are authorized based on predefined role granted to the individual user. Self-care role management is administered by mandated users of each tenant (registered company space) individually.
The following user roles are defined (availability depends on Teamio edition):
- HR Manager - role has an access to the all registered job positions & to all responses to these positions. There is privilege to change company profile settings (templates, headers, etc.). Can be (optionally) set to any combination of the following rights:
- Access to service statistics
- Access to recruitment statistics
- Access to account credit administration
- User account management
- Recruiter - role has an access only to own registered job positions & relevant responses. There is no right to change company profile settings. Role has privilege to:
- Access to shared pool of applicants including access to other recruiter’s (within the tenant) candidates who have been pre-selected, interviewed, or joined.
- Access to incoming messages (if the edition contains Inbox service).
- Recruiter (who can not spend) - varies only by blocking credits (e.g. payment by credit for posting, uncovering a CV in a database, etc.)
- Line Manager - role has access only to the candidates for job positions shared to. There is no right to change company profile settings or work with a job position. Role has privilege to:
- Add comments
- Invite applicants to interviews
Data at Rest
Teamio code runs sandboxed in WildFly (JBoss) application servers (because written in Java) built-up on the top of hardened Linux operating systems.
All components run virtualized (OpenStack) on the private cloud solution due to high-availability and fast disaster recovery options.
Main portion of data are kept within the High Availability Disaster Recovery database back-end (IBM DB2 UDB v10.5.x). The helper applications use the PostgreSQL database cluster (v 9.5). Data are continuously synchronized and mirrored to multiple locations, also backup is made on the regular basis.
Backup takes place according to a defined plan (retention is implicitly set for 14 days):
- Transaction log backup is ongoing (to ensure data recovery within 8 hours far from the crash)
- Snapshot of the cloud platform takes place daily
- Full data backup data runs weekly
Multi-level backup system is used:
- Online replication of data to multiple locations
- Backup systems of cloud providers
- Internal backup systems (Networker, Bareos)
Monitoring & Supervision
The operations monitoring runs continuously (24x7).
The status is supervised (and any issues notified) daily (07-22 CET):
- external monitoring services (Pingdom) together with internal systems (ICINGA) are employed to check the status
The development, integration and testing environments are fully virtualized and run on a private cloud platform. The environments are logically split (by firewalling). Access rights to different environments are different. Mentioned again, the production environment is fully separated (physically) from non-production environments.
Planning, development and testing of any updates/new releases of Teamio takes place in the framework of agile development (We cycle using SCRUM’s Sprints).
All used components (including in-house developed) are tested for stability, availability, and security prior to production deployment, so that vendor / platform manufacturer support is always maintained.
In the case of identified security flaws, updates (patches/fixes) are applied after testing in the shortest possible time.
Testing takes place in a continuous and multi-level development:
- Prior to accepting any change in the source code, a developers review (local Lint and four-eye control principle) takes place.
- In the framework of code quality control, static code analysis is performed (using the code review instruments, e.g. SonarQube).
- The application is further controlled (still pre-production) by dynamic analysis (using specialized penetration test tools, e.g. ZAProxy, Burp Suite).
- Regular (annual) independent assessment of application security (through penetration testing) is also carried out by a specialized third party.
Passed tests will open release management process to move the new code to production. This is fully automated (no hand-intervention allowed) deployment process with full audit track (to ensure rollback to the last good version, when deployment fails).
Audit records are taken as a track of all significant activities of the users. Audit (logging) is layered, descending from the application level to the system as follows:
- History (of user activities)
- Business log
- Security log
- Application log
- System log
Each record is tied with the timestamp and the user identity. Records are kept in the log(s) for the period specified for particular audit track.
Detailed info about user activities (e.g. reasons for refusal, "brand" from which the response was delivered, etc.), currently comes from the modules:
- Positions Management
- Candidates Management
Detailed info about particular user actions/automated actions of the system (over 700 different types of events are currently registered - operations with positions, job applicants, service orders, etc).
Info about security-related actions (e.g. authentication result etc).
Low-level application events:
- HTTP requests
- Database accesses
- Performance measurement info
- Application errors