Bloomberg Terminal. HPE

Security architect and identity program manager for Bloomberg (a global leader in business and financial data, news, and insight) discusses how open source software helps his team stay ahead of security threats

Almost weekly, the news is filled with yet another major organization reporting a hack or ransomware attack. In the last 12 months alone, we have seen a slew of damaging attacks – SolarWinds, Microsoft Exchange, Colonial Pipeline, T-Mobile – to name just a few.

These alarming stories are keeping CXOs and many others in organizations awake at night. Clearly, the industry needs to improve technologies and techniques used to combat these ever-increasing threats. Hardening the network perimeter is the classic approach to these problems, but one small gap in this moat could leave your sensitive data exposed. We need to reconsider our approach to securing critical assets by making authentication ubiquitous.

Staying vigilant to a growing and constantly changing landscape

As part of the Security Architecture team in Bloomberg’s CTO Office, I have plenty of experience in information security. For the past five years, I have worked on network and infrastructure security, human and machine identity management, and data science applications to identify emerging threats from malicious actors.

Ensuring the security of our infrastructure is paramount. That is because, at its heart, Bloomberg is a technology and information company–delivering business and markets news, financial data, analysis, and video around the world. The organization routinely collects almost 2 million stories from more than 150,000 news sources around the globe each day. Furthermore, the Bloomberg Terminal is a way for analysts and investors to access market data, including the more than 230 billion unique market data ticks per day that we collect across all asset classes.

Today’s challenge: securing services in dynamic and heterogeneous environments

Like many organizations, Bloomberg has a heterogeneous computing environment that has evolved considerably since its inception 40 years ago. The infrastructure includes UNIX and Linux machines, Kubernetes running in a private cloud, and, increasingly, workloads running in the public cloud. Because all these various infrastructures are different, our approach to managing these workloads must also be different. Securing the identity of such different types of architectures at this large scale can be challenging. On top of this, these various workloads all need to be able to communicate with each other, requiring any sort of identity technology to be usable across a wide variety of use cases.

To solve this problem, our team turned to the Secure Production Identity Framework for Everyone (SPIFFE). SPIFFE is an open standard currently being incubated by the Cloud Native Computing Foundation (CNCF) for securely authenticating software services in dynamic and heterogeneous environments using platform-agnostic cryptographic identities.

I was recently interviewed by Sunil James, Senior Director of Security Engineering at HPE during a workshop on SPIFFE and SPIRE Fundamentals as part of the annual HPE Discover event. We discussed the benefits of open source software and why SPIFFE should be considered a critical technology in the security architect’s toolkit. I have included some key takeaways from that conversation below.

SPIFFE is an authentication technology based on standards

By design, SPIFFE handles not only cloud-native and Kubernetes use cases, but also it manages identities across legacy infrastructures. SPIFFE defines how components interact, making it a powerful basis for converging management of identities across all kinds of infrastructure. For our team, it became a unifying tool. Suddenly, workloads that were built using new technologies could seamlessly connect to workloads running in legacy units.

Keep in mind that the SPIFFE specification is not an authorization technology. Instead, it is an identity and authentication technology that enables multiple workloads to interoperate and authenticate one another. You can think of SPIFFE as being something like a driver’s license or other forms of identity we carry around in our back pocket—they tell who we are, what we can do, and where we can go. In the world of software, SPIFFE basically does the same thing. And once SPIFFE conveys this authentication information, then an authorization technology can take over.

In the past, authentication technologies have either been platform-specific or required a lot of manual labor to manage, especially at scale. For example, client certificates would need to be replaced periodically for a particular host to authenticate to a service. Of course, certificates expire. If someone forgot to rotate a certificate, it could result in significant downtime, which could be catastrophic for a business.

The goal of SPIFFE is to securely manage identities across a wide variety of infrastructure using standardized documents. What is really exciting is that these identity documents are already built on top of widely adopted standards. It even works with older workloads that may not use the most up-to-date technologies.

Open-source software can help us work together to combat threats

Unfortunately, the security landscape is constantly changing, as bad actors continue to learn and update their attack vectors. Organizations must do the same in order to stay several steps ahead of them. As security architects, our job is to give our blue team a fighting chance, by giving them tools to keep bad actors at bay.

And that’s where open-source software plays a huge role. At my organization, using and contributing to open-source software is a core value. It is critical for developers worldwide to evolve and adopt open-source software, such as SPIFFE and SPIRE (the production-ready implementation of SPIFFE), to combat growing security threats.

The bigger picture – zero trust

Of course, SPIFFE, SPIRE, and other open-source software options are only part of the bigger picture of what organizations must adopt to combat this ongoing threat. Many enterprises are turning to zero trust, an approach used for identity and access management that ensures no user or software is trusted by default. To achieve that goal, zero trust demands that all users, devices, and application instances must prove they are who or what they are before they are authorized to access the resources they seek.

Organizations are making great strides in implementing these types of technologies¹ to protect infrastructure, operating systems, software platforms, and workloads — without signatures, significant performance trade-offs, or lock-in. Open source software such as SPIFFE and SPIRE can provide the underpinnings to successfully stay ahead of constantly evolving attackers.

A never-ending battle demands a multi-layer approach

Looking forward, we all need to work together to help organizations assess all aspects of their security. Successful security architects need to consider a layered approach to protect their infrastructure. SPIFFE, the bedrock on which you layer other technologies, makes it easier for enterprises to authenticate software services in heterogeneous environments.

Yet, we cannot stop there; we must all be diligent. Threats to our businesses are continuing to evolve, and the damage that attacks on the infrastructure technologies we traditionally used to protect the perimeter of our networks have shown that securing the edge is no longer enough. Of course, there is no silver bullet. Bad actors are always coming up with new ways to thwart what were yesterday’s best practices. However, SPIFFE is a key tool at our disposal. Since it is an open standard, we will see it adopted to secure a broader set of use cases.

To see our complete conversation from HPE Discover 2021, check out the workshop SPIFFE and SPIRE Fundamentals. You can also learn more by watching Sunil’s interview about security engineering on SiliconANGLE’s theCUBE during HPE Discover 2021.

^[1] For example, on June 22, 2021, HPE announced Project Aurora: https://www.hpe.com/us/en/security/project-aurora.html