Splunk On-Call Security FAQ
Overview
At Splunk On-Call, we’ve always recognized the sensitive nature of alert and monitoring data. While different organizations classify their alert data differently, we treat all data sent to us from a customer as sensitive and confidential. That said, some organizations may generate alert data that they consider highly confidential or of a critical sensitivity. Such organizations should take the time to ensure that they’re comfortable with the data being sent into the Splunk On-Call platform.
The customer is in the driver’s seat!
Splunk On-Call receives data through a variety of mechanisms: email, webhook, or native integration. Our native integrations have methods for choosing which alert fields get passed to Splunk On-Call, and our APIs can be used for alert delivery when a completely custom alert payload is required. This means that the customer is ultimately in control of what data goes into their Splunk On-Call account.
Splunk On-Call is a cloud-native SaaS-based platform operating in state-of-the-art cloud facilities using industry-standard TLS 1.2 or better encryption for data in transit. Splunk On-Call encrypts all customer data at rest using AES 256-bit encryption, anywhere that customer data is persisted to disk.
For our production, staging and development environments, Splunk On-Call partners with top-tier cloud providers whose data centers carry multiple certifications and attestations, including FedRAMP, PCI-DSS and ISO 27001:2013. These certifications demonstrate that our cloud partners take an aggressive stance toward physical security, including the use of video surveillance, on-site security staff, and advanced physical access control systems.
At our offices around the world, Splunk enforces strict physical security policies to ensure that only authorized personnel have access to our facilities. ID badges are required for all employers, contractors and visitors, and sensitive areas use additional factors to control access. The Splunk Global Security team monitors our facilities and keeps our staff informed in case of an event affecting site security, such as severe weather, viral outbreaks, or active security incidents.
Our SaaS infrastructure is managed for security first, including the use of hardened operating systems that are regularly updated and tightly managed by provisioning and configuration management frameworks. The Splunk Global Security team continuously scans the infrastructure for vulnerabilities, which are mitigated according to well-defined internal SLAs.
The Splunk Product Security team works with our software engineers to continuously evaluate Splunk On-Call with advanced SAST and DAST tools, helping identify potential vulnerabilities, coding errors, and licensing issues in our codebase as well as any 3rd party and OSS code we use in our stack. A secure software development life cycle is part of Splunk’s culture, including the use of threat modeling exercises, review of all code before it is pushed to production, and ongoing secure coding training for our engineers.
Third party penetration tests validate our security practices on a regular cadence, using a variety of different vendors from test-to-test, for maximum coverage.
Our in-depth approach to network security includes ACLs and stateful firewalls at the node, network, and edge boundaries. We are protected at layer 7 with WAF and DDoS mitigation technology. Infrastructure-as-code frameworks define our network structure and protection layers, ensuring that any changes are reviewed and approved, and unintended changes are detected and rolled-back. Network infrastructure is scoped-in to our regular 3rd party penetration tests, and any misconfigurations or vulnerabilities are mitigated according to the same strict internal security SLAs that govern our codebase and nodes.
We back up customer data on a daily basis to an offsite location and test the backups on a regular cadence.
All employees are granted access on a least privilege basis, and access is reviewed at least quarterly. Employees do not make any configuration changes to your account without prior notification and approval.
VictorOps uses Zuora to process customer payments. Zuora is a well-known and trusted Level 1 PCI DSS Compliant Service Provider.
Splunk is certified under the EU-U.S. and Swiss-U.S. Privacy Shield Frameworks. We are committed to Privacy Shield Principles, including considerations for onward transfer. Splunk processes Personal Data outside of the EEA (and the U.K.) including in the United States. Splunk will notify you if it can no longer meet its obligations to provide the same level of protection as is required by the Privacy Shield Principles.
Splunk conducts criminal background checks on all employees prior to hire, to the extent allowed under applicable law.
Users or account administrators will add their information for Splunk On-Call to notify (via email, text/sms, phone call, or push notification) should the service need to. This PII information typically includes first name, last name, email addresses, and a variety of phone numbers.
As a cloud-based service, the concern that Splunk On-Call may expose customers’ data can be mitigated due to the fact that each customer controls the information being sent to Splunk On-Call. This rarely includes PII or other types of sensitive information and steps can be taken to ensure information is not provided in alerts sent to Splunk On-Call (see What Data does Splunk On-Call collect?) All of your data in Splunk On-Call is encrypted in transit and at rest.
If needed, customers may request that their organizations data be purged from VictorOps’ databases. We comply with GDPR data subject requests as required by law.
Splunk On-Call will not publicly announce security vulnerabilities until fixes are publicly available. In the event of a breach, Splunk may notify affected customers prior to breach containment to recommend possible mitigations. Splunk will not release the exact details of vulnerabilities.