Six Years in Review: Transforming Company Culture to Embrace Risk

please for our next session uh join me to welcome Ariel who will be speaking to us about six year in we six year in six years in review transforming company culture to embrace risk

area thank you everyone for attending my talk I'm excited to take you on a 6ear journey of a single program that transformed company culture my name is Ariel and I'm a product security engineering manager at twilio I started my career off as a pentester then I worked in absec at1 medical then ABC at segment which got acquired by twilio I've now been at twio for almost 3 years and I managed the product security reactive team we focus in securing the second half of the stlc and preventing vulnerabilities from becoming incidents a quick breakdown of what we'll discuss today I'll share some context what is vulnerability management and why does it matter I'll take you on

on tlio in segment six-year Journey then I'll discuss the stages of a vulnerability Management program one of which is a democratized approach I'll discuss the components of a democratized approach and answer if this approach even works then I'll wrap things up and leave some time for questions disclaimer we all work in security so you all know I can't tell you everything names have been changed to protect the innocent metrics have been fictionalized due to lack of company approval but it's very fitting since I'm presenting on this gigantic screen used to share movies so treat this like you're watching any movie based off a true story some of it's true some of it's fake for drama and to

prevent me from getting sued let's dive in on everyone's favorite topic what is vulnerability management Microsoft has a very standard definition it's a risk-based approach to discovering prioritizing and remediating vulnerabilities and misconfigurations why do we need this for a lot of folks in this room vulnerability management is a noisy NeverEnding ticketing system the backlog continues to grow as more tickets come in every day you never have enough time to tackle it all this program is a massive undertaking but one you need to manage the chaos you create a workflow or a process so that you can act quickly communicate clearly and prevent an incident before it's too late if you work at a public company your C so may

have also asked you to build or expand your vulnerability Management program so that can properly disclose exploited vulnerabilities in their AK what is democratized vulnerability management you may have heard me say democratize one too many times in the agenda at segment and at twio we call our vulnerability management process democratize vulnerability management or DVM for short and this differs from a traditional vulnerability Management program because we shift the responsibility and accountability of vulnerabilities from the security team to engineering teams if you're a bit skeptical of how how we do this don't worry we'll dive into that during this talk which is a great segue for the next question what is the goal of this talk

my goal is to convince you that democratizing your vulnerability management process is an effective way to scale security vulnerabilities will be a constant for engineers a security team must build a strong security Culture by empowering Engineers to own risk let's travel back in time to 2018 6 years ago segment launch dbm this program found a lot of success that segment engineers and leaders were engaged in driving down risk as the company Grew From 300 to 450 the security team continued to iterate and grow this program twily acquired segment and in 20121 our security teams merged I started at segment security team for about 6 months before I started supporting toio and I observed that Engineers would wait for security

Engineers to chase them down when they breached SLA this was because the process was so complicated there were three different processes depending on which security engineer identified the vulnerability and you couldn't measure breach desas for all vulnerabilities present at twio segment had a strong security culture and a strong track record of success too Engineers often ignored security vulnerabilities and you couldn't measure the state of all vulnerabilities we strongly believe that democratizing vulnerability management was important for scaling security at twilio we launched TVM at Tulio 2 years ago and I live to tell this tale not only did we find success in our vulnerability Management program but we also had interest from other teams in joining forces to democratize more than

just our vulnerabilities and include risks and post-incident action items today our program continues to reach New Heights as this has become a core component of our company culture instead of ignoring risk our Engineers Embrace risk and this culture shift is not only evident through faster remediation timelines but also in the inclusion of security in everyday engineering discussions and road maps the format of this talk is going through the iterations of a vulnerability Management program why we chose to iterate to reach our current state stage one you start with spreadsheets to track all of your data we've all been here there may be more than one spreadsheet and you don't have a single method or format for reporting

vulnerabilities but this will do for now as you focus on more pressing issues generally you move from spreadsheets to an official system as a natural outcome of a company maturing and needing to scale you may have received an influx of emails to your security at or a friendly nudge from your compliance team and the key feature in this transition is that you move to a single system most often a ticketing system you now have a traditional vulnerability Management program and you may have observed that your security Engineers are burnt out from chasing Engineers breached slas and a general lack of investment from engineering as your backlog continues to grow scaling becomes your number one priority so you move over to a

