Hey there. I'm Mrinal Wadhwa, CTO at . I met some lovely old friends and many amazing new people at the RSA Conference last week. Ockam On Tuesday afternoon, I walked through the bustling expo floor with hallway after hallway of products that keenly monitor, scan, and scrutinize every event, every log message, and every asset to detect and thwart any suspicious behavior as soon as possible. It was a stark reminder that the cybersecurity industry has devolved into a game that is impossible to win. We’re about to see major disruption. The Sisyphean Whack-A-Mole One booth had an arcade-like whack-a-mole game (see image above) to help visualize what they do. This is a pretty good illustration of what most (maybe greater than 90%) of cybersecurity products do; they scan some part of your vulnerability surface to detect anomalous behavior. Some scan network traffic, some monitor endpoints, and others inspect API requests. They’re all looking to whack that next mole - as fast as possible. There are thousands of products that specialize in scanning specific corners of your vulnerability surface. Some specialize within a specific industry, others are tuned for logs from specific popular tools. Many are incredibly sophisticated and use advanced machine learning and AI to detect bad behavior. They all highlight that they can whack-a-mole with higher accuracy than their competitors. Most scanning products do the job as advertised. Hey, it is incredibly satisfying to whack moles. But, if we take a step back to look at trajectory, we notice that our vulnerability surface is growing way faster than we can build scanners to monitor every part of it. Our personal and business data is, paradoxically, becoming less secure over time. Like Sisyphus, from Greek mythology, our industry is endlessly rolling a big boulder up a steep hill only to watch it roll back down. Our vulnerability surface is growing exponentially To develop an intuition, stay with me as I do some napkin math about an example application and the vulnerability surface of data it manages for users. For the purpose of illustration, assume that the odds of any one person making a bad security decision is a fixed constant. With a development team of 10 people, the vulnerability surface created by the application's would have an area of . source code 10 If this app depends on say 100 libraries and each library has 5 developers, then the area of the vulnerability surface created by these libraries is 100 * 5 = 500. Assuming the app runs in a container that has 100 operating system packages and each package has 5 devs, then the area of the vulnerability surface created by OS packages is also 100 * 5 = 500. Together, create a vulnerability surface of 500 + 500 = . dependencies 1000 This example app would operate in some network and that , let’s say, has 9 other microservices in it. If each service has a similar-sized team and dependency tree, then total vulnerability surface area of our app’s data becomes 10 * 1000 = . network 10000 Our app also depends on 9 cloud-based services (Databases, Event Streaming, Gateways, etc.) and each third-party service similarly is made of 10 microservices operating in a network. Total vulnerability surface area of our app’s data becomes including becomes 10 * 10000 = . third-party services 100000 This napkin math, while it ignores overlaps across surfaces, is a good mental model for the of the problem facing typical modern applications - . exponential scale Tens of thousands of developers, platform engineers, and system administrators must never ship a mistake for our example application’s data to remain secure ; we’ll never build enough scanners to catch all possible mistakes that can be exploited by attackers. Vulnerability surfaces are too big and are growing too fast. This is untenable To make matters even more challenging, a typical application development team has limited control over most of the vulnerability surface described above. They can’t choose to not use open-source libraries or not rely on cloud services. Building everything from scratch will take too much time, cost too much money, and will likely result in poor-quality solutions. We must change the game Instead of attempting to scan every part of an exponentially expanding surface, the only tenable approach is to make design choices that completely eliminate large portions of our vulnerability surface. We have to make entire classes of attacks impossible. We must build software in ways that drastically reduce the size of potential targets and limit the blast radius. Our . software must become private and secure by design In the past, this was challenging and costly. The following tools are changing the game: like Rust and Typescript turn invariants into compile-time errors. This reduces the set of possible mistakes that can be shipped to production by making them easier to catch at build time. Strongly typed languages of buffer overflows, use-after-free, and other memory safety errors. An attack vector that is known to cause 60-70% of high-severity vulnerabilities in large C or C++ codebases. Rust provides this safety without the performance costs of garbage collection at runtime. Memory-safe languages eliminate the possibility Supply chain security practices described in emerging standards like SLSA help us build controls that . This diminishes the possibility of malicious libraries, packages, and container images exploiting developer workstations, build pipelines, and runtime environments. guarantee artifact integrity within our dependency trees , stored in secure hardware, combined with and approaches eliminate the possibility of attacks using stolen passwords and access tokens. Cryptographic keys passwordless tokenless and granular , at the application level, using tools like Ockam, enables zero trust in operating networks, VPNs, and VPCs. This removes other applications within the same network from an application’s vulnerability surface. Mutual authentication authorization of all data, and using Ockam , services from our vulnerability surface. End-to-end guarantees of data authenticity, integrity, and confidentiality mean that any mistake or misconfiguration within a broker, load balancer, or gateway cannot compromise our application’s data. Application layer, end-to-end encryption Secure Channels eliminates third-party All these approaches shift security left and allow an application’s development team to be in control of the security and privacy properties of their application. This team no longer has to cross their fingers and hope a third-party service won’t be compromised; they can simply end-to-end encrypt data as it passes through that service. Such design decisions turn security and privacy into problems that can be methodically solved instead of endlessly rolling a big boulder up a steep hill. Regulatory pressures are forcing the game to change Another interesting effect of relying on scanners for security is that it shifts the costs of securing software, away from vendors, to the customers of software. In the past, software vendors were able to require that customers operate their software within tightly controlled network boundaries like VPNs. They were able to specify environmental configurations that must be set up just right for their products to be secure. They were able to pass the costs and liabilities of security to their customers. As security threats escalate and vulnerability surfaces become unmanageable, both customers and regulators have realized that this shift of burden is ineffective and too expensive. The chief executive at insurer Zurich recently told the Financial Times that ”. CISA chief Jen Easterly and her colleague Eric Goldstein penned an article in February titled - arguing - They lay the to a model where cyber attacks may become “uninsurable Stop Passing the Buck on Cybersecurity “Technology manufacturers need to take responsibility for the security outcomes of their customers.” plan for a foundational shift “cybersecurity would ultimately be the responsibility of every CEO and every board.” This shift of accountability to senior leadership at technology vendors is reflected in new regulations across countries. For instance, the SEC has proposed cybersecurity incidents within . rules that require companies to disclose four business days In this turbulent landscape, savvy businesses are turning security and privacy into a competitive advantage. Software products that are designed to be secure are winning customers because they result in much safer systems that remove risks, ease compliance hurdles, and are significantly cheaper to operate. As I walked out of the expo halls at RSAC, it was obvious to me that the cybersecurity industry is about to see some disruptive change and the only companies that will survive the next few years are the ones that embrace this new reality.

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Why We Rewrote Ockam in Rust

How to Move End-to-end Encrypted Data Through Kafka

Build Applications That Trust Data-in-Motion

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

A CTO’s Reflection of the 2023 RSA Conference

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Securely connect a web app to a remote Postgres database

102 Stories To Learn About Encryption

153 Stories To Learn About Cryptography

5 Books You Can Read to Boost Your Computer Science Knowledge

6 Not-so-obvious Tech Predictions

Securely connect a web app to a remote Postgres database

102 Stories To Learn About Encryption

153 Stories To Learn About Cryptography

5 Books You Can Read to Boost Your Computer Science Knowledge

6 Not-so-obvious Tech Predictions

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps