Questions and answers for enterprise customers and security teams
Last updated
This document addresses advanced topics on Veza platform security. These include questions about authentication, encryption and key management, access controls, network security, and other procedures ensuring the security of our SaaS and cloud-premise deployments.
Veza's SaaS production environment runs on AWS. Our architecture emphasizes security, scalability, and efficient resource management with a multi-VPC structure. Key components include Amazon EKS for container orchestration, AWS WAF for web application security, and integrated monitoring tools.
What authentication methods does Veza support?
Interactive Users: Local User Accounts, SAML Single Sign-On, OpenID Connect (Early Access).
Non-Interactive Access: API Keys
For SAML-based authentication, do you handle user-provided XML? Do you validate XML to protect from malformed XML?
Veza accepts user-provided XML for SAML configuration. We validate the input to protect against malformed XML input.
For API authentication, do you support access tokens instead of API keys? If so, what tokens are supported?
Not at present.
Do you check if MFA is performed on the IdP side for single sign-on?
No. The desire that MFA is performed for session creation can be configured via ACR Values with OpenID Connect (OIDC). The configuration is specific your identity provider and the IdP configuration. It does not guarantee that the MFA was performed.
How long are access tokens valid? Is the duration of access tokens configurable?
The valid duration of regular session/access tokens is 20 hours (non-configurable). Session tokens must refresh every 15 minutes or will expire.
API keys do not expire.
The customer can configure session idle time on the Veza Sign-in Settings page.
Do you use cookies? How are your cookies defined?
Yes. We use cookies, including a session token, for session tracking. We assign our cookies as HTTPOnly and Secure.
Are all human users accessing Veza’s EKS backend required to use MFA?
All access to Veza's EKS backend is limited to a select few SRE individuals and requires multiple layers of MFA.
How does Veza avoid spoofing attacks, where an attacker impersonates the Veza application to gain unauthorized access?
Veza can prevent spoofing attacks. Here are the details:
Using a single SAML-based IdP (e.g., Okta) as the SSO provider.
Customers can disable local accounts.
Customers can allow a Super Admin user, managed by the customer, access for break-glass situations. This user's activity can be audited for any actions the user performs.
How does in-transit and at-rest encryption for data ingested into Veza work?
For in-transit data, we support TLS 1.3 (default) with ECDSA, RSA, and TLS 1.2; for at-rest data encryption, we use AES-256-GCM. We use GPG to encrypt the secrets for all integrations.
Encryption and storage: All storage is encrypted at rest (EBS Volumes, S3 buckets, Database storage).
How are keys managed?
We use AWS KMS to manage and secure keys.
Does Veza implement chains of trust?
We use AWS Certificate Manager (ACM) to issue our public TLS certificates. Internally, we use our own certificate authority (CA) and self-signed certificates for mTLS between services to prevent a supply chain compromise of internal communications security.
How are keys rotated? How often are keys rotated?
We rotate AWS and Veza KMS keys yearly
Certificates are rotated every 6 months
How is communication between the Insight Point and Veza platform secured?
All communication between the Veza Platform and the Insight Point is performed via TLS (Transport Layer Security). All requests are also signed to provide data authenticity and integrity.
Access Control Infrastructure: At the infrastructure level (Kubernetes cluster, tenant), what access control does Veza enforce to ensure infrastructure security?
Only specific personnel have access to production environments.
We perform quarterly access reviews to audit production environment access.
Authorized personnel can only access customer-managed clusters through a designated bastion host.
Bastion host activities are monitored and audited via SysDig.
We require SSO and MFA for all production systems.
All cluster traffic is encrypted.
All internal communications use mTLS.
All access is tracked in audit logs.
Is the network where customer data resides segmented from other networks, with only necessary ports and protocols allowed? Does Veza disable Public/Remote Access to EKS Cluster Endpoints?
Network policies isolate the tenant network. All external (incoming and outgoing) traffic is limited to the components that need it.
EKS access is only enabled from the Bastion host and limited to access from the private VPC. Public access is disabled.
Firewall and Intrusion Prevention: Does Veza Deploy Web Application Firewalls (WAFs) and intrusion prevention systems (IPS) to detect and block malicious traffic? Does Veza Regularly update signatures and rules? Is remote access to EKS cluster node groups disabled from the internet?
All external traffic must go through AWS WAF.
VPC traffic is analyzed and scanned to detect anomalies.
Signatures are updated automatically.
We restrict EKS node access to the private VPC from the bastion host.
Does Veza routinely review accounts with access to production tenants and the EKS backend to ensure no stale or unauthorized accounts exist? Do you ensure that Cluster Node Group IAM Policies are maintained? Is the worker node IAM user for cluster EKS Namespaces segmented?
Veza performs regular quarterly access reviews.
Veza maintains least-privilege IAM policies/permissions.
IAM policy integrity is maintained by regularly reconciling infrastructure-as-code configured policy against the running policy.
Tenants have strong access isolation through the IAM policy and Kubernetes Role-Based Access Controls (RBAC).
Do you support multi-tenancy? If so, can you describe how accesses are isolated among tenants?
Yes, Veza supports multi-tenancy:
Each tenant is an isolated deployment in a separate namespace
Tenant data and permissions are isolated, with controls to prevent cross-tenant data access.
Do you support RBAC for customer users in the same tenant? What roles are supported? What isolation is provided?
Veza supports four static roles:
Administrator (user management, provider management, and system settings)
Operator (access to all platform capabilities, like reports, rules, access workflows, etc.)
Access Reviewer (a specialized role for participating in access reviews)
Two additional roles are available in Early Access:
Viewer (Subset of operator role, preventing any changes or modifications)
Re-assigner (Subset of operator role, allowing re-assignment of any result in an Access Review)
Veza also supports Teams to limit access to specific integrations: users in a Team can only see data for integrations assigned to that Team.
How does Veza avoid repudiation (the inability to prove the occurrence of events or actions leading to disputes)?
Veza implements logging and monitoring to maintain an immutable record of all service activity:
Logs include the timestamp, the pod name that initiates the call, and all other operation details (which function, which line, etc.)
Logs are protected against tampering and stored immutably
We forward logs using TLS to our logging utility.
AWS CloudTrail is also used to monitor and audit access to AWS assets through the command line or console.
How does Veza avoid Denial of Services for supported integrations?
Veza implements rate limiting for all integrations.
Veza also monitors and allocates resources appropriately to handle spikes:
Default extraction intervals vary depending on the integration and can vary from 1 hour to 24 hours depending on target data source capabilities. Customers may set this to a larger time interval as desired.
Our EKS backend uses auto-scaling groups to achieve elasticity based on usage.
Resource usage is monitored and alerted on CPU, memory, and storage thresholds.
How does Veza avoid exploiting vulnerabilities to gain elevated privileges?
Veza uses strict permissions to ensure we use minimum necessary read permissions for each integration.
We audit Veza permissions and roles regularly.
Vulnerability Assessment and Patching:
Veza EKS backend must undergo regular vulnerability assessments.
Veza performs regular ECR image scans and patch images.
Veza assesses discovered vulnerabilities and patches them per CISA standards.
Veza automatically scans code dependencies continuously.
Veza keeps all system components up-to-date with a regular upgrade cadence.
Veza uses images with minimal dependencies necessary for each service.
How does Veza define data retention policies for metadata stored in the EKS backend and ensure secure deletion methods that comply with industry standards (e.g., NIST's Guidelines for Media Sanitization)?
Veza deletes all customer-related authorization metadata within 30 days of service termination, along with any reports.
All metadata is stored in encrypted S3 buckets and encrypted EBS volumes. AWS deletion policies and procedures comply with NIST guidelines for media sanitization.
Anomaly Detection: Does Veza implement behavioral analytics to detect unusual patterns in data access or system behavior, which might indicate a breach or other security incident? Does Veza maintain a detailed incident response plan and conduct regular threat isolation and mitigation drills?
Veza uses behavioral analytics to detect anomalies in CloudTrail and VPC flow logs.
Incident response plans are created and routinely reviewed.
We perform incident response drills at least annually.
Continuous Monitoring: Does Veza implement solutions like Security Information and Event Management (SIEM) systems to gather, correlate, and analyze logs from all parts of the environment? Does Veza ensure CIS controls are met for the EKS and AWS resources used to store and manage customer data? Is a CSPM used to track CIS controls?
We use GuardDuty to continuously monitor Production AWS accounts, including Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Elastic Kubernetes Service (Amazon EKS) clusters, and data stored in Amazon Simple Storage Service (Amazon S3) for malicious activity.
We use Sysdig to continuously monitor bastion host activities. Only authorized Veza personnel can use the host to access EKS and related AWS resources for the production AWS accounts.