democratized approach when we launched a democratized approach ad segment our program had four pillars the first pillar is Engineers own risk and are accountable for vulnerabilities our features explicitly call this out that Engineers own risk vulnerability tickets are assigned to risk owners instead of assignes and risk owners are engineering managers or product managers responsible for the risk of a product service our second pillar is self-service due date extensions since Engineers own risk our default process allows Engineers to request duate extensions with their engineering VP director or themselves depending on the severity of the ticket this means that if an engineering team can't fix a high priority vulnerability they would work with their leadership team to get an

extension leaders are a lot more accountable for vulnerabilities in their org when they put their name on each vulnerability our third pillar is transparency vulnerability reporting in addition to a description of the vulnerability you include the severity description why was this vulnerability prioritized as a P1 instead of a P2 a critical instead of a high this means that Engineers can review these tickets and negotiate the severity you also provide a criteria for remediation you clarify explicitly what the expectation is for engineers to Mark a ticket as remediated our fourth pillar is visible and meaningful metrics that you report on to drive accountability within the the engineering org at segment monthly emails were sent out to engineering on

the debt within the org and action items to drive down that debt these four pillars guided our program successfully at segment Engineers own risk self-service duate extensions transparent vulnerability reporting and visible metrics we were so confident that this program would succeed at twio this program was built to scale and we were ready to tackle 17x growth [Music] however when we launched this program at twio the pillars started to crack we had scale challenges we hadn't experienced before Not only was twio a much larger organization with many mergers and Acquisitions twio had a completely different culture and I can feel these pillars crumbling on top of me for many months I was being crushed and I felt

that this project was impossible with time and an amazing team beside me we're able to add a few more pillars and strengthen our program and accomplish The Impossible let's dive into where things can go wrong and how we can overcome those challenges first up is leadership buyin leadership buyin is crucial to the success of your democratized vulnerability Management program vulnerabilities are resource intensive so leadership bind ensures that you have the resources to build out this program effectively a democratized program requires folks to be engaged with security so leadership Buy helps Drive accountability and build trust at twio we faced many different types of challenges when it came to leadership buyin that we had an experienced before

at segment segment not only had a smaller leadership group but one that was also more aligned with a democratized approach the stakeholders that constitute your leadership group can vary depending on your organizational structure but generally includes that the highest levels your ceso head of security VP of security and at the lowerer levels all of the leaders of team teams that own parts of the vulnerability management life cycle this can be the manager of the vulnerability management team the risk team the security platform team and all of the teams that report vulnerabilities from their tooling such as product security and Cloud security when we were preparing to launched TVM at twio we faced a lot of

initial resistance from the cloud security team the risk team and the vulnerability management team Twi had just acquired segment and we were coming to make changes to existing programs a lot of folks felt that we were coming in very opinionated with big changes to an organization we didn't understand and this was true we didn't understand twio fully and yet we held strong beliefs that DVM was the only way to scale this program we conducted interviews across security and engineering and shared out an initial report of the current state of vulnerability management the pain points and how a democratized approach can solve it the report conclusion was met with a lot of push back and we

utilized a two-pronged approach first we relied on our bot and leaders to create buying with additional leaders we had high level leadership support due to impart with the ceso coming from segment so we relied on the ceso to influence other leaders and encourage them to move forward with dbm while leaders were bought in at a high level there were still questions and concerns we had to resolve our second approach was that we adopted our message to the different managers to the group and strive to resolve their concerns colge security had very tactical concerns they wanted to see a workflow and understand the engineering resources needed when committing to a project like this they also wanted a pilot to be conducted as

an engineering team they wanted to test the solution before buying into it the vaul management team on the other hand had concerns about big picture what is the vision of this program and how would our policies and standards adopt the RIS team had a lot of skepticism so we relied on evidence from the segment's program to build trust they didn't trust that our program could accurately capture risk so we worked on showing that not only can this program reduce risk but also free up time for them to focus on larger risk initiatives instead of just individual risk tickets in total we created around 42 documents three slide decks over three quarters to get the necessary leadership

