Today I’m live blogging Teleport Connect – Teleport’s first conference. I’m speaking later, but the talks are interesting!
The Department of Yes
Kevin Hanaford, Head Of Security Engineering @ Discord.
Security has been traditionally seen as the department of no. Remember the old RSA keys and how clunky they are. Intention was to protect company and customer data.
Most employees just do things, your controls failed them. Also, people do the peoply-things, and security makes everything hard. And they circumvent controls to get their job done.
People get around policies and tools that don’t make sense.
Showed a graph that shows what security did to employees caused job stress. It is all about performance!
We want people to naturally gravitate towards the best path, no friction, don’t take people out of the job they are doing. Make the area bad-actor-proof.
Only perfect security is shutting the company down. Risk-oriented security is possible.
To get there, build for your customers, provide low value for attackers.
Dept. of Yes is building for your customers, approachable, realistic. Be helpful! Risk oriented, realistic, business aware. Tells people what to do and actively says yes.
How to do it? Build an understanding of what you need to do. Don’t forget your internal customers. Know what you’re protecting, Understand the culture and your obligations (regulations). Listen, listen, listen. People WILL tell you what’s wrong.
4 major steps to get there: ID north stores, do some work, measure + hold yourself accountable, respond to feedback.
Discord north stars:
- Make the secure way the easy way. people are more likely to opt-in. When they went to teleport, minimal retraining with lots of security ROI.
- Devs hate context switching, so they optimize for in-line solutions
- Easy is never as easy as it looks, focus on higher roi
- Only add more when necessary to reduce friction
Important to be retrospective. And hold yourself accountable. you’re only one expert, not all the exports.
Continuous process, it never ends. But this is how to make your infrastructure more elastic.
Scaling Infrastructure Access
Ev Kontsevoy, Teleport CEO
We’ve had ways to access datacenters before, why do we need something new? Cuz scaling breaks the old ways.
What is access? For infrastructures, it means connectivity, authentication, authorization, and audit.
hard to find a solution to do all four of these things.
What is infrastructure? hardware, software, peopleware.
Scaling infrastucture = scaling access (pain and risk) for infra access
Scaling software introduces lot of complexity because of the layers. All the layers have their own log in, RBAC, etc etc plus expertise from your team.
Scaling hardware is difficult because it is changing.
Scaling people is difficult because people come and go, use their own devices, work from home, etc.
Security and productivity are in opposition to each other, and can lead to security theater.
Most successful attacks follow a pattern: humans do something they shouldn’t, and attackers exploit human error. They get in, pivot and go after more critical systems.
Design access system so it doesn’t rely on human error. Secrets are leaked because of human error, so move from secrets to true identity. Teleport considers secrets vulnerabilities.
How to transfer identity? Certificates (secrets that expire quickly). Certificates are supported by most everything
Eliminate access silos. Consolidate policies in one place.
Secrets are a surface area for an attack but so is time. Sensitive resources can temporarily upgrade critical access then drops it down.
Machines v humans is another surface attack – like a database table. Machines can access this surface – so machines have to have a policy to access data.
Complete zero trust. Don’t trust the network – design everything like it is running on a public network.
Don’t have many audit logs, unify your audit logs so you’re not looking everyplace for problems.
Infrastructure is only secure if your engineers love their access tools. Security is mostly about people.
Access tools need to be easy to start using. Open solutions are more secure (according to speaker). Developing in open, collaborate with customers and partners.
Become immune to human error with secretless security model. Use zero trust, Avoid access silos. Prevent security theatre (be the dept of yes, not no). Use open source.
Continuous Same Day Teleport Delivery
Sako M, Sr. DevOps @ Gladly
Definitions of devops efficiency.
Toil – every tool you add increases you scope and makes you slower. so you have to take care of it.
Deploy metrics – deploying fast and frequently without availability impacts of introducing new bugs.
- L1 = manual, but this is where you build a playbook
- L2 = semi-automation, team comes together and decides what can be automated
- L3 = conditional automation,
- L4 = high automation, find more interesting work to do! Your job is safe, you;ll a
- L5 = full automation, end to end, no intervention
Golden Path is reusable, well architected reference architecture. Use git repository template to get started.
Select software based life-cycle phases
Second session I’ve been in where writing things down has been brought up.
Nice explanation of using helm.
Teleport has helped him scale the team.
Moderated by Reed Loden, VP of Security @ Teleport. Panelists: Donnie Hasseltine, CISO @ Xenon Partners, Annalea Ilg, CISO @ Figment
Biggest worry? Are we preventing attacks, or blocking at the right level?
Create champions, so you are enabling the business. Creating the security culture, don’t be the Dept of No. Get allies in other biz to be your security rep. Open the doors of communications, get out and engage w other teams to understand WHY a developer is going around security processes.
How do you move from Dept of No to being strategic to the biz? Bring in talented people that have more experiences, and set aside time to add certs and keep up with the tech. Be able to communicate with customers and vendors to talk through security concerns.
How do you deal with vendors? Can’t be just check the box (SOC2 isn’t enough…). Depends on data use, threat, etc. How are they connecting with us? Social proof – not taking sales perspectives on tools. Talk to other CISO – who is using a tool, are they using a competitor?
Are security certs important? Thing like SOC2 are expected. Checklists are important reminders to help you remember to check things. Cloud Security Alliances checklist – can self-certify (esp for early companies) then drill down on things on that list that are important to you.
How do you determine risks for new tool devs want to use? In-house red team that partners with developers. Do you have an SLDC (software lifecylce development life cycle) process? Find where your gaps are with a process. Work with devs at each stage – no waterfalls!
How do you measure results? You can’t plug every risk. You can find them and give the risk to your team. Educate your team, but don’t name and shame and create a negative culture. Stop, take a break, and figure out how to get better.
Guidance to someone wanting to be in security? Look for someone with different skills, know the tech, and be curious about threats and how to fix them. Look for someone who knows how to communicate. Highlight a diversity of thought and experience. Cultivate interest in security. Get basics from certs, find a mentor, go to conferences.
What should security teams stop doing? Doing things with no value for the business. CISO has to be in line with the business, so security team can support the business. Don’t do it all yourself – find someone who has also had the problem.