security for humans

19
SECURITY FOR HUMANS

Upload: conjurinc

Post on 20-Jan-2017

300 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: Security For Humans

SECURITY FOR HUMANS

Page 2: Security For Humans

I am Dustin Collins

Organizer of the Boston DevOps meetupDeveloper Advocate at Conjur

Page 3: Security For Humans

THIS TALK IS NOT ABOUT⊡patching exploits⊡network security⊡container breakout⊡insider threats⊡cloud⊡encryption⊡intrusion analysis⊡security tooling

EXPECTATIONS

THIS TALK IS ABOUT⊡integrating security

into modern workflows⊡managing conflicts of

interest

Page 4: Security For Humans

I'm sorry, Dave. I'm afraid I can't do

that.

Page 5: Security For Humans

high risk, low reward

Page 6: Security For Humans

UNINTENDED CONSEQUENCES

Page 7: Security For Humans

EXAMPLES, PLEASE

⊡ Needs to use a new API to fetch geodata

⊡ Downloads the secret token⊡ gitignores it for development,

keeping it out of source control⊡ App now breaks in production

DEVELOPER

Page 8: Security For Humans

EXAMPLES, PLEASE

⊡ Needs to roll out containers for internal PaaS

⊡ Bakes secrets into Docker images

⊡ Password rotation now requires a redeploy of application

OPERATIONS

Page 9: Security For Humans

EXAMPLES, PLEASE

⊡ Needs to keep an inventory of running services

⊡ Rolls out a tool to do it through an internal web dashboard

⊡ With no API available, is now a bottleneck to launching new services

SECURITY

Page 10: Security For Humans

EXAMPLES, PLEASE⊡ Signs a contract with a vendor

for identity management solution

⊡ Only works on AWS⊡ Dev workflow is full of

workarounds⊡ Ops is constrained to one

platform⊡ Security isn’t happy with built-in

reporting

BUSINESS USER

Page 11: Security For Humans

THE DONNER PARTY

Page 12: Security For Humans

“Addressing the individual needs of the distinct User Personas, and paying

special attention to the points at which their needs intersect is the key to driving adoption, usage, and ultimately

delivering a successful product experience.

Dan Warner, Director of UX @ Conjur

Page 13: Security For Humans

App Developer (engineer)Primarily responsible for feature work. Lives in a Continuous Integration workflow. Supports lots of fun tools locally, but has disdain for imposed “dependencies.” Skills: Typical Python development stack, Vagrant, Homebrew...Equipment: Command Line. IDE. OSX. Laptop with multiple virtualized dev environments.Quotes:“Trying to figure out how to integrate with your system is not a great use of my time.”“It works on my laptop.”Stories:

● As an app developer, I want to write and test features without thinking about security, so that I can continuously deliver.

● As an app developer, I want the code I write to work in prod the same way it works in dev and test, so that I don’t have to spend cycles troubleshooting with QA.

Page 14: Security For Humans

OPS Guy (sysadmin, DevOps *, IT Admin, * of Operations)Primarily responsible for architecting and maintaining IT infrastructure including CI pipeline, SOX (and other audit) compliant data environments, controlling automation costs.Skills: A working knowledge of many diverse technologies — Ruby, ELK stack, Chef, Docker, Stackdriver, Bash Scripting, AWS, Jenkins, Nagios, vagrant...Equipment: Command Line. OSX. Laptop with multiple virtualized dev environments. Homespun Ops Dashboard. The UI’s of various tools like Jenkins and Kibana.Quotes:“The people in the meeting are going to be suits. Rather than show them some command line interface that they don’t understand, I would like to run it through a nice web interface.”“Which of the users on the product team have accessed this secret? When was the last time someone on the product team accessed this secret?”Stories:

● As an ops guy I want to see who has accessed a particular secret (or server, host, etc.), so that I can report to the responsible parties.

● As an ops guy, I want easy queryability (like Facebook search), so that I can find what I want quickly and do some level of discovery.

● As a (less technical) IT Admin I want to be able to spin up a secure server from a GUI.

● As an IT Admin I want to easily identify anomalies in secrets access, so that I can focus my time where it is needed.

Page 15: Security For Humans

Security User (CISO, InfoSec, * of IT Security)Primarily responsible for data security, DLP, incident response, audit and compliance. Skills: A high level understanding of the potential risks posed by new technologies. Equipment: Reports. Dashboards. PowerPoint. Google Docs. Email. Mobile alerts. SIEM.Quotes:XX REDACTED XXStories:

● As a VP of IT Security I want a blueprint for launching a secure server in a non-secure location, so that my team can leverage the public cloud.

● As CISO I want to choose tools that integrate with existing systems and make my team happy, so that my choices don’t slow my team down or demotivate them.

Page 16: Security For Humans

Business User (CIO, CTO, VP IT, Project Manager)Primarily responsible for aligning IT Strategy with the Business Goals, driving efficiency, building and motivating the team, making decisions about where to invest IT dollars, SOX (and other audit) compliant data environments, controlling cost.Skills: High level understanding of many, diverse technologies.Equipment: Reports. Dashboards. PowerPoint. Google Docs. Email.Quotes:“Chef. Docker. Puppet. Amazon. On-prem… we use all of the above.”“I know we are doing DevOps. I’m just not 100% sure what that means.”“My top concern is SOX compliance.”Stories:

● As CTO I want to see who had access to a secure DB server and when, so that I can comply with my SOX strategy.

● As CTO I want real-time, self-service reporting and SIEM integration, so that I know this data is part of our complete security picture and nothing is falling through the cracks.

● As VP of IT I want a blueprint for launching a secure server in a non-secure location, so that my team can leverage the public cloud.

● As VP of IT I want to choose tools that integrate with existing systems and make my team happy, so that my choices don’t slow my team down or demotivate them.

Page 17: Security For Humans

⊡Create and maintain user personas⊡Conduct user interviews⊡Share data with stakeholders⊡Mediate post-mortems for security issues⊡Raise the visibility of how security works

CROSS-FUNCTIONAL SECURITY UX TEAM

SUGGESTION

Page 18: Security For Humans

THINGS TO AVOID

⊡ Developer workflows that depend on gitignoring credentials

⊡ Credential rotation schemes that require redeploys⊡ More than one way to access credentials that depends on

the environment⊡ Cloud-specific solutions⊡ Security tools without programmable APIs⊡ Shoehorning security into collaborative tools - it limits

their effectiveness (Chef, Jenkins, etcd, Docker)⊡ Not checking your security policy into source control

(plain text is better than nothing)

Page 19: Security For Humans

THANKS!

Any questions?You can find me at

@[email protected]

dustinrcollins.com

Presentation template by SlidesCarnival