buy for this program while this was an expensive step this was a key requirement for ensuring that this program was set up for success in summary some challenges you might face is a lack of alignment with the democratized approach and this could be because they don't understand it fully teams may be resistant to change or teams may be again centralizing due to the need to share resources especially if teams are siloed there may be complex bureaucratic processes for obtaining approval and this is true for some larger organizations there may be high turnover in leadership positions often times we hear that cesos change annually and this is one big consequent of that if your leadership group changes you have to

regain that buy in leadership may also have competing priorities that take precedent over the vulnerability Management program making it challenging to secure their attention and commitment to this program our Solutions are to adapt your message to the different types of leaders in your group whether that's tactical Vision or evidence showcase your successes and outcomes to engage leaders don't just share your intentions speak to the business outcomes that leaders care about identify and leverage your influential allies and understand that leadership buying is the most important step do not move forward without it next upep is engineering buyin now that security leadership is on board your next step is to get your engineers on board generally your

Engineering Group consists of engineering managers directors VPS and your early adopters can also include staff Engineers I wanted to share two stories that represent the extreme end of our engineering bin Spectrum Bob really embraced our approach when was able to move faster than we could he was a champion for her program in many ways he filled in the gaps with ownership in our org he provided feedback through each iteration and he created dashboards that ultimately became the design for future dashboards ruled out to all of engineering most importantly he showed us a path forward for other engineering leaders like him to stay accountable he held weekly meetings to talk through security vulnerabilities with other engineering leads fostering a culture of

coll collaboration and shared responsibility he was the best supporter we could have asked for he not only voiced support for our program but he played a pivotal role in guiding adoption at twio Alice on the other hand was really resistant she had heard that security was launching this democratized approach and told us in other words that this project will fail Engineers are going to ignore tickets being created in a centralized project we should instead be creating tickets in a backlog or else the team will never get the work done we ultimately move forward without Alice's approval and it's important to understand that not every single engineer will be on board this can feel really scary because engineering support

is a good predictor of adoption we chose to proceed without 100% engineering buy because we had strong backing from influential engineering leaders and Leadership we faced an additional challenge of engaging leaders when it came to scale when I was supporting segment I could hop on a zoom call to to hash out a security concern with an engineer it was no problem at a company of 8,000 and 100 person security team that was no longer possible we introduced the concept of a biso or a business unit ceso so that each engineering or would have a security representative one of the responsibilities of abisa was to lead a weekly operational trust review meeting this is a weekly meeting in

which engineering leads sync with their security Representatives on their top security risk this group would review dashboards of all of the vulnerabilities present within their Buu and leaders would provide context on remediation timelines and their engineering bandwidth for instance they might tell us hey we need to be prioritize security issues for this month as we focus on migrating off this end of life service BOS would also work with engineering leads to identify tickets without owners and lastly this was an opportunity for security to get continuous feedback from engineering leads in summary some challenges you might face is Engineers may be resistant to change they may be comfortable with the current process and a new process

requires more work and no guarantee that it'll improve anything lack of incentives with a demanding workflow Engineers may not see the direct benefits or incentives of actively participating in a vulnerability Management program without clear incentives or rewards for their involvement engineering buyin can be challenging this new change was communicated poorly folks may be confused or skeptical about this process some of the methods that we used to engage our engineer was getting input from Engineers early and often during our transition to democratize program we wrote down their pain points resolved them and followed up with them and this helped us find our earlier adopter like Bob who helped adapt our program to too's size and culture once again Bob

helped us create the early designs for our dashboards we created different dashboards depending on the roles engineering had dashboards that showed tickets assigned to them and Engineering leaders had more highlevel Dash exps on Trends and top risks the role of the biso or the mini ceso helped us develop key Partnerships with engineering leads and our weekly operational trust review meetings with the support of Bob we expanded those weekly meetings to additional business units so that engineering leaders could chat about top security vulnerabilities and risks with a security partner you've now created Vine with your leadership group and a few engineers and now you have to bring awareness to the entire company when you try to get Engineers involved a new

