Adrian is a Security Strategist and brings over 22 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and software development. With experience at Ingres, Oracle, and Unisys, he has extensive experience in the vendor community, but brings a pragmatic perspective to selecting and deploying technologies having worked on “the other side” as CIO in the finance vertical. Prior to joining Securosis, Adrian served as the CTO/VP at companies such as IPLocks, Touchpoint, CPMi and Transactor/Brodia. He has been invited to present at dozens of security conferences, contributed articles to many major publications, and is easily recognizable by his “network hair” and propensity to wear loud colors. Once you get past his windy rants on data security and incessant coffee consumption, he is quite entertaining.
Adrian is a Computer Science graduate of the University of California at Berkeley with post-graduate work in operating systems at Stanford University. He can be reached at alane (at) securosis (dot) com.
We will close out this series with a look at several operational considerations for selecting a secrets management platform. There are quite a few secrets management tools, both commercial and otherwise, on the market, and each does things a bit differently. Rather than a giant survey of every product and how it works, we will focus on the facets of these products which enable them to handle the use cases discussed earlier. Central questions include how these platforms deploy, how they provide scalability and resiliency, and how they integrate with the services they supply secrets to? To better distinguish between
In this section we will discuss the core features of a secrets management platform. There are basic functions every secrets management platform needs to address the basic use cases. These include secure storage and disbursement of secrets, identity management, and API access, for starters. There are plenty of tools out there, many open source, and several bundled into other platforms. But when considering what you need from one of these platforms, the key thing to keep in mind is that most of them were originally developed to perform a single very specific task – such as injecting secrets into containers at
This post will discuss why secrets management is needed at all, along with the diverse use cases which teams need it to address. In every case there is some secret data which needs to be sent – hopefully not in plain text – to an application or service. And in every case we want the ability to provide secrets, both when an operator is present and automatically. The biggest single issue is that security around these secrets today is largely absent, and they are kept in cleartext within documents of various types. Let’s dive in.
API Gateways and Access
This week we are starting a new research series on Secrets Management. What is secrets management and why do you care? A good number of you in security will be asking these questions. Secrets Management platforms do exactly what the name implies; they store, manage and provide secrets. This technology addresses several problems most security folks don’t yet know they have. As development teams leverage automation and orchestration techniques, they are creating new security issues to be tackled. Let’s jump into some of the back story, and then outline what we will accomplish in this research effort.
Cloud computing is the single biggest change to computing we have seen, fundamentally changing how we use computing resources. We have reached a point where multi-cloud support is a reality for most firms; SaaS and private clouds are complimented by public PaaS and IaaS. With these changes we have received an increasing number of questions on how to protect data in the cloud, so in this research paper we discuss several approaches to both keeping data secure and maintaining control over access.
From the paper:
Controlling encryption keys – and thus also your data – while adopting cloud services is one of
Cloud services are typically described as sharing responsibility for security, but the reality is that you don’t working shoulder to shoulder with the vendor. Instead you implement security with the building blocks they provide you, possibly filling in gaps where they don’t provide solutions. One of the central goals of this research project was to show that it is possible to take control of data security, supplanting embedded encryption and key management services, even when you don’t control the environment. And with key management you can gain as much security as your on-premise solution provides – in some
This post will discuss how to deploy encryption keys into a third-party cloud service. We illustrate the deployment options, along with the components of a solution. We will then walk through the process of getting a key from your on-premise Hardware Security Module (HSM) into a cloud HSM. We will discuss variations on using cloud-based HSM for all encryption operations, as well as cases where you instead delegate encryption operations to the cloud-native encryption service. We’ll close out with a discussion of software-based (non-HSM) key management systems running on IaaS cloud services.
There are two basic design approaches to
This post will cover some issues and concerns customers cite when considering a move – or more carefully reassessing a move they have already made – to cloud services.
To provide some context to this discussion, one of the major mental adjustments security folks need to make when moving to cloud services is where their responsibilities begin and end. You are no longer responsible for physical security of cloud systems, and do not control the security of resource pools (e.g.: compute, storage, network), so your areas of concern move “up the stack”. With IaaS you control applications, data, user access, and
Running IT systems on public cloud services is a reality for most companies. Just about every company uses Software as a Service to some degree; with many having already migrated back-office systems like email, collaboration, file storage, and customer relationship management software. But we are now also witnessing the core of the data center – financial systems, databases, supply chain, and enterprise resource planning software – moving to public Platform and Infrastructure “as a Service” (PaaS & IaaS) providers. It’s common for medium and large enterprises to run SaaS, PaaS, and IaaS at different providers, all in parallel with on-premise systems.
Use of cloud services is common in IT. Gmail, Twitter, and Dropbox are ubiquitous; as are business applications like Salesforce, ServiceNow, and QuickBooks. But along with the basic service, customers are outsourcing much of application security. As more firms move critical back-office components such as SAP Hana to public platform and infrastructure services, those vendors are taking on much more security responsibility. It is far from clear how to assemble a security strategy for complex a application such as SAP Hana, or how to adapt existing security controls to an unfamiliar environment with only partial control.
We have received a