On this week’s episode of Security Nation, we had the pleasure of speaking with Oliver Day, a security professional working for a medium-sized publisher. Prior to working at this publisher, Oliver started a nonprofit providing security services to other nonprofits. He also spent some time working at Rapid7, so we were pleased to have him back with us. Oliver spoke about learning to work with engineering teams on security initiatives, rather than against them.
Here is our recap of the podcast:
Patience and empathy for better organizational buy-in
Oliver took a role that was originally meant to be DevOps, but the organization added security engineering to his role due to his background. In the beginning, he spent most of his time observing how the DevOps team worked and soon began contributing to the code infrastructure. Eventually, the company encountered a security crisis and he was able to integrate the role of security advisor into his role as a DevOps team member.
Oliver found that patience and empathy were two main components of implementing a security operations process that worked for the organization over the long-term. As one of his advisors told him, “Every CTO should be a CEO once, so they learn how to sell.” In the same way, security team members should spend time on other teams so they can understand the business needs from another perspective.
In that light, Oliver spent time asking non-judgmental questions of the organization’s processes, figuring out which of the processes opened the organization up to risk had valid business justifications. He worked to gain trust throughout the organization by asking the why behind their risks and giving them the benefit of the doubt that security risks weren’t intentional on their part. For example, it also took Oliver two years to convince his superiors that a specific policy opened them up to a hack in a very avoidable way. Where others may have been impatient and quit, in the end he was able to make small incremental changes that added up to big security advancements.
Oliver found that by establishing the value of security tools rather than enforcing requirements around using tools, he got less pushback from fellow team members on implementing new security processes. Team members would actually apply security procedures to other processes organically because they saw the value in the procedures.
Learn to speak your stakeholders’ language
During his time working in security, Oliver was surprised that the organization assigned him to work on privacy issues. He quickly learned that the organization considered privacy part of security, even though, technically speaking, privacy is more of a legal issue than a data security issue. Still, Oliver found that accepting that they thought his job encompassed privacy meant that he could be taken more seriously in pushing through security goals. In essence, he had to learn to use the language that the stakeholders used, instead of trying to correct them, to get his goals accomplished.
This is also a good idea when working with engineers, Oliver says. He learned from a blog post that using the language of agile when working with engineers would give you a better way to communicate with engineers on security matters. He learned JIRA and how to break processes into stories, then found he could approach engineers with a JIRA ticket. At that point, the engineers would begin to work on the initiative like it was any other assignment, finding different ways to implement it or setting it into a timeframe that would affect the company’s other organizational goals.
Learning to speak the engineer’s language removed the need for SecOps to be the “bad guy,” constantly looking for flaws and imposing corrections. Instead, the effort introduced a more collaborative environment where engineers were willing to include security in the code from the very beginning. This saves everyone a lot of time, effort, and heartache.
Add in humility to truly get the job done
Oliver reminded us that humility is often the key to ensuring good work gets done, no matter what you’re tasked with. For instance, understanding that just because you’re a good security professional doesn’t mean you’re good at coding or policymaking. Furthermore, the very best way to build a good program is to include experts who are better at certain aspects than you are. Respecting the expertise of others is paramount to building a program. It can be a difficult pill to swallow, but a little humility can be the difference between a security program that works and one that is a waste of time for everyone.
Focus on your relationship with the product owner
In order to build a security program like Oliver’s, he suggests that you work on building a good relationship with the product owner of any product you’re trying to improve from a security standpoint. The reason is simple: The product owner controls the flow of resources, time, and energy that goes into the product. Cultivating this relationship will give you a better chance of having your security improvements be taken seriously. By developing mutual respect and a working relationship with the product owner, you can both trust that your initiatives will be met, even if it’s not as immediate as you would like.
Listen to the full interview
We’d like to thank Oliver for sharing his story. To hear Oliver’s interview in full, be sure to check out our latest episode of Security Nation, and if you like what you hear, please subscribe!