program processor tool it's very similar to a marketing concept called the buyer Journey the buyer journey is when you're trying to acquire new customer it's important to adapt your message and your resources depending on where your customer is in the buying Journey if your customer base is unaware of your product it doesn't make sense for you to launch a loyalty product through a buy n get 10th product free instead you need to focus on building awareness through Billboards ads sometimes even cold calls to ensure that your customer is aware of you when we first started to plan to launch the newest iteration of vulnerability management we copied the same exact Playbook from segment we sent out a sock

message like this one pictured here to an engineering wide Channel we sent out an email to all Engineers we created a primer on how this new process work and in each ticket we included instructions how to follow the process and engage with security we even took one additional step we created a 4-minute demo that replicated the primer for audio visual Learners across our Global teams we padded ourselves on the back and checked off create awareness in our checklist we observed a couple of signals that our work was not yet done you can see in this slack message we have six reactions five of which was from security and one was a software engineering intern so thank you Kevin

the intern we also received a lot of comments that they didn't understand how this process worked or questions that were already answered in our primer after we recognized that our initial awareness efforts had no impact on engineering we decided to go on a road show to all 32 business units at tlio we had a 10-minute presentation prepared that walked through the workflow and frequently asked questions this presentation just really reflected the primer but we found success at twilio because twio has a strong meeting culture other methods like email and slack had become white noise so this was our only effective tool that allowed us to create the awareness we needed for some of the business units this was the

first time that they ever had the opportunity to speak with security they felt ignored so showing up to their meetings showed that we cared and went a long way in building Goodwill in summary some challenges you might face in creating awareness is complexity a new vulnerability management process can seem complex and hard to digest for large audiences especially if they don't feel engaged for larger and more diverse audiences it can be a logistical Nightmare and timeconsuming to tailor each awareness campaign to suit everyone's needs finding a consistent and impactful Communication channel to engage a diverse audience can be challenging should you use a slot Channel an email Dro or 30 Plus Engineering meetings and awareness efforts are not always

scalable maintaining interest engagement and focus on vulnerability management requires continuous effort and resources that may not always be readily available at scale our Solutions were that we utilized our primer those Wiki articles instructions and recordings while they had a limited reach it ensured that we had one consistent method that was accessible to everyone we leaned on our leadership team to socialize our new process on our most successful Avenue in creating awareness was a road show a democratized approach requires engaged participants next up is ownership in order to remediate a vulnerability you need to know who is responsible for fixing that vulnerability this is an intimidating and a thankless task for many like many in the tech industry we're affected by

the layoffs we were dealing with the impact of the news while getting alerts on inactive owners all across our org we were struggling to keep up with the ownership changes or the absence of any new information on who the new owners are often times we just couldn't find an owner and the ticket would stay with the security team in needs security triage meaning it was up to security to find the new owner one of the core pillars of DVM is that Engineers own risk that means they own the the risk for not having a clear owner for their product or service this should be on engineering to find the new owner not on security in

practice we would often see behaviors like this where engineering teams would push a ticket back to need security triage happened more than a few times it actually happened quite often the security team would try to keep up with the changes but we're manually writing down owners our information was going stale at a rapid rate we have a help Channel which would constantly get flooded with mess Mees like this this ticket isn't mine how do I get my name off of it and we received a lot of recommendations from engineers and leaders to throw security resources at a Band-Aid solution for the ownership problem but it was important for us to ensure that this was a problem

engineering solved instead we socialized the engineer the ownership Problem by letting engineering leads know how many hours were spent finding accurate owners and how those delays pushed off remediation and led to breached slas luckily we found some great engineering Partners one year ago segment cleaned up their ownership information in a quable catalog and created a jur integration for us to use the statea and our security tickets and this was huge you can see in the first ticket Patrick is trying to get his name off a ticket in the morning and then in the afternoon he had signed up to solve the ownership problem for all segment vulnerability tickets all we have to do now is include an asset in a

