Securosis

Menu

Research

Secrets Management: New Series

Adrian Lane September 19, 2017 1 Comment

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. It sounds cliche, sure, but IT and application environments are genuinely undergoing radical change. New ways of deploying applications as microservices or into containers is improving our ability to cost-effectively scale services and large systems. Software defined IT stacks and granular control over services through API provide tremendous advantages in agility. Modern operational models such as Continuous Integration and DevOps amplify these advantages, bringing applications and infrastructure to market faster and more reliably. Perhaps the largest change currently affecting software development and IT is cloud computing: on-demand and elastic services offers huge advantages, but predicated on automated infrastructure defined as software. While cloud is not a necessary component to these other advancements, it’s makes them all the more powerful. Leveraging all these advancements together, a few lines of code can launch – or shut down – an entire (virtual) data center in minutes, with minimal human involvement or effort. Alongside their benefits, automation and orchestration raise new security concerns. The major issue today is secure sharing of secret information. Development teams need to share data, configurations, and access keys across teams to cooperate on application development and testing. Automated build servers need access to source code control, API gateways, and user roles to accomplish their tasks. Servers need access to encrypted disks, applications need to access databases, and containers must be provisioned with privileges as they start up. Automated services cannot wait around for users to type in passwords or provide credentials! So we need new agile and automated techniques to provision data, identity, and access rights. Obtaining these secrets is essential for automation scripts to function, but many organizations cling to the classic (simple) mode of operation: place secrets in files, or embed them into scripts, so tasks can complete without human intervention. Developers understand this is problematic, but it’s a technical problem most sweep under the rug. And they certainly do not go out of their way to tell security about how they provision secrets, so most CISOs and security architects are unaware of this emerging security issue. This problem is not new. No administrator wants to be called into work in the middle of the night to enter a password so an application can restart. So IT administrators routinely store encryption keys in files so an OS or application can access them when needed. Database administrators place encryption keys and passwords in files to facilitate automated reboots. Or they did until corporate networks came under even more attack; then we saw a shift to keys, certificates, and passwords. Since then we have relied upon everything from manual intervention, key management servers, and even hardware dongles to provide a root of trust to establish identity and provision systems. But those models not only break the automation we rely upon to reduce costs and speed up deployments, lack also the programmatic interfaces needed to integrate with cloud services. To address the changes described above, new utilities and platforms have been created to rapidly provide information across groups and applications. The term for this new class of product is “Secrets Management”; it is changing how we deliver identity, secrets, and tokens; as well as changing the way we validate systems for automated establishment of trust. In this research we will explore why this is an issue for many organizations, what sort of problems these new platforms tackle, and how they work in these newer environments. Specifically, we will cover: Use Cases: We will start by considering specific problems which make secret sharing so difficult: such as moving passwords in clear text, providing keys to encryption engines, secure disk storage, knowing which processes are trustworthy, and mutual (bidirectional) authentication. Then we will discus specific use cases driving secrets management. We will cover issues such as provisioning containers and servers, software build environments, database access, and encrypted disk & file stores; we will continue to examine sharing secrets across groups and controlling who can launch which resources in private and public cloud environments. Components and Features: This section will discuss the core features of a secrets management platform. We will discuss the vault/repository concept, the use of ephemeral non-vault systems, identity management for vault access, role-based authorization, network security, and replication for both resiliency and remote access. We will cover common interfaces such as CLI, API, and HTTP. We’ll contrast open source personal productivity tools with newer commercial products; we will also consider advanced features such as administration, logging, identity store integration, ability to provide secure connections, and policy enforcement. Deployment Considerations: Next we will discuss what is stored in a repository, and how secrets are shared or integrated with dependent services or applications. We will discuss both deployment models; as well as the secrets to be shared: passwords, encryption keys, access tokens, API keys, identity certificates, IoT key pairs, secure configuration data, and even text files. We will also offer some advice on product selection criteria and what to look for. As we leverage cloud services and rely more heavily on automation to provision applications and IT resources, we find more and more need to get secrets to applications and scripts securely. So our next post will start with use cases driving this market. Share:

Share:
Read Post
dinosaur-sidebar

Research

view all

Sign Up for Our Newsletter

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

“Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.”

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.