What Security Means at Kindling
Last week’s excellent 99% Invisible podcast detailed the history of locksmithing and lockpicking, and, as a consequence, the historically anomalous 70-odd year period when a concept called “complete security” existed. You should listen to it in full, but here’s the short version: an inventor named Joseph Bramah once created a lock that nobody could pick, despite his publishing full schematics of its inner workings. For awhile, it was possible to lock something, and be completely sure that (as long as the lock prevented opening the only way in or out) whatever was behind the lock was safe—until, inevitably, someone picked the lock. That finally occurred in 1851, and nothing has been totally, 100% secure since. Fortunately, today, when companies rely on data security and intellectual property for their success, we’re capable of coming extremely close to 100%.
Administering Kindling’s systems as a DevOps Engineer means security practices, protocols, and concerns are very much part of my matrix. We just published an overview of Kindling security from personnel protocols to tech measures, and anyone who is interested in the nitty-gritty of our protection practices should absolutely read that. To give it some context, I’d like to share a little bit of ancillary information about how, and why, we think about security here at Kindling.
The main reason security is key for our product is that customers trust our software to manage and protect the ideas which give them their greatest competitive advantage, and which precipitate their next moves as a business. We take that trust very, very seriously, and in addition to the various levels of compliance required by both laws that apply to us and laws that separately apply to customers, we also take many steps and measures that enhance the security of our product, and our customers’ data, well beyond regulatory requirements.
In the past, information security was both easier and harder for enterprises, who often owned and managed their entire stack on-premise, from top to bottom. While this meant that security was entirely the managing entity’s responsibility, it also made access to any given piece of technology much more controllable (for someone who knew what they were doing). Today, a stack is distributed across an array of services, locations, connections, and products which all talk to one another, and this arrangement also has benefits and drawbacks.
A significant benefit of a distributed stack like Kindling’s is that the security is partially managed or facilitated by very powerful providers, like Amazon Web Services, our host, who not only require security to be as key a component to their offering as Kindling does to ours, but also have vast resources and extensive teams of engineers whose sole job is to dream up and implement ever-evolving new security measures, tests, and protocols, which means that we can sleep slightly easier knowing our data is in good hands. (Major examples of this include their new Key Management Service and their expanding support for turnkey full-disk encryption.)
On the other hand, interfacing with other people’s technology all the time means that we have to be their equal or better in protecting our customers’ data, because we need to ensure security on that data’s trip from the customer to the server and back to the customer. This puts the onus on me, as well as the rest of our team at Kindling, to implement features that customers want or require, in addition to the things that are just good practice. The latter reason is the impetus behind our use of SSL for all connections to and from our software in all cases, as well as our decision to encrypt all data at rest in our databases.
We also regularly assess the security of our services with any and all available tools, from virus scanning of all attachments to regular external penetration tests and the tracking of all vulnerability reports from around the security community, so we can stay as informed, responsive, and proactive on the issue of security as possible.
For my part, I follow security experts like Bruce Schneier as well as the recommendations and intel of groups like Qualys, to make sure my personal knowledge of the available and standard security features remains as up-to-date as possible.
Sometimes, customers ask me what they can do to maximize security, for which I always recommend that they have all employees use a password manager—which is a terrific idea for everyone, no matter who they are. I personally use 1Password, but the tool doesn't matter as much as preventing reuse of passwords—that way a breach at one organization that they have a login stored in doesn't result in other services being compromised.
If you’re interested in a more in-depth account of our security features, please check out our Security page. We may no longer have one unpickable lock, but we have the next best thing: a staggering number of locks that are almost impossible to pick.