vulnerability ticket and ownership information autop populates and auto refreshes to this day this is my favorite feature I do want to call that this is something we currently only have at segment we're continuing to influence toio but this is difficult to do as most individual engineering managers do not care about the cost of the entire ownership problem for all of engineering this makes it really difficult to shift the ownership problem to engineering when you interact with an individual engineering manager they just want you to take their name off of a ticket that they know doesn't belong to them and you want them to help you find the right engineering manager and influence their org to provide clear and accurate

ownership data there are a couple of challenges with ownership that probably feel familiar to many of you ambiguous owners if there are multiple teams that own a product a service has been deprecated a reor you just don't know who the owner is or why turnover your previous owner no longer works at the company you have no idea how to find this new owner lastly it's individual engineering managers do not bear sole responsibility for the lack of clear ownership so it's difficult to motivate action for the greater good R2 Solutions won't solve all of your problems but this helped us Trend towards the right direction attribute ownership upwards this tends to be more stable during reorgs and

departures and quantify the ownership problem what is the cost of not having clear owners for every single vulnerability ticket not being able to assign tickets quickly socialize those costs to engineering leaders to influence more structure and organization around ownership the ownership problem is not up to security to fix but it is our job to advocate for an engineering solution our last pillar is noise a vulnerability Management program tries to create some order amongst all of the noise but there's still too much noise the more securing tooling you add the more noise you add the more people ignore you the more noise you create to get their attention how do you make noise less noisy how do you make folks

pay attention when they've started to block out all of the noise we had received this message from VP who' received 70 emails in 2 months we'd actually purposely did this we had set up our email notifications so that if you were not triaging and remediating your tickets in a timely manner you and your leadership chain would continue to get emails this wasn't just Joe many individuals had flooded inboxes as they were experiencing The Growing Pains of transitioning from a culture in which ignoring tickets was tolerated to a culture in which you needed to actively engage in a address tickets in a timely and consistent manner with a huge backlog of debt engineering wasn't going to fix all of

this overnight we were going to further alienate the individuals who already had a strain relationship with security or this was going to strain the relationship for us before we can even improve how we notify in a large volume we had to reduce the volume for an organization that was just regularly starting to tackle their debt as a security organization we chose to prioritize remediation of critical and high vulnerabilities our p1s and our p2s we would build a Security Muscle for the most pressing issues and then expand our Focus to lower severity issues our p3s and p4s many of you may be thinking that's exactly where my program is at and there's no end in sight this is in part due to the law of

diminishing returns the first slice of chocolate cake is a joy to consume that ninth or 10th slice is downright miserable p1s are easy to get attention on and remediate quickly p3s and p4s are difficult to get any movement on as we worked on building a Security Muscle and encouraging Engineers to embrace risk we not only saw a reduction in criticals and Highs but also reduction in our mediums and lows Engineers started to include security fixes in their workflows and road maps and we would see comments like this in the engineering team room our goal is not to ignore lower severity findings forever our goal is to build a muscle so that Engineers own risk and sustainably drive down

their debt we also had to help these poor inboxes out we created a sock Bo digest that allows us to group all tickets pending action on an individual and send just one message this feature is still in development but we're hoping that this makes noise become less noisy in summary some challenges we face is that Engineers are overwhelmed by the high volume of findings CU they don't have the bmth to handle them all if they're used to ignoring security issues this feeling is Multiplied as they have this new work and no additional resources due to a lack of context for most automated tooling tickets may be Mis prioritized they may be false positives they may be duplicates and

this causes strain on both security and Engineering since security spends a lot of time during security triage and Engineers feel like they're wasting time investigating non-existent issues when security continues to ring that fire alarm again and again Engineers become fatigued by the constant fire s Engineers start to mistrust the impact of superiority vulnerabilities and the law of diminishing returns comes into play as Engineers have burned themselves out on the first batch of critical vulnerabilities and are tired or no longer have the resources to remediate medium and low severity issues Engineers May lack the motivation or the incentives to address all security issues reported to them they may feel that there's a minimal impact to their performance evaluation or to

