How Kenna Secures Kenna
Kenna Security understands the challenges companies face, that’s why we built our platform. But we don’t just sell security solustions, we live security in our own environment.
We implement a risk-based control system for our platform to make sure that your data is protected and secure. This includes things like the latest cloud-based architecture and implementing automation at a variety of levels to improve monitoring and reacting to events.
We embrace the philosophy that securing the company is not just the responsibility of our security team, but everyone’s responsibility. That’s why we have robust policies that govern our workforce.
Security in the Software Development Lifecycle (SDLC)
Our development teams employ a full suite of secure software development activities and controls. This starts with the design of our applications in a three-tiered Model View Controller architecture. We carefully segment each of our software technology layers via network and access controls. Within the code itself, our development teams leverage as many of the security functions as are made available by the Ruby on Rails framework. Our code is tested via static analysis and dynamic scanning prior to being deployed to our production environment. Some other controls in our SDLC are listed below.
· Defense in Depth design
· Secure Defaults design
· Reduced Attack Surface design
· Automated & encrypted data protection for data at rest & in transit
· Automated data protection for data in transit
· Mandatory input validation for all untrusted inputs with a definable format, length, type, and range. We also mitigate risk with additional software security techniques (parameterized stored procedures, encoding, etc.)
· Parameterized stored procedures for all calls to database backends
· Data encoding for all untrusted inputs using standard libraries
· 100% managed code to reduce risk from common attacks associated with non-managed languages, such as buffer overflows
· Anti-recovery techniques to help prevent malicious recovery of deleted data
· Peer code review using expert manual techniques and automated code analysis tools
· Automated functional and security test suite to help ensure high code quality and help prevent regressions
· Principle of least privilege deployment for both front- and back-end services
· Generic exception handling to help prevent information disclosure attacks
Web Application Platform Protections
Kenna protects against all cross-site request forgery (CSRF) state-changing actions using built-in platform protection. We also use implementation controls to prevent cross-site scripting attacks (XSS) as well as additional code-side filtering. These methods are also used to protect against cross-site scripting as well as SQL Injection and any significant security threats from web traffic.
Firewalls restrict network access to necessary ports and are configured based on the principle of least privilege according to NIST’s Guide to General Server Security.
Security Research and Disclosure Process
The Kenna bug bounty program is managed through Bugcrowd. To see the terms of the program and participate, visit https://bugcrowd.com/kennasecurity to register as a tester. You will need to accept the Kenna Security terms of service to engage in testing. If you have identified a vulnerability, please report it via Bugcrowd to be eligible for a reward.
Architecture & Benefits
The rapid growth of cloud-based services, coupled with the discovery of significant security weaknesses, has demanded heightened awareness and the use of high-level security measures and encryption protocols. We have carefully designed every aspect of our solutions to maximize security for our users. In this section, we’ll highlight some of the benefits of this approach.
The design of our network is based on three-tiered Model View Controller architecture that has been compartmentalized and firewalled, and we carefully segment each of these technology layers via network and access controls. Kenna has implemented documented security configuration baselines that harden and secure our systems.
Data in Transit
All application traffic occurs over TLS 1.2 or better, and all network traffic is encrypted via SSL.
All communication between the user’s device and Kenna is further encrypted at all times using TLS as an automated layer of data protection.
HTTPS Strict Transport Security (HSTS)
Our solutions run exclusively over HTTPS, so if someone manually edited the URL to start with http://, they would be redirected to an https:// URL. This prevents TLS-stripping attacks in the event that a user connects to Kenna from an untrusted network.
All authentication cookies use the “secure” flag as well as the http-only flag. This ensures that cookies are only sent over secured connections and that the cookies cannot be accessed over non-HTTP(S) methods.
We operate in a Zero-Trust model. For those who are not familiar, Zero Trust refers to a threat model that no longer assumes that actors, systems, or services operate from within a centralized security perimeter. Instead, users must be authenticated to all services independently.
In the Zero-Trust model, all networks are considered equal, and as such, there is no difference in the level of access allowed based on geographical location.
Kenna uses a wide range of technologies such as multi-factor authentication, threat analytics, anomaly detection in our Zero-Trust model to ensure proper access. Along with this, we also have governance policies that require giving users the least amount of access they need to accomplish a specific task.
Encryption & Other Controls
Kenna deploys a number of controls to protect the confidentiality and integrity of our customers and their data.
- Data at rest is encrypted using AES-256
- Standard FIPS-compliant encryption algorithms and implementations
- AES 256-bit encryption for symmetric encryption processes
- Variable-length RSA encryption for asymmetric encryption processes
- SHA-512 for internal/core data integrity checking
We understand that scalability is a requirement for our users, which is why we use major IaaS providers, so that we can manage our customers’ needs for volume and complexity. We use geographically distributed data centers so that we are always on, meeting our service level requirements. In the event of a disruption at one location, we can use one of our other locations. If you have requirements for where your data is physically located, we can support several locations to maintain customer data where required (e.g., if you are in the EU, we can keep your data in the EU).
SOC 2, Type II
Kenna performs a SOC 2 Type II, certification for security, availability, processing integrity, confidentiality or privacy. This means that our operations are reviewed annually by an independent, third party auditor and found to meet these security standards. We can provide a copy of this certification upon request, under NDA.
GDPR / CCPA
Kenna is committed to protecting the privacy of personal information. Kenna complies with the EU-U.S. Privacy Shield Framework and the Swiss-U.S. Privacy Shield Framework as set forth by the U.S. Department of Commerce. In addition, Kenna complies with the California Consumer Privacy Act and provides methods for individuals to exercise their rights granted to them by various privacy laws, such as the European Union General Data Protection Regulation.
Information Security / Operational Security
We use a variety of tools, processes, and technologies to help secure and control our environment.
Kenna regularly conducts vulnerability scanning using proprietary, commercial, and open-source tools, and using our own platform for risk-based vulnerability management and remediation. Kenna conducts regularly scheduled self-penetration testing to look for vulnerabilities. Then, at the center of our vulnerability intelligence is our own instance of Kenna, which is a reliable part of our daily workflow.
Secure Admin Access
Kenna implements role-based access control, so that users can be assigned only the permissions they need to perform their respective functions. By default, no access to front and back-end services is granted to any employee and access is granted based only on operational need and at the least privilege necessary to perform the duty. All access to the Kenna infrastructure requires VPN access with two-factor authentication to enhance security and accountability.
Secure Data Access
Kenna security policies strictly enforce data access on a “need- to-know” basis. An active process also revokes access by employees, contractors, or others who have left our company and no longer require access (this includes physical access, logical access, and access to any SaaS or external applications that our company uses). Third parties (such as outsourcing partners, vendors and subcontractors) do not have access to unencrypted company data.
A centralized log management and monitoring solution is in place to detect unauthorized access to Kenna systems. This also allows our team to reconstruct the actions that any given user took within the application.
Our products are designed with security in mind. Some of the ways that Kenna solutions keep our customer data secure are listed below.
Security Architecture Design
During the sign-up process, the user generates their own password. User passwords are stored in a one-way salted hash. By design, it is impossible for any Kenna employee to access user passwords.
Users are authenticated when they sign in to the Kenna Security Platform using their password. The password is used to send an authentication hash to the Kenna server for authentication. Sessions expire after a 30-minute session timeout.
The application supports single sign-on using OAuth Login standards. Administrators of the Kenna Security Platform can enable two-factor authentication which will send a one-time password to supporting applications each time a user logs in.
We care about the privacy of your personal information and have dedicated an entire page to our privacy practices. For more details, go to the privacy page at https://www.kennasecurity.com/privacy/