Hyperscale Security

I spent last week at Headquarters which is always great to talk directly with many security colleagues in a short amount of time – and not just in the office, but also dinner and drinks. That always allows for conversations that can go deeper and more passionate – and sometimes more honest – than you get in the day time, let alone when meeting virtually. Especially when you've known each other for years.

Thursday was the local Cybersecurity Awareness Month event, and I was invited for an Executive Q&A on our security strategy and direction. To continue the conversation, I invited those interested to dinner after to close out my week before flying back home. This is how I found myself opposite my oldest friend in the security organization, deeply engaged on one of his favorite topics: open source security.

“But That Stuff is Boring!”

He wanted to talk about protecting against zero days in the most common open source components used in our solutions. Admirable, but aside from the greater risks from known vulnerabilities, how would you do that? Not knowing they exist, such zero days by definition would have slipped through our SAST and DAST scanning. So, are you proposing we run continuous fuzzing tests against such components and dependent libraries, in addition?

We can engage the internal security community (another one of his favorite topics), he replied. They can submit vulnerabilities and pull requests to the maintainers. And we could patch our landscape even before the vulnerability is disclosed.

Wait, you're suggesting we fork the library and deploy a patch, rather than wait for the fix to be released by the maintainers? And then how do we get back on the official version? Do we force all the developer teams to patch twice for a zero day nobody knows about and we have no evidence is exploited in the wild? Why wouldn't we just manage it through the existing known vulnerability management processes with established SLAs, and if necessary deploy a temporary detection or mitigation?

Oh, but that stuff is boring...

Ignoring the Boring Makes Us Vulnerable

We have such a habit in infosec to chase after the esoteric and interesting. It is encouraged through conferences and social media fame. The cybersecurity industry adds to it, whether for marketing reasons or added features without guidance or consideration how to operationalize them but demo well. We like intellectually interesting problems we can solve on our own. But then we shouldn't be surprised when the basics aren't taken care of, and developer teams consider us burdensome and adding irrelevant toil.

I get that it may not be as much fun to chase after teams with reports on alerts or missing evidence for compliance controls, help teams to manage a never ending stream of newly reported vulnerabilities against SLAs, or to improve asset discovery and metadata management, rather than chase after zero days. But the boring basics are what truly reduces the attack surface. Ignoring the boring is what continues to make us vulnerable.

Finding Excitement in the Boring

To solve the big problems in security, we must find excitement in the boring. Let's focus our minds on how we implement and operationalize least-privilege IAM and secrets, how we can make CI/CD pipelines both more secure and efficient for developer teams to allow for greater code quality and higher velocity, and provide secure-by-default infrastructure, platforms and services that enable teams to be more productive without getting in their way. Find the intellectual challenge in security engineering and operations. We must work on the risks we face, not the threats we like.

cloud security posts without corporate approval @jaythvv@infosec.exchange