the company to resolve all of the issues why fix all of the vulnerabilities when your director is only looking at the criticals our Solutions are to reduce noise for engineers and that's clear prioritization reporting p1s and p2s so that folks build out their muscle improve the signal to noise ratio and there are many methods you can do this we have fine-tuning tooling defining standard for creating tickets improving ticket quality during security triage before it goes out to engineering and including a score for Ticket quality this can be a measure of confidence that you can attribute delay in remediation to pour ticket quality in conversations with engineering adapter reporting and notification methods to your audience this is knowing when to use email versus

sock we generally use sock for notifications and emails for escalation using a digest instead of individual notifications tools like Jared tend to only allow you ticket by ticket so build an automation that allows you to group tickets by an individual similarly using a dashboard to motivate bulk action next is regular security hygiene activities to build out that Security Muscle lastly it's creating a recognition program and culture segment had gamified security culture in which teams were rewarded for security activities and this helped encourage folks to care about all security vulnerabilities that was a lot of recommendations I threw out at you have a lot of strong opinions after working on this one program for many years the

key takeaway here though is that you iterate on reducing noise and to have empathy for engineers as they grow and adapt to this process these new pillars became the democratized vulnerability Management program for tlio in addition to the four pillars we borrowed from segment we included leadership buyin engineering buyin awareness ownership and Noise We had launched the democratized program at two companies of different sizes and cultures does a democratized approach work one way to measure this is through metrics we hadn't launch tvia when log for J hit in late 2021 we didn't have an easy way to track all of our repos and many of our known repos were in an unknown state of remediation many people

spent many many manual hours confirming that we tracked all repos at twilio on our m&as confirming if a repo was affected by log forj and confirming if we remediated it we can compare that to any zero day that hit us in 2023 where we could spin up a dashboard like this on day one we not only had coverage of all affected assets at tlio but we could see a downward trend of affected assets as engineering buring down risk quickly and efficiently Beyond a single incident we can look at a burn down CH of all vulnerabilities present in the org before we launched stvm a dashboard like this wasn't even possible when we first launched DVM we see in the first few

months that most tickets had breached and very few tickets were closed within SLA as time progressed we saw more tickets Clos within SLA and fewer and fewer tickets Clos outside of SLA to many folks they saw this as a sign of definitive success finally we're getting Engineers to burn down risk but metrics don't capture the full story and the plot thickens we had solved a lot of challenges but often times I would complain that this program had become a monster in Greek mythology a Hydra is a monster in which you cut one head off two more grow in security you report one vulnerability and then two more get reported this program is effective at getting Engineers to fix security issues

when you have an effective program that gets Engineers to do security work that's been previously ignored it's easy to keep adding more and more vulnerabilities this was our effective Hammer so we were going to use a hammer for all of our problems all of the elements that make it easier for engineers and Engineering leaders to embrace risk had actually created this terrible powerful ticketing monster at any cost this monster was going to maximize vulnerability remediation and if it's grown heads it had eyes everywhere it could see every engineer and every engineering manager not rising up to be the perfect security partner this is also in part due to the great metrics we were reporting out to prevent this monster from

destroying our program we had to build our program on a foundation a culture of trust this Foundation remains for any program that adopts a democratize approach whether you have more few or even different pillars this is the most important ele liit you must Safeguard a culture of trust is a culture where you are confident in your organization to act with good intention this culture Fosters an atmosphere where folks feel empowered and their opinions are valued and respected as a security engineer you're not fearful that Engineers will leave your organization vulnerable you trust your engineers to protect the company maximizing vulnerability remediation is inherently at odds with giving folks the autonomy and responsibility to remove immediate

vulnerabilities the goal of a democratized vulnerability Management program is that you give Engineers the autonomy to own their vulnerabilities if they're slow to remediate of vulnerability that's their decision and it's our job to encourage and motivate them to want to care about security the only goal of leadership is to burn down vulnerabilities as fast as possible it's a shortsighted goal you can only ring that fire alarm so many times before folks start to distrust you and burn out remember it's easy to break trust it's hard to build building and demonstrating a culture of trust is hard to do metrics aren't easy to capture around a culture evolving however you can share stories of cultural change alongside your

