We use several components to optimize each part of the Blackchair platform. For example, we use MongoDB, Java Spring Framework, Javascript (Client + NodeJS), RabbitMQ, and for our relational database systems (RDBMS), we use Oracle and MSSQL.
The Blackchair solution can be customized to run on the cloud, on-premise or a combination of both, depending on how you want to run the setup.
Our clients require consistent, high-quality performance, so we work with only the best cloud providers - Amazon, Google, and Microsoft
We have researched the best security practices recommended by Amazon, Google, and Microsoft and built our data policies around these security practices.
We are not restricted to any country, geography or data center; we operate based on our client's requirements.
Yes, on-premise is an option available for clients who want it, alongside our cloud deployment offerings.
Our most recent code review took place on 20th September 2020 .
Our penetration test assessments follow methdologies like ISSAF and PTES.
No, Blackchair does not require or carry any personal company data for services rendered.
We follow the purview of the client's administrator controls. However, it is important to repeat that we do not request any sensitive data from our clients.
No, we do not have any access to personal or sensitive data because we do not request that kind of information from our clients.
No, we do not request any sensitive data or store it in hard or soft copy.
We do not store any customer data.
Yes, we have a strict internal password policy.
Yes, at least 7 characters with one uppercase, lowercase and a special unicode character.
We encrypt passwords using both Advanced Encryption Standard (AES) and Rijndael encryption algorithm.
If the system runs on-premise access, then production systems are accessible through the desktop share session supervised by your staff. If the system runs in the cloud, then access is only possible via desktop share session supervised by staff. However, If the system runs in cloud managed by Blackchair, we will connect to the system for support activities only.
No, third-party vendors cannot access customer systems and information.
We review and update our information security policies once a year.
We have security management support and a security management forum to help take action on security risks.
Yes, our policies are in line with industry standards like ISO-27001, NIST Cybersecurity Framework, ISO-22307, and CoBIT.
We have a policy exception process to better support our clients.
Yes, we follow a formal disciplinary or sanction process for employees who violate security procedures.
Yes, all our employees - including third-party contractors - are subject to background verification.
Yes, all personnel must sign a confidentiality agreements as part of their contract.
Yes, all employees need to sign a user policy.
Following a change in employment status or termination we include timely revocation of access and return of assets.
Our network security testing is performed by third-party organizations.
Briefly describe your network vulnerability management procedures and processes?
What is your timeframe for patching critical vulnerabilities?
Our third-party penetration testers use all the tools necessary to conduct a detailed, comprehensive test.
Yes, we have processes and procedures in place for application vulnerability management. Our third-party penetration testers must follow these procedures when conducting an application vulnerability test.
Our third-party penetration testers use all the tools necessary when managing application vulnerabilities.
Not applicable.
We have several systems in place to help mitigate the different attacks on web applications. Some of the procedures include, but are not limited to, input validation, proxied DB access, parameterized queries, and escaping.
Yes, we have uniformly configured the hosts.
Yes, we make sure that any changes made to the production environment are reviewed by two engineers.
Yes, all security events - authentication events, SSH session commands, privilege elevations - are production logged.
No, we do not make changes to the network configuration regularly.
Yes, any network traffic going through the production infrastructure are cryptographically encrypted connections like TLS, VPN, IPSEC, etc
We use the AES-128 framework cyptographic frameworks to store passwords.
We use several procedures to monitor potential vulnerabilities that may affect service. Some of these procedures include static code analysis and subscribing to updates in third-party libraries.
We maintain a log of all security events. When an event is flagged we will log in and conduct an internal review.
Yes, we have a Security Response Program. When a security breach occurs, the incident is logged in our incident management system. We will then investigate the breach and take remedial action, if necessary.
We have an incident response plan in place. We simulate security incidents and study how the incident management team responded.
Yes, we have prepared a formal service level agreement, specifically for incident responses.
In the event of a security breach, our incident management system will automatically notify customers to minimize downtime when giving out alerts.
Yes.
A set of tools is used to perform static code analysis securely. In case of vurnerabilitiy the results will be selected for further analysis, and broken down by source code language, issue type, and priority.
Yes, the threat modeling is part of our agile process. When the system changes, we measure the security impact those changes might have during a sprint/feature build.
Yes, we train developers in Secure Coding Practices, especially those who are doing code reviews, architecture analysis, and design reviews.
A set of tools is used to perform static code analysis securely. In case of vurnerabilitiy the results will be selected for further analysis, and broken down by source code language, issue type, and priority.
We have a pre-production system to validate build artifacts for promotion and production.
Yes, we maintain a bill of materials for third-party libraries or code.
We monitor vulnerabilities using SonarQube. We use the platform as an inspection engine to find vulnerabilities, bugs, and code smells. We also use SonarQube to track code complexity, duplication, and unit test coverage.
Yes, we contract third-parties on certain projects.
We perform different security reviews on custom-built software, including code reviews, QA, mixed team development, and in-house testing.
The method of authenticating users changes based on whether the system is integrated into the cloud or in on-premise windows. If the system is installed on-premise, then we use pass-through authentication. However, if the system is installed on the cloud, we utilize an internal authentication process. This applies for both public and private cloud platforms, the only exception being when we use third-party authentication.
Yes, admin users can enforce multi-factor authentication provided they have purchased the option.
We do not store any customer data.
We do not store any customer data.
Yes, applications provide a sandbox environment to customers for testing provided they have purchased the option.
Our internal audits cover system performance, security incidents, and customer raised incidents. We conduct the audit on a quarterly basis.
We follow the regulations associated with ISO 27001 and 27701.
We are in the process of obtaining our certifications.
Automate contact center capabilities, free up resources, and achieve cloud migration excellence.