Security
System Security
-
What security certifications are involved with VoiceConsole SaaS deployment?
The infrastructure layer of VoiceConsole SaaS deployment undergoes regular third party audits to satisfy and maintain several compliance certifications including ISO/IEC 27001, ISO 62443, and NIS2. Additionally, the security process employed is ISASecure 52443 Security Development LifeCycle certified.
-
Is there a choice of multi-tenant or single tenant structure?
VoiceConsole is a hybrid-tenant implementation in which each customer's database is single-tenant, but customers can benefit from several general shared services which are multi-tenant. Given their nature, these shared resources are used by multiple customers to help optimize VoiceConsole while keeping each customers’ data contained, secure, and invisible to other tenants. No VoiceConsole SaaS deployment customer has access to any other customer's data.
-
How is my sensitive Wi-Fi network information secured?
Both VoiceConsole On Prem and SaaS deployments do not control wireless security. Wi-Fi security should be handled directly with the service provider.
If customers use Extensible Authentication Protocol (EAP) for wireless security, those credentials are always encrypted. If customers use a plain-text Wireless Equivalent Privacy (WEP) or Wi-Fi Protected Access (WPA) key, credentials can be encrypted by enabling the security salt option.
-
What intrusion penetration and detection systems are in place?
Checkpoint firewalls are implemented for protection from intrusions.
-
How are Security Events handled?
Security Events generated by Microsoft Defender for Cloud (enabled for all Azure Subscriptions) are forwarded to Splunk where Honeywell’s Security Operation Center monitors and investigates those security events.
-
Can you share more information on network logging and monitoring?
Virtual Network Communication: Azure 2.0 model directs all traffic between application tiers (subnets) to route through Honeywell Global Security’s Managed Checkpoint Firewall using user-defined routes in subnet route tables. Once this process is complete, logging and monitoring has been established.
Azure Network Security Groups: Network Security Group flow logs are enabled to record information about ingress and egress IP traffic through a network security group.
Data and Log Security
-
Where are the data centers?
Data Centers are located in Virginia for Eastern USA and in California for Western USA.
EU Data Centers are located in Ireland and The Netherlands.
-
How do we control, record, and log access?
For controlling access, Admin users can create roles for users to manage what they have access to via User Accounts.
User accounts and roles are documented in VoiceConsole Help: Users Help | Roles Help
For logging access support, VoiceConsole Online Help has information on Audit functionality and Logging support.
-
What is the process to inform customers when security is at risk?
If security is at risk, the standard Honeywell security and privacy practices are employed. More info can be found here regarding standard processes.
-
Is there an option to connect to the Saas services if customers have VoiceConsole On Prem deployment?
Yes, if customers have a VoiceConsole On Prem deployment, they can choose to connect to the SaaS cloud to access additional cloud-based services.
-
Can customers choose which vendor provides the deployment’s infrastructure?
Currently, Microsoft Azure is the only infrastructure platform available for the VoiceConsole SaaS deployment.
-
What role is Honeywell responsible for?
Honeywell maintains the cloud portion of the implementation which includes the server and database as well as the VoiceConsole SaaS deployment software.
-
What roles are customers responsible for?
The customer is responsible for maintaining the Talkman devices and installed software along with the Wi-Fi network and Internet connection.
-
Is it necessary to VPN in to access the VoiceConsole SaaS deployment?
The VoiceConsole SaaS application is public-facing and does not require VPN.
-
Can more detail be provided on communication method?
Currently VoiceConsole SaaS deployment creates device profiles to using Secure Sockets Layer (SSL) communications between VoiceConsole and Honeywell Voice devices. This means only secured device communication protocols are used within VoiceConsole.
-
How is the data stored in the cloud protected? And who can access the data?
Each customer is provided a secure link and login information for their instance of VoiceConsole SaaS deployment, which is secured using an in-depth defense methodology. Multiple layers of defense are implemented, ranging from active monitoring to stringent encryption ciphers for data in-motion, in processing, and at rest. This ensures a secure channel for data exchange between the Honeywell Cloud and the user's device. As Honeywell VoiceConsole SaaS deployment segregates tenant data logically, each customer can view and interact with only their own data and reports.
Data is stored in the Azure Cloud SQL Database. The Database and Azure File storage system are both automatically protected by Service-side encryption (SSE) and Transparent data encryption (TDE) per Azure’s processes. All stored data is encrypted at the tenant level using keys that are unique to each organization. All encryption keys are securely stored in a vault solution separate from encrypted data. All customer data is segmented from the Honeywell network and kept in its own production instance. There is no interaction with development systems or infrastructure, which are also kept separate.
-
What VoiceCatalyst versions are needed in the event of VoiceConsole upgrades?
Current compatible VoiceCatalyst versions can be found here.
-
Can customers purchase additional deployment environments for non-production test environments or additional regions due to device limits or country locations?
Yes, customers can purchase additional environments so long as minimum license requirements are met.
-
Can two-factor authentication be implemented with VoiceConsole SaaS deployment?
Two-factor and/or multi-factor authentication is enabled by default but implemented via a risk-based policy which is structured to detect abnormal and/or suspicious factors.