dashboards a couple of stories at Twi that I'm really proud to share are our developer enablement team came to the security team to solve the ownership problem with a centralized software catalog and a Juro integration a zero date incident was resolved before the security team even came online we didn't need to create a single ticket because Engineers had proactively secure the organization the security team adopted those weekly meetings from engineering as engineering leaders were already meeting weekly to prioritize security vulnerabilities into their Sprints and quarterly road maps engineering is currently exploring adding security as a key requirement for their engineering Career Development plans and lastly remember Alice and Bob Alice returned one year later she had reached out to

engineering about building a new process for reporting action items to engineering after an incident engineer ing pushed on Alice to adopt a process similar to dbm due to its success and appeal was extremely happy when Alice reached out and also a little bit Vindicated but I truly saw the culture shift before my own eyes toio Engineers were embracing risk in the DVM program in summary some challenges you may face is culture is continuously evolving it's hard to Define your desired culture and Define the next steps you need to take to get there it's a lot more difficult to measure and report on culture change especially with limited tools like engagement surveys which in my opinion don't do a great job

of evaluating or assessing your current culture a culture transformation demands constant investment and effort it's not a one-time activity it's not always clear what that next step needs to be our Solutions are to regularly report on stories of cultural change alongside your metrics security engineering's job is now to create that culture change trust your engineers to make the right decision decision and this is hard to do going back to control and scare tactics are easier in the short term but trusting your engineers is better for the long term security is a muscle that needs to be built over time so keep folks accountable and engaged through security hygiene activities and recognizing your good partners after the success of dbm

amongst engineering teams they pushed on the risk and the SR teams to utilizer approach for how they handle Enterprise risks and reliability incidents thus our latest stage in vulnerability management is uniting with other teams to standardize how we prioritize and Report vulnerabilities risks and post incident Action items to engineering we formed a group called resilience operations where our goal is to stop competing with each other for engineering time and instead communicate and collaborate with one another and Engineering to resolve the most pressing issues to the organization to wrap things up we go back to one of our original questions why do we need vulnerability management it isn't just a system for creating tickets vulnerability management is a

tool to drive security and ownership change it's about creating a culture shift so that Engineers not only own risk but they Embrace risk thank you to all the folks who gave me feedback during my dry run thank you to all the vulnerabilities that made this presentation possible thank you to the bsides organizers

thank you Ariel we have a question for you it's what types of Education was needed for the adoption of DVM or course engineering teams of what was the last piece of engineering teams okay yes so for it was just how to use the process it wasn't necessarily that this was super difficult to do but it was different from the previous process so we had changed a couple of fields the work flow had looked different there were a couple of new terms like Risk owner due date extensions when you have a really large audience we found that they weren't engaged so they didn't understand or know any of it and so when they got a ticket assigned to them they're just

like what is this in the ticket comments please get this name off like get my name off this ticket or like fix this I'm stuck on something they weren't reading our primer so that's why we had to go to each business unit to walk through the workflow answer frequently asked questions um and basically just point them towards the resources do you have time for more questions is there more time no it's because I know you you need to one if we have any more questions this is the you have a question you know if you have time yeah okay so coming from uh engineering that side that's what I represent maneral ask hear me I can hear but I think it's

for the recording for the while you're asking I'm going to flash this screen that I'm required to flash uh coming from engineering as a manager Dev set Ops area I'm trying to sell this idea to sea level what is your recommendation but like my Approach right now is utilizing compliance trying to be smart sock 2 type 2 ISO 270001 we need this kind of stuff but what what do you recommend would be a smart way to get Buy in at the sea level that may or may not have the knowledge or understanding of what we're trying to achieve with such a program I think the sea level still gets like broad news about security and I think using

relevant news stories talk about how that can affect you is a really convincing way and if there's one person that you feel like is more tuned in on security relying on them to do the speaking for you I would often find like I was doing this project as an L2 so like a role level security engineer and folks didn't trust my title at twio and so I did have to rely on other leaders to encourage others I I think that's like a pretty like dramatic example of using other folks but sometimes it's knowing when you're going to let others speak for you because they're going to do a better job because they have the alliances to build that trust right okay

thanks please join me to thanking our guest Ariel