Vision of security that doesn’t hinder innovations yet protects it #
Many of us have been dealing with security tooling for decades. Developing, using, auditing, integrating, improving, breaking — it’s hard to find an angle at which we didn’t deal with security tools.
Often security tools are cumbersome. They don’t compose well. They add more complexity when deployed than they remove security risks.
Modern security engineers often end up operating, say, five similar dashboards, three user management or identity management systems, delivery pipeline management and orchestration systems—just because they need some small fraction of all these products’ functionality in their daily jobs.
This is not what we want, and this is not how security tooling should look.
If we look at a security system within a large infrastructure, product or organisation, what matters is baseline and coverage.
In other words, it’s important to know how weak are the weakest parts, and how much the system is covered with security controls at different levels.
Security baseline #
Those of us who have been around long enough understand that it doesn’t matter how good a single security control is.
What matters is how weak is the weakest link, because the attackers are on a fixed budget even if it’s a time budget.
So, in terms of systems, the security baseline is more impactful.
What increases the baseline? Freeing up engineers’ time, simplifying management and complexity, and enabling more granular control on integration points.
Data lifecycle #
Security starts with understanding what we’re protecting (assets and data) and from whom (risks and threats).
Data protection should cover the whole data lifecycle. It’s futile to protect data only in one part of the system, leaving other parts exposed to attackers.
There are two approaches to covering sensitive data lifecycle:
- Have good tools that fit into system architecture, and cover the whole data lifecycle with their security controls.
- Bend the data lifecycle until it fits into the tools.
We’re much for the former and against the latter.
Why does security hinder innovation, anyway? #
Existing security tooling bends lifecycles, requires special maintenance, and changes system architecture drastically in a bad way.
When the security effort relies on some “expert advice” (aka sales propaganda) rather than realistic understanding of the risks, it often misses out the point of security.
Many security controls come from the era of choosing lesser kinds of evil, “at least something”, instead of seeking good. With no incentive of interoperability, composing such controls increases complexity radically.
Complexity leads to more security problems, efficiently turning millions of dollars of security investment into security theatre. Oldschool products set the tone for the engineering experience: you are expected to struggle, hinder your product, and run around in circles.
This status quo is not set in stone and can be changed. We don’t need to reinvent cryptography or introduce fancy synthetic language to describe security policies. We need simple stuff.
Our vision #
We believe these principles make the security software beneficial:
- Simple controls.
- Large coverage and impact.
- Highly configurable, composable, manageable, working well with each other.
- Compatible with modern monitoring and logging tools.
Our vision follows the UNIX-way: we produce atomic, well configurable units. Such a unit can be used for one task or many tasks, composed and recomposed well into entirely different schemes.
Tools are useful when they can participate in a larger security infrastructure instead of claiming to cover it.
It’s also fair: licensing several smaller libraries is more cost-appropriate for smaller companies that can scale security tooling together with scaling their product.
Born out of experience #
Through these years, we’ve conducted numerous large-scale security engineering projects, improving software products, building huge systems from scratch, and challenging the status quo in large ecosystems.
Most of our tools have been born this way: we were addressing the need for adequate tooling rather than inventing a “next revolutionary security thing”.
We want something else: security tools to be meaningful, simple, and well-configurable.