Overview #

We all keep secrets and also know that there are inherent costs in doing so. In the social realm, the cost is betrayal and we try to offset it by entrusting our secrets to only those whom we trust. Trust is however built on top of personal relationships. Further the choice of the secret keeper is also based on the nature of the secret. Some secrets are worthless after a certain time interval, but some secrets have to stay hidden for a very long time. A further complexity because of us being social animals is that there are group secrets, which are known only to a group.

Identifying if a person belongs to a group thus becomes an identity management problem. Secret management starts to suffer from scaling problems, once there are large number of secrets that needs to be shared and managed by diverse groups. The scaling problems becomes even more acute in the infrastructure realm, once machines and services can belong to a group and just not people and requires an entity that has a separate structure, organization, process and systems to guarantee trust.

Secret management at scale hence is no longer just a management problem, but is also a cost problem. While some secret keepers can keep and manage secrets effectively for less cost, they may fail to do so at a different scale. Others would be able to manage many types of secrets and groups, but may require a third party identity management solution which increases total cost of operations because of additional complexity.

How then should we evaluate which secret keeper to use? What would be the inputs that would tilt the decision to a particular secret keeping solution?

We need realistic examples from the field and focussed discussions to understand the above aspects and not just theory on how secret keeping solutions work.

Outline #

Discussion Structure #

Rather than starting from a particular solution and discuss the specific nature in which it works, the discussion should be centered around ** why a particular solution was deployed** in an organization and the thought process that went into it.

We need at least 4 - 5 examples on real world thought process that went in deploying a particular solution. In particular we would be interested in the following structure

1. What was the secret keeping solution that was chosen?
2. Why was it chosen?
3. What are the parameters for chosing a particular solution? The parameters we are looking to understand in depth are:
   • Number of Secrets
   • Nature of Secrets (Ephemeral, API Keys, Tokens etc.)
   • Number of entities that access these secrets (500, 1000 etc.)
   • Integration with Identity management.
   • Cost for storing and managing secrets.
   • Trust in the organization/community/person that developed and maintains the solution.
   • Integration with existing tools/cloud providers/organization workflows etc.

Requirements #

Expectation from Participants #

Participants must meet at least one of the following requirements to attend the session.

• Currently working or interfacing with a Secret management solution, but does not know why it was used instead of other alternatives.
• Currently evaluating or may evaluate a secret management solution in the future, but does not know how to pick one.
• Evaluated and deployed a secret management solution and have strong opinions on why it is the best decision or why it is not.

The session would be considered as a success if participants can understand to some extent the factors they would use to consciously evaluate a solution, if they are asked to do so again in their work environment.

Speaker bio #

Anand V is a security researcher who has written extensively on Aadhaar, India’s Digital identification project. He is a long term optimist on the illusory idea that people will care about their privacy and will not trade it for being a product while being a short term skeptic