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.
- UDP flow and SNMP are unencrypted by default.
|Data on disk
||- When clients connect to Kentik Data Engine, PostgreSQL enforces the use of SSL.
- Data is not currently stored in an encrypted form on disk.
||- Each customer has a completely independent PostgreSQL database.
- All users within a given customer share the same database.
- No user can alter tables created by the system.
- Each password is stored as a salted hash, with unique salt used for each user.
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 SOC2/ISAE3402 or similar third party audit reports?
Kentik is planning a full SOC audit in the first half of 2018. All stored data is in a SOC2-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, PagerDuty 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?
If a security breach occurs, 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?
- Are the hosting facilities SAS 70 Type II Certified?
Compliance is planned for 2018.
- Is Kentik's service PCI compliant?
Not applicable. Kentik does not receive or store any PCI-restricted data from customer networks.
- Is Kentik's service HIPAA compliant?
Not applicable. Kentik does not receive or store any HIPAA-restricted data from customer networks.
- Do Kentik's customers have a right 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 tables created by Kentik Data Engine (KDE) to store network data (flow records, BGP, GeoIP, SNMP) are logically segregated 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 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 the PostgreSQL command line interface (CLI).
- 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, and would only do so with such written consent.
- Are there any interfaces or connections with third party systems?
Yes. There are a number of alliance partners that 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 accessibly 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.
- Does Kentik offer single sign-on (SSO?), such as SAML or Oauth?
Not yet; this capability is planned for 2017 Q4.
- 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 employees are terminated via a set process, including removal of access rights to the Kentik infrastructure within 1 hour of termination.
- 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.
- Have you verified that all software suppliers adhere to industry standards for secure development lifecycle?
Kentik does not utilize any software suppliers that affect the security of our systems.
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).
||No. No packet payload data is exported.
|Other Sensitive Information
||Only IP address/port-related.
|Payment Card Information
||No. No packet payload data is exported.
|Personally Identifiable Information (PII)
||No (unless IP address contains PII). No packet payload data is exported.
|Protected Health Information (PHI)
|Sensitive Digital Research Data
||No (no packet payload data is exported).
|Social Security Numbers (SSN)
||No (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.
- Queries in transit are encrypted via the PostgreSQL command line interface (CLI).
- Data is not currently encrypted at rest.
||- Each customer can only see their own data via system-created logical PostgreSQL tables. Customers do not have permission/access to create these logical table mappings.
- All customer data is stored on the same data nodes.
Current compliance-related information:
||All data stored in a SOC2-compliant data center.
||Yearly external penetration test.
|Legal, regulatory, or industry requirements.
||Currently none (not operating in the EU or Russia).
This table covers common questions related to application security:
|Is there a change management program?
|How are changes tested?
||Through a staging system.
|Is production data used for development and/or testing?
||The staging system has some customer data, but only from customers that explicitly opt-in to this program.
|How do changes go into production? How are they reviewed and approved?
||QA testing is done actively and passively (testing the system and observing alerts and logs). Changes are then approved for roll-out to production.
|Who has access to deploy into production?
||Operations staff and a limited number of senior developers (currently two).
|Explain the 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.
|Do you conduct software security code reviews on the source code? Explain:
||We conduct periodic code reviews and cover security reviews as part of a comprehensive code review.
|Is the application audited against the OWASP Top 10 Application Security Risks?
|Do you perform threat modeling? Explain:
||As part of all design reviews we perform threat modeling against components, the system, and interactions (planned and unplanned) between components.
|Do you use an automated source-code analysis tool to detect code security defects prior to production?
||Yes. We also conduct regular security reviews of our code.
|Is any portion of the development outsourced to third party developers?
|Does your application/service support SAML/SSO for login?
||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.
|Do you conduct web application vulnerability assessment/penetration tests?
This table covers common questions related to infrastructure security:
|Has a infrastructure vulnerability assessment/penetration test been performed?
||Yes. We have addressed valid security findings, and have systems in place to audit/mitigate any future findings.
|Do you perform patch management?
|How are application servers and database servers patched?
||We run entirely on stateless Linux. Systems are kept updated with all security updates.
|How are users authenticated to production?
||Users are authenticated via key access from our SSH gateway servers, which log all access.
|How are system changes tested, approved, and logged?
||Documentation is via a collaboration service and email.
This table covers common questions related to security monitoring:
|Do you perform audit logging and use SIEM technology?
||- We send all system, server, and application logs to Elasticsearch/logstash/Kibana.
- We have human oversight as well as programmatic alerting for security alerts.
|What type of events are logged and monitored?
||- Failed authentication attempts
- External traffic searches unrelated to queries
- Unusual sources of flow
- Crashing/failed components
|Is there an Incident Response Plan in place to respond to incidents?
Basic disaster recovery information:
|Primary data center (production)
||Located on Kentik's own equipment in Equinix DC3, 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 only replicated for customers purchasing HA (multi-site HA+DR) service.