Unfortunately, no. The internet’s security infrastructure hasn’t changed in 30 years and was built to protect data at rest. It still relies on keys and certificates, which are often lost, stolen, and misappropriated. A compromised key can expose your data without your browser being able to detect it. So, no, the lock icon is not a reliable indicator of security.
Encryption works like a lock. With the right key, the lock opens easily. It is the same way with encryption where compromising the key that protects data in flight means the data is compromised as well.
Certificates are the glue that makes legacy security solutions work. When a certificate authority is compromised it enables a Bad Actor to impersonate any web service, whether it is a website or a different service, and attack private data.
No. Unfortunately, with legacy security, your private key is not the only problem.
In order to connect securely, a connecting device must first confirm that it is connected to your site and not an attacker’s site. In layman’s terms, when you obtained your certificate from a Certificate Authority (CA) it established your site’s identity. Any CA can do this for you by signing your certificate with their private key.
What this means is that the compromise of any CA’s private key also compromises your site’s security. In other words, if a CA’s private key is compromised a Bad Actor can create “false certificates” that fool the connecting party into thinking that they are connecting with your site when in reality they are connecting with an attacker’s device.
KnectIQ has discussed these problems with technical staff from startups to large corporations to national security officials. Nobody disagrees with any piece of our analysis – private keys expose communication, Certificate Authorities do the same, and every user must manage their devices correctly for security to be assured. This is all established fact.
But technical staff’s role is to solve business problems given agreed upon requirements. The requirements they are currently operating under allow only existing tools (PKI, CAs) to secure data in flight, so it is not surprising that industry keeps using the same flawed tools.
The cybersecurity community needs to raise the bar on security by updating requirements to make digital communication safer. Collectively, we don’t need to throw away the old system, but we do need to enhance it. Insisting that our secure communication be restricted to known parties and that its performance is auditable can ensure progress, and KnectIQ does exactly this.
Stored, or persistent, keys are never used for securing data in flight. Our system meets the ZeroTrust security law that says “No credential or cryptographic secret exists either before or after its function”.
The most sensitive data should only be shared with known and trusted employees or partners. Encryption is not enough to secure data. Knowing that only the intended recipient can decrypt the data is crucial to information security. In other words: Identity + Encryption = Information Security.
Logging every transaction between provisioned parties allows us to report exactly who accessed the information. Additionally, any attempted breaches are immediately logged.
It is already a best practice to regularly audit anything of value including physical and endpoint security, however, this generally happens well after events have transpired. The ability to immediately audit the security of data-in-flight is something no legacy system can provide.
Yes. We can scale horizontally and vertically, and our systems are distributed for availability as well as scale. Our system currently exceeds 8000 transactions/second (more than the volume of transactions processed by Visa). And we can scale by simply adding more systems.
KnectIQ is not a single system. There are a minimum of three separate systems that must all be successfully compromised to attack your data. In addition to distributing functionality for reliability, KnectIQ also partitions information between discrete parts of the system so that no single user or attack can expose customer data. Additionally, because KnectIQ doesn’t touch or “see” customer data, the data pathway would have to be separately compromised. Compare that to current best practice where compromising a single key provides the ability to unlock all data-in-flight.
KnectIQ can run almost anywhere. We currently have packages to support servers running Windows, OSX, or Linux. We also deploy to mobile devices and run in any modern browser with no additional software installs.
This really depends on the solution. We can classify integrations into three buckets:
Small Effort — In some cases it may be as easy as configuring the KnectIQ trust environment and then recompiling with a KnectIQ enabled library.
It Depends — In other cases, the communication portion of an application may need to be extended with our APIs to enable our auditable security. Depending on the scope of the integration the effort can vary.
No Effort– In many cases, KnectIQ will be integrated into a solution such that a company need only select and deploy a solution they already use with “KnectIQ inside.”
Different organizations require different levels of security. Even within an organization, some users may require more vetting than others. So, there is no “one size fits all” process. For example, a mobile banking user requires less security care to check a balance than for making large financial transactions. National security applications would require even more care.
The KnectIQ solution is configurable and able to handle any of these. It can be set up to automate adding a new user by simply clicking on a welcome button, but it also supports workflows where valid identification must be verified manually, in person, or in a secure environment.