Its not a bug it's a feature - Seattle B sides 2019

Editor's Notes

• #5: I once worked in a centralized security organization. We mandated requirements for software and services operating within our ecosystem. We never actively sought out feedback from the teams we pushed these requirements on to We never checked to see if there were easy paths for them to engage us when they had questions We didn't pay attention to their release timelines As a result we frequently came at these organizations from out of nowhere, with terrible timing, making demands that were laughable at best and service impacting at the worst These development organizations frequently ignored us or went around us, usually with managements blessing because we were hindering the development process while providing no value We sat in our ivory tower patting ourselves on the back for what a good job we were doing while disdainfully looking at the developers who were, in our opinion, just thumbing their noses at us. Within our organization everything looked like a well oiled machine, but externally it was next to impossible for orgs to reach out to us I left this org and ended up in a dev org working on a product that was, ironically enough, in this ecosystem I had just left One of my devs had spent 2 months trying to get 2 firewall ports opened so they could double the capacity of their dev lab. I did it in a week, but only because I went off the path and reached out to my old teams Within 3 months of joining the dev team I'd developed a strong resentment towards my old org because I now understood how out of touch they were. I now saw what a hinderance I'd been to this teams progress
• #6: Developers don't hate you, they don't hate security, that's a cop out on our part Security people are rewarded for helping the business manage and mitigate risk. Periodically we’re rewarded for saving the day Developers are rewarded for designing, implementing, and shipping features. They are rewarded for helping the company save money and make it. Don’t design your security requirements in a vacuum. This particularly applies to centralized security organizations. Make sure the people who will be impacted are in the room. Get their feedback. Do the requirements make sense? Do the developers understand what’s driving the requirements? Make sure that there’s good, two way, communication between stakeholders. This might seem like a no-brainer, but you’d be surprised how many security organizations turn inwards and start doing things that impact others without talking to them. Echo chambers form quickly, especially in centralized security orgs, and especially when those orgs feel the developers are ignoring them The easiest way to build trust and friendship with developers is to show that you are respectful of their time. Increasingly they are under timelines that make InfoSec timelines seem reasonable. If you’re getting crickets from your developers or outright hostile pushback, there’s a very good chance that your timing is way off. You’re going to get two different reactions if you engage early in the planning cycle versus coming in unexpectedly at the end Play “secret shopper”. Sure, you think you’re easy to engage with. Sure you think everything is great and people should have no problems engaging with your organization, I mean look at how good all this documentation is! Well, periodically try to engage your organization through the very channels you push people to…you may be surprised. Turns out getting 2 ports opened on a firewall was next to impossible and the security org expected everyone to be happy with a multi-month turn around.
• #8: Large external security organization comes to us with a “compliance framework” that we supposedly have to comply with Much like my last organization these requirements were drafted in a vacuum with no input from anyone else There was absolutely no benefit to snapping to this new, seemingly arbitrary compliance framework. It didn’t make us more secure, it didn’t increase our ability to onboard customers, it didn’t do anything but put a feather in this security organization’s cap. Most of the requirements weren’t applicable and some didn’t even make sense. Telling me I *HAVE* to do something when my own management doesn’t understand what you’re on about is a guaranteed way to fail
• #9: There was a huge missed opportunity here. If this organization had met with the teams they were going to put this framework on and had learned about how their products and services were structured they could have built something great. My org was driven by several principals: Reducing complexity and increasing efficiency through automation Driving customer adoption and onboarding (grow or die) If this compliance framework has been able to help with these things, we could have built a beautiful partnership. For example if this compliance framework was accepted across the company and understood by people, I would have loved to incorporate it into our platform. Similar to being able to tell a customer “We’re ISO27001 compliant” or “Here’s our SOC2”. Being able to say “We’re OSComp Level 2 compliant” and have that mean something would remove hurdles to adoption Big stick compliance. The “you HAVE to do it” doesn’t work. More importantly it’s never worked, even though a lot of veteran security folks seem to vividly remember it working (Mandela Effect) All Big stick compliance does is create division. It reinforces that borderline hate between security and development. Don’t do it. If you see others doing it, tell them to stop.
• #11: The product I was working on had between 30-40 separate moving parts to it This product had also never had any security oversight due to its internal nature, but it did have nearly a decade of technical debt My developers could care less about threat modeling. Some were even hostile to it because they knew it meant more work I found a dev lead that had previously worked on a security product and got him to humor me for a dry run of a TM session I asked him to explain to me how his service worked and how it interacted with other services As he began to diagram the service he’d periodically stop, change things, change them again, etc. When we finished he said “Get a picture of that. I think that’s the only true, accurate flow diagram we have of this service” We then started discussing the usual threat model stuff. Things like security boundaries. I would bring up customer onboarding requirements around TLS, logging, etc. Dev lead turns to me and says “I never realized how much feature work security could generate, this is great” That was the moment I realized I’d been going about this the wrong way all along. What I saw as issues to fix, he saw as features to develop/improve What I saw as compliance work I would have to “hard sell” he saw as ways to get customers onboarded faster Developer is now singing my praises, of course he’ll help me get others onboard When it was all said and done, 500 bug fixes/feature enhancements/changes were logged New development standards, such as requiring threat modeling are set in place!
• #12: Speak in terms of feature development. If you can, avoid using the word ‘security’ at all. Most developers look at security work in terms of bug fixes, which distracts from work they get rewarded for Find that one developer that has a keen interest in security (there’s always one) and get them to help you drive your feature work with other developers Developers care about reliability, a lot. Seriously. Developers also care about product adoption. If no one is using the product, it will go away. Tie your requests in with these drivers Talk about product adoption. If we do these things then we can get these types of customers Threat model with your developers early and often. Let them see with their own eyes the value you’re providing as a security person They can see early on where they’re going to need to do work They can see issues now that they can fix in the design phase that would be a nightmare to fix in production They can get a great visual idea of how their service works. Often how it works in their head and how it really works are two different things
• #13: Build trust and collaboration by starting constructive 2-way dialogue. Learn the product development cycles. Learn when it’s appropriate to engage the developers and when it’s not If you think you’re finished building out security requirements for your products and services but the product teams aren’t at the table, then you’re not done Speak to developers in terms of feature development. Most developers associate security work with “bug fixes”. Fixing bugs doesn’t fit their reward model, but feature development does Demonstrate that security features can drive customer adoption. Don’t say “You have to do this because of ISO27001 compliance”, instead say “If we implement this feature we will be able to offer this product/service to a wider customer base, including those that have ISO27001 compliance restrictions” Developers also care about reliability and performance, show how these features can improve those areas (Security is just a bonus!)