This article discusses how Kentik ensures the security of its systems and of the data entrusted to us by customers. These topics are covered in the following topics:
Kentik takes extremely seriously the security of the data collected for, sent to, and ingested by our data platform. At the highest level, our approach can be summed up as follows:
- All data sent to us can be encrypted in transit.
- All access to our system is protected.
- No customer has access to the data of another customer.
The precautions outlined above enable us to store data on our internal datastore unencrypted, which in turn enables us to achieve exceptional performance for ingestion and querying.
The following table shows in somewhat greater detail how the system and the data are protected:
|Data in transit
||- All communication to and from Kentik.com can be limited to HTTPS.
- SNMP supports encrypted and unencrypted modes.
- UDP flow is unencrypted by design, though Kentik offers methods to encrypt it.
|Data on disk
||- Data is not currently stored in an encrypted form on disk.
- All client communication with the Kentik system is via SSL.
||- Each user has completely independent UI sessions.
- Each customer has a separate logical database.
- All users within a given customer share the same database.
- No user can alter tables.
- Each password is stored as a salted hash, with unique salt used for each user.
- Data filters can be applied on a per-user level.
Most Kentik customers use the Kentik Detect service — which has been architected to provide multi-factored scalability, reliability, and security — via our multi-tenant SaaS platform. The answers provided in the following FAQ topics — many of which apply as well to on-premises deployment — address how Kentik Technologies handles security concerns that commonly arise in relation to SaaS deployment:
- Does Kentik hold SSAE 16 SOC 2 / ISAE3402 / ISO27001 or similar third party audit reports?
All stored data is in a SOC 2-compliant data center.
- Has Kentik undergone a vulnerability assessment or penetration test of its production environment within the past six months?
Yes. We have addressed all valid security findings, and have systems and processes in place to audit/ mitigate any future findings.
- What is Kentik’s process for security event monitoring and notification?
Processes and logs are used to watch for possible security breaches, with internal monitoring via dashboards, pager alerting, and log viewing. Notifications are optionally sent by email to the address associated with user login account. Our general-purpose support address (firstname.lastname@example.org) is used for all inbound service availability inquiries and reports.
- What notification and escalation processes exist in case of a security event?
Were a security breach to occur, all affected customers are notified using email and a message banner in the Kentik portal.
- Is Kentik insured by a 3rd party for security/operational losses?
- How is security supported within Kentik’s company culture?
Security is a first class citizen and an integral part of our culture. Discussion of the importance of security, and the procedures we use to support it, is part of the applicant screening process for all positions, and security considerations are built into the design and review process across our platform.
- Are the hosting facilities SOC 1 and 2 Certified?
Yes. Our hosting centers are SOC 1 and 2 compliant.
- Is Kentik’s service PCI compliant?
PCI certification is not currently relevant to Kentik’s services because Kentik does not receive or store any PCI-restricted data from customer networks.
- Is Kentik’s service HIPAA compliant?
HIPAA compliance is not currently relevant to Kentik’s services because Kentik does not receive or store any HIPAA-restricted data from customer networks.
- Are customers allowed to audit and/or conduct vulnerability assessments or penetration testing?
Kentik is open to coordinating any such activity, providing that it is scheduled in advance, poses no potential to disrupt normal operations, is conducted on a running up-to-date copy of Kentik’s SaaS platform, and is conducted at the customer’s expense.
- What type of data security/segregation controls does Kentik provide?
Customer data in our public SaaS is stored on common sets of nodes, but with multiple internal system safeguards to ensure that data cannot cross customer boundaries:
- The Kentik Data Engine (KDE) stores each customer’s network data (flow records, BGP, GeoIP, SNMP) in separate logical databases and tables, such that the data from any given customer’s devices is never included in a table with data from any other customer.
- Customers do not have permission/access to change the mapping of data to any KDE table.
- Customers can see only their own logical databases and tables, and thus only their own data.
- Data access audit logs are maintained for all activity within the environment.
- Access to client data is limited to senior, vetted SaaS administrators via logged 2FA authentication.
- There is no “God” account via PostgreSQL or API that allows access to data from multiple or all customers.
- Is data encrypted at rest?
Data at rest is not currently encrypted. Data stored by Kentik is derived from the headers of packets that have already traversed the public Internet in the clear and is generally not considered to be at the highest level of sensitivity by our SaaS customers.
- Is data encrypted in transit?
- Kentik collects NetFlow data, BGP routing data, and SNMP polling data from customer routers/ switches. Transmitted data can be optionally encrypted over HTTPS via the Kentik agent running on a host inside customer infrastructure. Inbound data privacy can also be implemented by use of a direct PNI to the Kentik backend, via cross-connect, if the customer has a PoP in an Equinix data center.
- Queries in transit are encrypted via SSL.
- Can data be removed at customer’s request and per customer’s policies?
Yes. Data is automatically removed from the system when past the negotiated retention period. Data can also be optionally removed at any time per customer request.
- Will data be shared with third party vendors?
No. Kentik does not share any customer information with any third parties. Kentik may seek express written consent from our customers to use agreed portions or aggregates of their data for Kentik’s own marketing or research purposes as covered in Kentik’s customer contracts, and would only do so with such written consent.
- Are there any interfaces or connections with third party systems?
A number of alliance partners have built connectors to the Kentik Data Engine (backend datastore). However any data retrieval via those interfaces must be instantiated and authorized by the Kentik customer, and must use validated customer access credentials controlled by the user.
- What forms of user management features and controls exist for Kentik?
- Our operations environment is tightly secured and accessible only via two-factor authentication.
- Internally, only users in the operations group have access to the Kentik infrastructure.
- Service users (customers) utilize portal login.
- User accounts exist only within a customer’s account, and can be created only by the designated customer administrator. Users can be assigned Admin or Read-only access.
- API access tokens are generated for each user account, and access to the data is also controlled using a salted hash.
- Data retrieval filters can be placed on individual users.
- Does Kentik offer single sign-on (SSO)?
Yes, we offer SAML2-based SSO.
- Is multi-factor authentication deployed for “high-risk” environments?
Multi-factor authentication is implemented in Kentik Detect. It is used internally by Kentik employees, and is available for each customer to enable for its own users.
- Pursuant to local laws, regulations, ethics, and contractual constraints, are all Kentik employment candidates, contractors, and third parties subject to background verification?
Kentik performs standard reference checks and background review as part of employment.
- Are employees required to sign NDA or Confidentiality Agreements as a condition of employment to protect customer/tenant information?
- What are Kentik’s user termination procedures and timelines?
- Customer users are deleted from the system as soon as they are removed via the User administration section of the portal.
- Kentik staff accounts are disabled immediately upon change in role or termination and audited monthly.
- What is Kentik’s password policy for systems and infrastructure that is used to host customer data?
Kentik employs secure-key, 2-factor authentication, secure kernels on all public bastions, and all access is logged to multiple endpoints.
- Does Kentik employ a formal secure application methodology?
Kentik currently follows OWASP guidelines for secure web development, including use of the OWASP dependency checker.
- What are your processes for security code review and secure development lifecycle?
Kentik uses several automated source code analysis tools for assessing both performance and security, and we are continuously evolving our development platform and processes to embrace best practices for secure code development. We also conduct regular code reviews, which include security reviews, as part of our implementation process.
- Do you utilize industry standards (Build Security in Maturity Model [BSIMM] Benchmarks, Open Group ACS Trusted Technology Provider Framework, NIST, etc.) to build-in security for your Systems/ Software Development Lifecycle (SDLC)?
These standards are under consideration for adoption, but are not used at the present time.
The tables in the following topics contain information typically requested by prospective customers to assess security concerns related to their vendors:
The categories of data that Kentik does and does not collect and store:
|Business Critical Information
||IP addresses of servers are exported to Kentik either over HTTPS transport or via unencrypted UDP (default). UDP flow can be encrypted before leaving your site. SNMP supports unencrypted and encrypted formats.
||No packet payload data is exported to Kentik.
|Other Sensitive Information
||Data is only IP address/port-related.
|Payment Card Information
||No packet payload data is exported.
|Personally Identifiable Information (PII)
||No PII is exported (unless contained in IP address). No packet payload data is exported.
|Protected Health Information (PHI)
||No PHI is exported.
||No public information is exported.
|Sensitive Digital Research Data
||No packet payload data is exported.
|Social Security Numbers (SSN)
||No packet payload data is exported.
What Kentik does with collected data, and where:
||Data is sent via UDP or HTTPS to Kentik’s PaaS offering, and is stored, indexed, and made available via the API and portal. Alerts can be configured to run over the data as well.
||NetFlow can be sent to a Kentik-provided proxying agent that runs on the customer’s network.
All outbound communication between the agent and Kentik’s network is via HTTPS.
Data is not encrypted on disk, however data cannot be extracted from the system unencrypted.
||Each company has an independent database fully partitioned from other customers.
All users within a company share a single database.
No databases can be altered by customers.
(user-subscribed, for alerting)
Current compliance-related information:
||All data stored in a SOC 2-compliant data center.
||Quarterly external penetration test.
Information on security-related monitoring:
|Audit logging and SIEM technology
||We send all system, server, and application logs to an internally- hosted, DR, HA log service such as ELK. We have human oversight as well as programmatic alerting for security alerts.
|Event logging and monitoring
||The following types of events are logged and monitored:
Failed authentication attempts
External traffic searches unrelated to queries
Unusual data-traffic patterns both internally and externally
|Incident Response Plan
||We have an Incident Response Plan in place to respond to incidents.
Information about the processes used to ensure the security of the application:
|Change management program
||Changes are tested through Continuous Integration (CI) QA process, development, and staging systems.
|Data used for development and/ or testing
||The staging system has some production data, but only from customers that explicitly opt in to this program.
|Testing and approval of changes for production
||QA testing is done actively and passively (testing the system and observing alerts and logs). Changes are then approved for roll- out to production.
|Deployment of changes to production
||Software updates are deployed to production through an automated process and systems that include QA, security verification, logging, and monitoring.
|Separation between testing and production environments
||Test environments are hosted on our own machines or on a secure IaaS. Staging is on IaaS and on our own hardware. Prod is separate and currently all on our own hardware.
|Software security code reviews
||We conduct periodic source code reviews and cover security reviews as part of a comprehensive code review.
|OWASP Top 10 Application Security Risks
||The application is audited against OWASP Top 10 Application Security Risks.
||As part of all design reviews we perform threat modeling against components, the system, and interactions (planned and unplanned) between components.
|Automated source-code analysis
||We use an automated source-code analysis tool to detect code security defects prior to production. We also conduct regular security reviews of our code.
||No portion of the development is outsourced to third party developers.
||Both 2FA and SAML2/SSO are supported for customers, and SAML2/SSO is utilized by all backend systems.
||Customers can interact directly with the DBI or RESTful APIs, in which case no JS is needed. Using our portal does involve using our JS.
|Web application vulnerability assessment and penetration tests
||We periodically conduct both web application vulnerability assessments and penetration tests.
Information related to security on production servers (application and database):
|Infrastructure vulnerability assessment and penetration testing
||We have conducted infrastructure vulnerability assessment and penetration testing. Valid security findings have been addressed. Systems are in place to audit/mitigate any future findings.
||We perform patch management on application servers and database servers. We run entirely on stateless Linux. Systems are kept updated with all security updates.
|User authentication to production
||Users are authenticated via key access and 2FA through our SSH gateway servers, which log all access.
|Testing, approval, and logging of system changes
||Documentation is via a collaboration service and email.
Basic disaster recovery information:
|Primary data center (production)
||Located on Kentik’s own equipment in Equinix DC3 and DC4, Ashburn, VA.
|Disaster recovery data centers
||Located on a secure IaaS (various locations).
|Recovery time objective (RTO)
||Less than 2 hours
|Recovery point objective (RPO)
||RPO today covers device identification and company/user metadata.
Device dynamics (NetFlow/SNMP/routing) data is replicated in the primary site and is only replicated outside the primary site for customers purchasing HA (multi-site HA+DR) service.