How To "Speak Developer"
âąAls PPTX, PDF herunterladenâą
0 gefĂ€llt mirâą74 views
The document discusses how security professionals can better communicate with developers by learning to "speak developer". It recommends: 1) Learning the developer's language by understanding their perceptions, working context using agile terminology, and key metrics. 2) Speaking the developer's language by imitating them, being inclusive of all roles, and being transparent about security work. 3) "Speaking" in the right places by being pragmatic, concise, and integrating security tools and documentation into the workflows and tools developers already use. The goal is to break down barriers, empower teams to build security in from the start, and help developers integrate security best practices into their rapid pace of work.
Empfohlen
Weitere Àhnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ăhnlich wie How To "Speak Developer"
Ăhnlich wie How To "Speak Developer" (20)
Mehr von Nick Malcolm
Mehr von Nick Malcolm (7)
KĂŒrzlich hochgeladen
KĂŒrzlich hochgeladen (20)
How To "Speak Developer"
- 1. Nick Malcolm How To âSpeak Developerâ @nickmalcolm
- 2. How to âspeak developerâ
- 3. Why are we getting hacked?
- 4. Why are there vulnerabilities in my software?
- 5. Do people come in to work thinking âHmmm, what buggy software can we create today?â
- 6. Why do penetration tests keep finding the same things?
- 7. Why wont they just listen to me?!
- 8. Why am I so busy?!
- 9. There is a language barrier
- 10. We need to break it.
- 11. We have skills and context on the security risks facing our organisations
- 12. We need to translate that into something that empowers teams to be better
- 13. We need to learn How to âspeak developerâ
- 14. Hi, Iâm Nick. Former software developer. Security Consultant @ Aura.
- 15. 1) Learn their language 2) Speak their language 3) âSpeakâ in the right places
- 16. 1) Learn their language Perceptions. Working Context. Metrics. 2) Speak their language 3) âSpeakâ in the right places
- 17. 1) Learn their language Perceptions. Working Context. Metrics. 2) Speak their language Imitate. Be Inclusive. Be Transparent. 3) âSpeakâ in the right places
- 18. 1) Learn their language Perceptions. Working Context. Metrics. 2) Speak their language Imitate. Be Inclusive. Be Transparent. 3) âSpeakâ in the right places Pragmatic & Concise. In their tools. Timing.
- 19. 1) Learn Their Language
- 20. How are we perceived? 1) Learn their language
- 24. Security Has An Ego
- 25. > Their perception influences how they hear what weâre saying 1) Learn their language: Perception
- 26. > We need to change their perception 1) Learn their language: Perception
- 27. Our perception of them matters too. âActor-Observer Biasâ
- 28. Other peopleâs bad behaviour is because theyâre dumb. My bad behaviour is due to factors beyond my control. 1) Learn their language: Perception
- 29. The dev teams lack common sense and donât learn. The security team is under-resourced and dealing with too many projects. 1) Learn their language: Perception
- 30. > Our perception influences how we talk to them 1) Learn their language: Perception
- 31. Understand their perception of us, and our perception of them 1) Learn their language: Perception
- 32. Working Context 1) Learn their language
- 33. > Use the words they use. Work the way they work. 1) Learn their language: Perception
- 34. Agile? 1) Learn their language: Working Context
- 35. Refinement Sessions Definition of Ready Definition of Done 1) Learn their language: Working Context
- 36. Meets Definition of Ready? Meets Definition of Done? Do it Ship It Refine it Backlog Item 1) Learn their language: Working Context
- 37. Meets Definition of Ready? Meets Definition of Done? Do it Ship It Refine it Backlog Item 1) Learn their language: Working Context
- 38. > If security isnât in the Definition of Ready, it wonât get done.
- 39. Ask if you can attend their refinement sessions. Ask about their DoR & DoD. 1) Learn their language: Working Context
- 40. Find the right âinjection pointsâ 1) Learn their language: Working Context
- 41. Donât hijack their meetings 1) Learn their language: Working Context
- 42. Epics! Features! Stories! Oh my! 1) Learn their language: Working Context
- 43. Itâs the language they use to make big to-do items in to small to-do items 1) Learn their language: Working Context
- 44. EPIC EPIC EPIC Feature Feature Story Story Story Story Task Task Task Task 1) Learn their language: Working Context
- 45. EPIC EPIC EPIC 1) Learn their language: Working Context High level Define NFRs Big security initiatives
- 46. Create a Security Epic. Figure out what goes in it later! 1) Learn their language: Working Context
- 47. Flag high-level compliance / privacy considerations 1) Learn their language: Working Context
- 48. EPIC EPIC EPIC Feature Feature 1) Learn their language: Working Context Medium Level Identify security stories âAs a secure developer I want toâŠâ Reusable patterns
- 49. âŠI want users to sign up with good passwords âŠI want to let users use 2 Factor Authentication âŠI want logs to be good, and stored safely âŠI want to detect fraudulent payments 1) Learn their language: Working Context
- 50. If other teams in the organisation have done similar things securely, you should be pointing to those reusable patterns! 1) Learn their language: Working Context
- 51. âFeaturesâ of a Security Epic: Create a Threat Model Establish and test DR metrics & plan Conduct a Penetration Test 1) Learn their language: Working Context
- 52. EPIC EPIC EPIC Feature Feature Story Story Story Story 1) Learn their language: Working Context Acceptance criteria
- 53. I canât choose a password with less than 12 characters I canât choose a commonly-used password 1) Learn their language: Working Context
- 54. Servers are configured to CIS Benchmark Automated tests continuously assure ports are closed 1) Learn their language: Working Context
- 55. EPIC EPIC EPIC Feature Feature Story Story Story Story Task Task Task Task 1) Learn their language: Working Context Low Level Code examples Test examples
- 56. > Learn how your teams work
- 57. > Friction happens if we donât adapt to their working style
- 58. DevOps? 1) Learn their language: Working Context
- 59. Continuous Integration Continuous Delivery Continuous Deployment Metrics, Metrics, Metrics 1) Learn their language: Working Context
- 60. Continuous Integration Continuous Delivery Continuous Deployment Metrics, Metrics, Metrics 1) Learn their language: Working Context
- 61. > If theyâre trying to do CD, is security a hurdle?
- 62. Deployment Frequency How often can we deploy each day/week/month? 1) Learn their language: Working Context
- 63. Change Lead Time How long does it take from âDoneâ to âDeployedâ? 1) Learn their language: Working Context
- 64. > Donât slow velocity 1) Learn their language: Working Context
- 65. > What are their rituals? What are their drivers? 1) Learn their language: Working Context
- 66. What tools do you use? Where do team discussions happen? Can I join in? Whatâs tripping you up? 1) Learn their language: Working Context
- 67. â Use outliers to shift the norm 1) Learn their language: Working Context
- 68. Identify the âstarâ team Help them lead by example
- 69. Identify the âworstâ team Youâll learn an awful lot
- 70. NORM WORST BEST NORM 1) Learn their language: Working Context
- 71. Understand their working language Start with the outliers 1) Learn their language: Working Context
- 72. 2) Speak Their Language
- 73. Imitation 2) Speak their language
- 74. How do any of us begin to learn a language? Trial and error. Over and over. 2) Speak their language: Imitation
- 75. â Imitation is not just the sincerest form of flattery - it's the sincerest form of learning - George Bernard Shaw 2) Speak their language: Imitation
- 76. Slack / Chatrooms / GIFs 2) Speak their language: Imitation
- 80. NICK MALCOLM / AURA INFORMATION SECURITY
- 82. giphy.com knowyourmeme.com 2) Speak their language: Imitation
- 83. Be Inclusive 2) Speak their language
- 84. > These are your developers! Coders, Testers, BAs, PMs, Architects, Sysadmins, Help Desk⊠2) Speak their language
- 85. Silos are a security issue. âthrown over the fenceâ == âfallen through the cracksâ 2) Speak their language: Be Inclusive
- 86. Include all development team roles, not just coders If theyâre part of the SDLC, involve them! 2) Speak their language: Be Inclusive
- 87. Everyone learns more. Everyone understand their responsibilities better. 2) Speak their language: Be Inclusive
- 88. Remember: Jargon excludes people. 2) Speak their language: Be Inclusive
- 89. â Example: Threat Modelling 2) Speak their language: Be Inclusive
- 90. â Gather the team for a half-an-hour brainstorming session. All roles should be involved. 2) Speak their language: Be Inclusive
- 91. â Who are our users? What info are they putting in? What would happen if it was exposed / changed / lost? What can we do to stop that? 2) Speak their language: Be Inclusive
- 92. â Encourage discussion Ask questions Help teams understand likelihood and impact Talk about real scenarios youâve seen. 2) Speak their language: Be Inclusive
- 93. Be Transparent 2) Speak their language
- 94. When youâre working on something that affects them, include them!
- 95. Seek their feedback. Give them ownership. 2) Speak their language: Be Transparent
- 96. Get involved. Be a familiar face. Be available. Commit to âoffice hoursâ. 2) Speak their language: Be Transparent
- 97. Build trust. Change perceptions. 2) Speak their language: Be Transparent
- 98. âTranslateâ pen test reports Provide metrics on recurring bugs 2) Speak their language: Be Transparent
- 99. > Security should happen with your teams not to your teams 2) Speak their language
- 100. Imitate Be Inclusive Be Transparent 2) Speak their language
- 101. 3) Speak In The Right Places
- 102. Pragmatic & Concise 3) Speak in the right places
- 104. Documentation should be: 1. Easy to navigate 2. Answer âwhat do I actually need to do?â 3. Answer âwhere do I look for more information" 3) Speak in the right places: Pragmatic & Concise
- 105. Anything else is a hurdle to be avoided. 3) Speak in the right places: Pragmatic & Concise
- 106. Developers donât look at standards. They look at Stack Overflow. 3) Speak in the right places: Pragmatic & Concise
- 107. Instead of 100 page âcoding standardsâ, give them something practical 3) Speak in the right places: Pragmatic & Concise
- 108. â Example: Pattern Library 3) Speak in the right places: Pragmatic & Concise
- 109. â Known-secure code snippets Hardened configurations Base projects Base tests 3) Speak in the right places: Pragmatic & Concise
- 110. Make âthe right thingâ a copy-paste away. 3) Speak in the right places: Pragmatic & Concise
- 111. Show them what âgoodâ will look like, for if they need to look elsewhere. Empower them to add new code back. 3) Speak in the right places: Pragmatic & Concise
- 112. Quick, relevant answers. Secure software. 3) Speak in the right places: Pragmatic & Concise
- 113. Be In Their Tools 3) Speak in the right places
- 114. â Example: Jira-Integrated Security Questionnaire 3) Speak in the right places: Be in their tools
- 115. â Slackâs goSDL Identifies security requirements at the âEpicâ level. Teams can DIY 3) Speak in the right places: Be in their tools
- 116. â Will this be internal-only, or production? Will it access sensitive customer data? Will you change or create security features? ⊠3) Speak in the right places: Be in their tools
- 117. â 3) Speak in the right places: Be in their tools
- 118. â Makes it less likely that issues make it to production Or show up in a Penetration Test. 3) Speak in the right places: Be in their tools
- 119. â Example: Static Code Analysis 3) Speak in the right places: Be in their tools
- 120. â Add a metric to their DevOps dashboard # vulnerabilities identified at build time 3) Speak in the right places: Be in their tools
- 121. â Make sure it integrates with code editors and testing suites too 3) Speak in the right places: Be in their tools
- 122. â Start off by accepting the existing issues, but preventing new ones. Then work through the backlog. And SHOW THEM their progress! 3) Speak in the right places: Be in their tools
- 123. > Integrate with their tools 3) Speak in the right places: Be in their tools
- 124. > Make it easy to do the right thing 3) Speak in the right places: Be in their tools
- 125. > Make it easy to spot the wrong things 3) Speak in the right places: Be in their tools
- 126. > Security built-in, and increased pace 3) Speak in the right places
- 127. Pragmatic & Concise Be in their tools 3) Speak in the right places
- 128. So. What if we lived in a world where we could âSpeak Developerâ?
- 129. Empowerment
- 130. Empowered to do the right thing, and empowered to call things out when they look weird.
- 131. Pace
- 132. Tools that help them move fast, without breaking things
- 133. Trust
- 134. Trust that when you say âStopâ, you must really, truly mean it
- 135. â Woven in to keep them going Respected enough to stop them - Laura Bell (@lady_nerd)
- 136. Recap time!
- 137. 1) Learn their language
- 138. 2) Speak their language
- 139. 3) âSpeakâ in the right places
- 140. Bridge the language barrier
- 141. because thatâs our job
- 142. Weave security in
- 144. Learning a new language is slow going. Thatâs OK
- 145. Learn from each other
- 146. Other people in this room are (hopefully!) interested in this topic
- 147. What ideas sparked? How do you approach this topic? What can I learn from you?
- 148. Take that first step.
- 149. Speak developer.
Hinweis der Redaktion
- I want to start by asking some questions. Aimed at InfoSec professionals working in organisations with software development teams
- Do people come
- Do people come in to work thinking âhmmm, what buggy code can I write today?â
- As information security professionals working in organisations with software teams, these questions come up all the time.
- Security teams feel under resourced, overcommitted, with incidents and questions and reports flying in from all over
- I think thereâs a language barrier. You might think so too, if the title of my talk drew you here. This isnât a new idea.
- But I do think itâs our responsibility as information security professionals, to break that barrier. Itâs on us. Not development teams, although their involvement is crucial. Ultimately we have the skills and knowledge that needs to be translated in to something they can understand and be empowered to run with themselves.
- We need to learn how to speak developer
- We need to learn how to speak developer
- We need to learn how to speak developer
- 6 years as a ruby on rails developer 2 years in information security. I spend most of my working week trying to do exactly this. Iâve been on the other side of the fence, and now itâs my job to empower and work alongside organisation and development teams to improve their security maturity.
- There are three things I think are a crucial starting point, and weâll talk through these today. 1) Understand how they perceive us, and what their working styles are. What drives them? 2) Observe how they interact with each other, and where, and then join in. Be present. Be transparent. Include them. 3) Donât speak to them at the end of a project, speak at the start and throughout. Make it easy for them to choose secure paths by providing guidance at the right time and in the right way
- There are three things I think are a crucial starting point, and weâll talk through these today. 1) Understand how they perceive us, and what their working styles are. What drives them? 2) Observe how they interact with each other, and where, and then join in. Be present. Be transparent. Include them. 3) Donât speak to them at the end of a project, speak at the start and throughout. Make it easy for them to choose secure paths by providing guidance at the right time and in the right way
- There are three things I think are a crucial starting point, and weâll talk through these today. 1) Understand how they perceive us, and what their working styles are. What drives them? 2) Observe how they interact with each other, and where, and then join in. Be present. Be transparent. Include them. 3) Donât speak to them at the end of a project, speak at the start and throughout. Make it easy for them to choose secure paths by providing guidance at the right time and in the right way
- There are three things I think are a crucial starting point, and weâll talk through these today. 1) Understand how they perceive us, and what their working styles are. What drives them? 2) Observe how they interact with each other, and where, and then join in. Be present. Be transparent. Include them. 3) Donât speak to them at the end of a project, speak at the start and throughout. Make it easy for them to choose secure paths by providing guidance at the right time and in the right way
- Before we can understand their context and learn their language, letâs think about how they might perceive us. What lens do they see security through, at the moment?
- Before we can understand their context and learn their language, letâs think about how they might perceive us. What lens do they see security through, at the moment?
- Too often weâre seen as people who say no all the time. Weâre in too late in the project. Donât have time to do anything except pull the handbrake.
- Perhaps we put barriers in the way to try and give ourselves some breathing space. We delay project timelines and become a source of friction, a hurdle to be overcome or smashed through.
- Another approach is to throw a book of requirements at them. We leave it to them to figure out whatâs relevant and whatâs not. If they miss Section 54 Point 12 Subsection D and overlook a requirement, we can pass the blame and say âtold you soâ. https://media.giphy.com/media/8Ue8ekoT67ylq/giphy.gif
- Ego Patronizing Jargon â itâs easy to overcomplicate language, and can be a way of posturing power dynamics Forcing every change to go through them
- How do they perceive us?
- Whether their perception is fair or right doesnât matter.
- There is something called the Actor-Observer bias. Where we attribute other peopleâs behaviour to something intrinsic to them, and our behaviour to things we canât control. Thereâs a thing called the âActor-Observer BiasââŠ
- Before we can start to speak their language, we need to recognise our own biases that might prevent us from putting in the effort. Most people donât come to work wanting to do a bad job and build buggy apps.
- Now that weâre more aware of their context and our own context, letâs look at the context of how they work. We donât want to try and force a square peg through a round hole. Are they working with waterfall, agile, devops, something in between?
- Pitch your security requirements at the right level. Understand what their levels are.
- Pitch your security requirements at the right level. Understand what their levels are.
- If you donât influence the refinement of a story, or get security into the definition of ready, things will be done without security involvement. If you canât fit in to this workflow, itâs likely that youâll cause friction in your team.
- If you donât influence the refinement of a story, or get security into the definition of ready, things will be done without security involvement. If you canât fit in to this workflow, itâs likely that youâll cause friction in your team.
- Respect their time and agenda Donât hijack their story refinement sessions in to a âtell security what youâve been doing for the last monthâ
- Stories: Design Reviews Threat Modelling, Pen test, etc
- This is an important spot to get in to
- How fast are they trying to deliver? Where are their sources of friction? Are these changing? What metrics are important to them? How can you build that into your own success metrics? Adopt their language of success.
- How fast are they trying to deliver? Where are their sources of friction? Are these changing? What metrics are important to them? How can you build that into your own success metrics? Adopt their language of success.
- Donât focus just on the number of findings. The focus initially should be proving that security tools can be added to the pipeline and add value without dragging down velocity.
- What are the injection points where you can get in early, with just the right amount of effort to say the right thing.
- Identify and start with the âstarâ teams, so others are led by example. Then work with the âworstâ team. By working at both ends of the scale, the median will rise. If you can establish a relationship with both of those teams, youâll have learnt an awful lot about how to work best with the other teams.
- Graph of using outliers to shift norm
- Graph of using outliers to shift norm
- There are theories on how we learn language, and imitation is one we can understand. When you hear a young child learning to talk, imitation is so common. Trial and error. Repetition. The same applies to us when weâre learning the language of our developers.
- There are theories on how we learn language, and imitation is one we can understand. When you hear a young child learning to talk, imitation is so common. Trial and error. Repetition. The same applies to us when weâre learning the language of our developers.
- If youâre seen as an outsider, own it! Poke fun at yourself. https://media.giphy.com/media/Exs0D5k1MpoRO/giphy.gif
- If someone does a good job, praise them
- Drake meme
- If you have to use a ban hammer, at least make it fun!
- If theyâre invovled in the Software Development Lifecycle, theyâre âdevelopersâ!
- Silos exist. You need to know if things are being âthrown over the fenceâ, and should make it part of your job to make sure everyone is aware of their roles and responsibilities.
- When youâre working on something that effects them, include them!
- Get involved in onboarding. Ask to go to team meetings. Let them know youâre approachable, reasonable, not scary, not here to say no. If they use a chatroom, hang out in there sometimes so that youâre part of the team. Have office hours at least. A couple of hours a week where you clear your schedule to be available. Let them know when youâre free and when youâre not, so they can time things to match.
- Get involved in onboarding. Ask to go to team meetings. Let them know youâre approachable, reasonable, not scary, not here to say no. If they use a chatroom, hang out in there sometimes so that youâre part of the team. Have office hours at least. A couple of hours a week where you clear your schedule to be available. Let them know when youâre free and when youâre not, so they can time things to match.
- Penetration tests arenât a big hammer to whack teams with You need to translate the findings into something they can understand and learn from Track the categories of bugs, so that they know where to focus
- Policies, Standards, Guidelines need to meet these three criteria to be useful to development teams. Anything else is a hurdle to be avoided, a time sink where effort expended exceeds value gained.
- Policies, Standards, Guidelines need to meet these three criteria to be useful to development teams. Anything else is a hurdle to be avoided, a time sink where effort expended exceeds value gained.
- Policies, Standards, Guidelines need to meet these three criteria to be useful to development teams. Anything else is a hurdle to be avoided, a time sink where effort expended exceeds value gained.
- Policies, Standards, Guidelines need to meet these three criteria to be useful to development teams. Anything else is a hurdle to be avoided, a time sink where effort expended exceeds value gained.
- Why do developers love SO? Because you can copy paste code that probably works. As security people, we know that code is often buggy or vulnerable in certain contexts.
- Build your own go-to library where the right thing is just a copy-paste away. Let teams build on these, and create new ones. Have more than just code, have unit and integration test cases that testers can run with too. Mention pen tests again
- If your teams are creating Epics, get in early with some questions. Here are three, but you should aim to ask about 10 questions. They should be able to answer them themselves
- If your teams are creating Epics, get in early with some questions. Here are three, but you should aim to ask about 10 questions. They should be able to answer them themselves
- If your teams are creating Epics, get in early with some questions. Here are three, but you should aim to ask about 10 questions. They should be able to answer them themselves
- Empowered to do the right thing, and empowered to call things out when they look weird
- Empowered to do the right thing, and empowered to call things out when they look weird
- Empowered to do the right thing, and empowered to call things out when they look weird
- Tools to help them move faster
- Empowered to do the right thing, and empowered to call things out when they look weird
- You trust them to do the right thing, and they trust you when you say something really ought to be done
- Empowered to do the right thing, and empowered to call things out when they look weird
- Easy to understand. Easy to act.
- Easy to understand. Easy to act.
- Itâs hard to learn a language, so allow yourself time. Donât be surprised if itâs a slow process. Language is hard to learn, and trust can be hard to gain.
- We all know that talks are sometimes the most useless part of going to a conference, and I won't presume I've done a great job myself. But take a look around you. You've all just spent 40 minutes in the same room, hopefully because this topic means something to you. As you leave to enjoy the rest of the conference, take the time to ask to ask others how they approach this issue. How they work with and empower their development teams. What ideas sparked out of this talk for you? What could you learn from others in the same position as you? Or from those who have already made some progress? Share your learnings with others. Use each other to raise the bar. And together we can weave security into the fabric of all we do. Thank you.
- We all know that talks are sometimes the most useless part of going to a conference, and I won't presume I've done a great job myself. But take a look around you. You've all just spent 40 minutes in the same room, hopefully because this topic means something to you. As you leave to enjoy the rest of the conference, take the time to ask to ask others how they approach this issue. How they work with and empower their development teams. What ideas sparked out of this talk for you? What could you learn from others in the same position as you? Or from those who have already made some progress? Share your learnings with others. Use each other to raise the bar. And together we can weave security into the fabric of all we do. Thank you.
- We all know that talks are sometimes the most useless part of going to a conference, and I won't presume I've done a great job myself. But take a look around you. You've all just spent 40 minutes in the same room, hopefully because this topic means something to you. As you leave to enjoy the rest of the conference, take the time to ask to ask others how they approach this issue. How they work with and empower their development teams. What ideas sparked out of this talk for you? What could you learn from others in the same position as you? Or from those who have already made some progress? Share your learnings with others. Use each other to raise the bar. And together we can weave security into the fabric of all we do. Thank you.