Ep. #40, Large-Scale Digital Transformation with Brian Sodano of Liberty Mutual

Guy Podjarny: Hello, everybody. Welcome back to the show and thanks for joining us again.

And today we have Brian Sodano from Liberty Mutual. Welcome to the show, Brian. Thanks for coming.

Brian Sodano: Thank you for having me, Guy. I appreciate it.

Guy: Brian, we have a whole bunch of topics to cover, but before we dig in can you tell us a little bit about yourself?

What is it that you do, and how did you even get involved in security in the first place?

Brian: I've been in the software development industry for about 20 years, I've always been an engineer and I still consider myself an engineer.

I don't get to write a lot of code these days, but--

Guy: Yeah, you're still an engineer.

Brian: I have my side projects, so that keeps me busy. I've always found that security is actually a very important aspect of this.

I've watched it evolve over a long period of time from anything from physical security down to AppSec stuff, and I've always been part of the process from either--

Like, if you remember 20 years ago setting up servers and physical stuff and worrying about actual physical security, all the way down to now.

I'd say I got very into this a few years ago. I worked at a small cyber security startup that was actually here in Boston, I got very involved with analyzing different vendors in the space.

Static security, pen testing, dynamic security, emerging runtime security market, looking at all these different aspects. I found it fascinating because there's so many different angles, and everyone has their different take on what's important and how stuff works.

There's some elements and essential stuff, so I came to Liberty Mutual about two years ago and I've been looking at ways to improve that there while working on a digital transformation project as part of their platform, which I will gladly talk more about too.

Guy: For sure. So you we went through this great journey in your engineering and I love that, just as a cycle, but you also have done about maybe still run the local Node.js meet up group here?

Brian: I did. In fact, that's where I first met you. It's been about five years ago, now.

Guy: It's been a little while there, but I seem to recall you had a security interest then as well.

Brian: You know it's funny, first of all I'll never forget that you showed up and you pinged me out of nowhere and said "I'm going to be in town. I want to talk about this stuff."

I'm like, "OK. I don't know what this is, but this is fine." Security had become a very popular thing, and I remember two things from that meet up.

One was I asked you, I said "Is this like NSP? Like, Node security project?" And your answer was, "No. This is way better than that."

Guy: Good to hear I was confident, even back then.

Brian: You were. And I said, "OK. We can go talk." Basically the Node.js meet up in Boston is this monthly-ish meet up.

Sorry guys, if you're listening and you're a Node meet up I've been slacking a little bit and I've been busy, but we have regular meet ups.

I think that when one was security-themed and you said you'd come in, and the second thing I remember by the way, was you had the little--

Guy: The magic wands.

Brian: Those little plastic things that you roll up and then you throw it up in the air and a magic wand appears.

My kids still have a bunch of them at home, believe it or not. We found some when we moved and they're still throwing them around.

Guy: They continue to be our-- I like to say that "If we've achieved nothing as a startup, we've perfected swag with these magic wands."

Brian: You need more magic wands. We've got to bring them back and keep doing them.

So one of the things that I found very interesting about that, also as an aside-- By the way, this is not a plug on Snyk, I swear.

The audience really resonated with what you're talking about at that meet up, so you're talking about how Snyk works and how it is very developer-friendly.

I don't think it was so much that it was a security software, I think it was the fact that you were actually talking to developers as a developer, and showing them how to do this in the code and going through it.

I think they were like, "OK. This is super easy. This makes sense, I understand this and I could see where this is going to evolve. It's easy to put it in my processes."

It really hit me at that point, I was like "I think they're on to something." I think about that over the past few years as I've looked at other tooling and stuff like that too.

Because I think the entire security market as I've looked at over the past 3-4 years is so tailored towards certain audiences and certain end games of what people are really looking for, and what it is that they need to support as part of their stuff. But it was really the first point I saw somebody really seriously targeting the developer audience, so I took that and I remember I got tremendous feedback on that.

Like, "You need to have more developer-oriented stuff." Actually it's funny, because we really talked to and I started gearing towards other companies when they started coming in.

Like, "You really need to start talking about the APIs you offer and the kinds of ways you can interact."

You did change my mentality a little bit about how to run that meet up, which was good.

It was that great turn out, that great showcase, but I think it was really resonating with the developer that really drove that stuff.

Guy: That's awesome. First of all, it's awesome to hear that it left a good impression.

We got a chance to maybe move this back in, which is this whole theme of the developer and security has really strengthened over those years since that talk way back when.

So maybe let's dig into this one for you. You come into Liberty and you're not in a security title, you come in to do really a digital transformation project and change it.

Tell us a little bit, paint a bit of that picture and what's the scope of the initiative, and how does security play a role in it?

Brian: So , Liberty Mutual has for the past two years undergone what's commonly called a "Digital transformation."

Folks who are not familiar with that, they were operating in a very waterfall software delivery model, they weren't necessarily following agile practices, a lot of things were tied to big, long delivery dates and were project-based.

They had a lot of analysts write up a lot of papers and make these project plans and deliver stuff.

It was slow, it was essentially-- In order to deliver new functionality it was a very difficult transition to be able to actually get stuff out the door and move stuff in.

They moved to agile methodology, they moved towards a very developer-centric model and they shifted the way in which they work.

We're very similar to a Spotify model, you have product owners and we have development squads.

Their task is now to maximize customer delivering impact as we go.

Everything is customer-centric, everything is customer-focused. The teams are consistently looking to deliver the right kind of value outward.

One of the reasons why they're doing this is in this industry they're looking for a central operational efficiencies to be able to drive more adoption of folks, and to be able to buy insurance online.

We are certainly a very successful business for getting folks to come in and work through agents and partners and call centers and reps, but sooner or later the customer demand--

I can think of younger folks and millennials that don't even want to talk to people on the phone.

Guy: They want to go online somewhere, right?

Brian: Correct. Yeah, and you look at what insurer techs are doing and you look at other startups in the space and FinTechs, they're gearing everything towards online.

They don't have the giant distribution network that we have going for us, so they're making a shift for the benefit to that.

As we do that, as we start to drive through, you look at these different teams that are building that, we have a bunch of teams that are working down here in Boston and up in New Hampshire, Seattle, Ireland, and they're looking at ways in which to engage the customer faster.

Now what's funny is typically most people wouldn't think to engage with an insurance company very often. I mean, how often are you going to go do this?

So the name of the game is speed to attract them in from a sales or point of sale perspective. "I'm able to draw the m in now--"

Guy: Cash in some attention.

Brian: Correct. Of course, price matters in this, and there's other factors that go into that.

But once you do that there's also the speed factor and convenience, and "I have to deal with my insurance company."

So I have to make payments, I have to file claims, I want to have payout. What is it that you said you're covering?"

In order to transform those particular experiences we're developing software super quickly and trying to see essentially in an agile way what sticks.

We're constantly testing and measuring, we're constantly throwing stuff out there.

As you can imagine a lot of this means that stuff is changing all the time, so when you start getting in that environment and we also embrace an open source mentality.

Moving from a lot of primarily Java proprietary stacks into JavaScript open source community, full stack--

Guy: It's a wholesale change there?

Brian: It was a very wholesale change, but as we made that change now you're opening up a nice broad ecosystem.

Which on one hand is great, because you have access to all these commonly used libraries, and you cannot reinvent the wheel every single time.

The con is that there could be potential vulnerabilities that are opened up in these particular libraries as well as new methodologies in which we're deploying software when we're throwing it out into the cloud, and different mix methodologies of hybrid environment as we move into a new way of working.

What's been interesting and what's been a continuously evolving way in which we've operated is the best way I could say this, is when you have the market teams and the digital group that we're part of continuously pushing out these changes, and they're constantly churning through and you don't have these big project plans or these big things anymore that you can hand over to your network operations.

Your data center folks said "I need to provision this kind of hardware to go through these things," and "Here's my security plan."

Guy: Kind of fluid force. There's no gates, there's no review points as much. It's continuous.

Brian: Correct. It is a continuous change deployment, everything that has to happen there, so we have to come up with a new way to operate.

I would love to tell you that we have figured everything out, but we have not.

We are constantly reevaluating the best ways to operate both with our security partners, our global cyber security group, as well as our SOC and getting the alerts and understanding who is responsible for what.

It's interesting. I think the tools that we can introduce from this market delivery perspective to help really literally the shift left mentality of developers do more have immensely helped to help shove down those sorts of--

Like, catching things essentially before they even get off a developer's machine.

I'd be able to understand what library choices that we use from an architecture perspective, but we're also continuously looking at the best kinds of architecture patterns and practices for deployment as well and how we actually work with our partners.

Guy: So this is a fascinating transition, and you're describing the change of really everything.

I know about how do you operate, I think you rightly describe this as "Changing how we operate."

If we focus on security for a moment, you're inside and your title is "Director of engineering," right?

The title isn't a security title, and you're describing security activity and you're talking about shifting left and building those security components in.

From an organizational perspective how has security changed from within the company? Is there a separate security team that's a part of this digital transformation?

This like, "Digital Liberty Mutual," is it the security team that's learning how do they adapt to this new surrounding?

Security, responsibility and eng? Instead of trying to enumerate the options, how is that being handled in that context of all this big change?

Brian: It is a brave new world in terms of how we're doing this, so a lot of the drive begins with "What is it that we're really doing to the customer?"

As we keep pushing that we've had to evolve and understand and have certain people assume certain roles, so we have the concept of what we call "Solution engineers," or more or less like a solution architect.

It's the same idea. A lot of those folks essentially have taken some of the leads from a market and digital delivery perspective, understanding the kinds of risks that we're going to be throwing out there based on what it is that we're making.

Whether that be writing to web clients or chat bots, or text SMS interaction along with our new web apps, and then helping to work on new plans that essentially didn't exist in this continuous deployment model to be able to put together the kinds of checks we need.

For example, if we have Snyk as part of our CICD pipelines, that now has become our responsibility because previously we would have thrown this in a monthly release cycle.

It would have gone through all the--

Guy: Someone would audit.

Brian: Somebody would have checked all this stuff and checked all the boxes and said, "Are you doing all these things? Yes or no?"

When we said "We're not doing this anymore, we're going to deploy at will and at demand," we had to come up with our own methodologies to be able to incorporate back into this.

We are taking lead on this.

Guy: Was that a conscious decision?

So there was this set of, "From a compliance perspective," or just the security policy, "Here are the things that needs to go into a release, or whatever code that got shipped into production and code that touches our private and personal data that you touch. How will you be satisfying it?"

Or has it been more the dev team being security-minded because it's a different perspective, a different breed?

Brian: There's the aspect of how we chose to go with an open source ecosystem, and a very popular one too.

You talk about full stack JavaScript, so we're on the hook for understanding the kinds of vulnerabilities we're continuously bringing in or potentially bringing in as part of that.

There is another aspect where we're trying to figure this out now too. Like I said, teams are moving into the cloud and you get into a dynamic security aspect.

That's been a joint effort between a centralized security group as well as partners that we have that might be maintaining--

Like a WAF or application firewall, rule sets and scanning that go along with that, as well as bending those rules and modifying them to meet our needs.

Guy: These are groups that are--? These partners are the same teams that would have secured the pre-digital transformation teams?

Or these new teams that got formed for this purpose, or new individuals that got tasked with--?

Brian: They are the same teams that existed, but they've evolved.

They have become a newer entity on our global cybersecurity group that exists within our world, and their role is essentially to still take on this centralized security response in and incident management aspect.

Where we've had to come together is a newer understanding of the architecture that we're proposing that we're doing, and you talk about things like moving into the cloud and serverless.

You talk about getting rid of giant monolithic applications that are much easier to manage from a security perspective, and it's one spot, everything's there.

As we move into service-oriented architecture and you can call i t micro services or you can call it whatever you want, but essentially as you move into the service-oriented architecture in the cloud we are redrawing out the ways in which we're inter-operating.

What we found is super interesting, is that there isn't really one side or the other side. There's a lot of shades of gray that go in between both of these sides. There's granular and fine-grained abilities that some of us want to have and not, and from a security and centralized security group perspective they want to know if there's a potential incident or there is a potential problem . Or if there's a very broad scale vulnerability, and be alerted to it, and understand that somebody is going to be looking at remediating it.

Or whether they are going to be involved or whether they'd have to get us involved, everything like that.

But there's a lot of fine-grained detail that goes into what we're implementing all day long, and boldly speaking we outnumber them.

We have several hundred developers in the digital group alone and over a thousand developers inside the US alone.

They are-- A security organization that is centralized doesn't have that many folks, it's a much smaller ratio.

I don't know if it's 100 to 1, but it might be in terms of that size.

So how do you operate in this knowing that the developers are essentially now pushing and changing everything as a growing force and have the capabilities to do this too?

Where do you draw the line? We've worked to a new model where there's a little bit of the central group, and essentially what their needs are, and then there's a group that's evolving under the market level or the digital level.

Say under me, where we have security champions and we have dedicated folks that are involved in part analysis, part plan, part architecture.

It's a little bit of blur, but essentially it'll boil down to procedural dev ops automation things, anything that we'd be doing to essentially carry out those checklists.

I think it's just going to keep growing as we keep evolving.

Guy: So this would be-- To echo this back, within the digital group there will be--

Or maybe there are dev ops entities, so there's somebody there that is more central but not security-dedicated that focuses on developer empowerment.

There's the security, the central security entity that reasonably has the same concerns regardless of whether it's on new or old infrastructure.

If it's a vulnerability it needs to be handled. But then for this new world, this dev ops team needs to take on or is taking on some more of this responsibility in coordination with the security team.

Is that--? Did I hear that correctly?

Brian: Yeah, that's about right. It's a little bit more split up than that, and I don't need to get into the details of our organization that likes to shift around as things do.

But there's definitely needs from, like I said, from that first response perspective and from a global "Is this going to be a problem from a customer perspective that we need to really be concerned about?"

Essentially rolling up to our CISO versus the roles that we have to help enable the functionality that that we're driving and we're pushing.

It is a little bit of a self-elected, self-nominated "We have to do this. We don't have choice." As soon as we keep expanding this channel.

Guy: You made a decision to embrace the technical platforms, or you made the technology choices.

Given the fact they're different than past technology choices you have to assume some responsibilities.

Brian: It's like, when we have that freedom we have to pay that price a little bit.

Guy: Yeah, exactly. It goes hand-in-hand. So you're doing it, and I think this process you describe is fascinating.

It's probably similar to many other digital transformation initiatives, what would you say are a couple of your key learnings here?

Things that if you look back at the last year or two you would have done differently, or after 70 durations you hit the mark?

What tips do you have to somebody else going through this same journey to spare them a mistake or two?

Brian: One of the things we had to figure out was how to get the developers to care about this.

We didn't have dedicated security folks, we have some people that care about it more than others but we had started a guild concept internally.

It went how you would imagine it went, there was a lot of people that were like "I really like UIs."

And there was a lot of people that were like, "I like some services and I like back end stuff." Then we had "Let's do a testing guild, a security guild," and there was a few people there.

That's typically how it goes, and those are two areas that I really care about because they're super important and usually underrepresented, essentially. Not misrepresented, but--

Guy: A little bit more invisible.

Brian: Yeah, a little bit more subdued in terms of their role.

The tricky part was trying to figure out how to get them to really understand just as much as they might be concerned with the way their code is presented, the kinds of libraries they're making, incessantly caring about nitty-gritty things like glinting rules in code and everything like that.

Can you get them to care about security just as easily? One of the things was looking at the kinds of tools that we could use that A) were super easy to integrate into their everyday processes, so API driven.

The second thing was using tools that were also easy to read and understand what they meant.

That meant if there was something that was scanning or something that was helping them with the security process, there wasn't a lot of noise.

They weren't just sitting there saying, "That's great. This tool just told me I have 2,000 things wrong with my stuff. I don't even care about this anymore.

Guy: A much better signal to noise ratio.

Brian: Correct. So we looked across and then we looked at different tooling to do that, and we also had tried to incorporate all of these tools into DevOps pipelines automatically.

We were using a split node between say a Jenkins' and some other Atlassian tools like Bamboo and some other tools that exist inside there.

We try to coalesce around some, but how do we then make that so that they're not really thinking about it so much?

It's super easy to say, "OK. This is a quick change and I understand this." The second part was also getting our product owners to buy in, and this was super important too.

A lot of them are focused on making great changes for the customers.

They have certain metrics they want to get to with customer satisfaction, making sure that folks like this, and we had to angle that in.

We're continuously doing that and saying "Also, a secure website is super important for you and for your customers. Have them have that peace of mind to make sure that it seems like we know what we're doing, and that they're capable of providing that safer environment with any incident or stuff like that too."

So we didn't really step back and focus a lot on that, and quite frankly a lot of what we are going to be doing the rest of this year and in the next years is a heavy focus on working with our product owners, in addition to our security organization, on educating "What is it that we're trying to do? What is it that we want to go?"

And understanding the kinds of roles that everyone needs to play in helping support this transition, because it's an "Everybody" thing.

To your point, we don't really have a dedicated person, like we don't really even have dedicated QA or testing folks anymore.

It's something that we're shying away from and we're saying "This is everybody's responsibility as part of the dev thing, you're responsible for dev and DevOps, you're responsible for testing QA as it goes and you're responsible for security as it goes," and trying to spread that all out with certain champions to help push certain things.

Guy: Across those, yeah. But I think probably what I like the most about what you're describing is how you're basically treating security the same way you are treating all the other aspects.

There's a UI guild, and there's also a security guild or a testing guild, to even talk about product and getting into the backlog.

I think what you're describing is actually the epitome of making security just a natural aspect of quality, of just "This is what good software looks like."

It has those components in, which I assume is not an easy challenge but it feels like once accomplished it's just more ingrained into the fabric of how software is developed in the new stack.

Brian: You said it correctly. All of this is a software quality play, not for a means to an end and not just because we want to sit here and chew on building correct software.

What's the old adage? There's always the old joke that it's a bunch of DevOps-y folks that just love to tool around and get their most perfect Kubernetes cluster sitting there and running in perfect harmony.

Is that what we're trying to do? We're trying to do very, what I believe and I think what a lot of the folks the industry are thinking, just as in the DevOps idea, if you want to take this to DevSecOps this is where this is going.

This is part of your job, it's part of your every day.

There's a lot of noise and choices that certain individuals, say from a leadership perspective or from my angle, as well as in harmony with the security organization that can help filter out and say "OK. There's some basics that you have to cover, and there's some things that we're expecting out of this. But other than that, just keep building towards these things."

We're starting to introduce the idea essentially KPI-- Or, better yet, more like OKR-driven requirements for security as well as performance and testing.

Guy: That's fascinating. What are the OKRs? Sorry for interrupting you there for a second, but what are a sample of OKRs that you had around security initiatives?

Just the metrics, not necessarily the thresholds.

Brian: Yeah, they're a little bit of both. It depends.

A lot of them would be tangible upon potential outcomes that we're looking for. I believe I heard earlier today in a discussion the idea of rewarding teams that might have a zero vulnerability in certain aspects like that too.

It's being driven that way, and it's the idea that in building these continuously evolving new software choices we're going to be rewarding folks just as we're meeting OKRs for getting certain other percentages to the website, or certain other stuff like that.

It's "If we can hit these some degree of threshold, or some degree of code security quality, some sort of maintenance level.

Like, we didn't introduce the new vulnerabilities, we made conscious choices to not use certain libraries and that helped a whole bunch of different things by not doing that."

We're now baking that into plans, we're thinking of the next year and giving those same OKRs to our product owners alongside with a customer-centric ones so that it's all equalized.

Guy: Rationalizing the same-- It sits there right next to the business value metrics, because this is business value it's just you have to measure it as a leading indicator.

That's in general one of my areas of passion, just exploring, hence my butting in there on those.

It's just finding security metrics, but it sounds like in this case you're saying, "I'm picking more of the accomplishment of the activity that I'm doing. I'm not trying to get into some nebulous 'How secure am I?' Type measurement, it's more about how I've set out to not have known vulnerabilities in my system. Have I achieved that or not?"

Brian: We want to set guidelines towards the excellence levels we want to achieve as an organization, and that's security and that's a level of testing that we have, and that's site performance which is super huge.

That completely and very directly impacts our customers, all of those get intertwined but we don't want to necessarily be super overly prescriptive on how.

We do want to narrow down into some guidelines, so there's a middle ground that we're trying to come to where we can put a little bit of blinders on and say "It's not a completely open field.

You can't just do whatever we want and use 50,000 different security tools or testing tools, or even web frameworks for that matter.

We're going to centralize around this, more or less, and we're going to go over here."

I'd like to point out too, if there's any developers that are listening to this, the Airbnb model.

They have certain standards that they use and certain libraries that they use, and I don't know anybody at Airbnb but I have to imagine that internally there are plenty of other teams that explore other avenues and ways to do it.

It's not like everybody uses this universally, it changes over time. That's the model we're taking.

It's like, "Let's pick like an 80-90% common denominator about where to go."

Say, "Yeah. Go that way." Go do this and then say, "Figure it out." We know we have a bunch of smart developers, really great engineers, and they're constantly coming up with awesome stuff.

We're just trying to make sure that they're measured and incentivized for doing the kinds of security practices in the same way as they are for that very direct customer-centric type of idea.

Like "I made something visually appealing, I made a workflow that works really awesome. I had a dysfunctionality that never existed before that talked to some of our systems and made the customer's life that much easier."

This should be alongside with all that stuff.

Guy: Yeah, no. That makes a lot of sense, and I find it to be very much future-looking.

Basically just trying to understand around the destination, you talk about outcomes of the different aspects of software, the outcome of "Am I performant, am I secure?

But to an extent if you think about these things as the outcomes of the organization, if you manage to achieve an organization that measures itself this way, I think that's a good destination.

There's a whole bunch of other things we can dig into over here, but I think we're coming a little bit to the end of the time.

Before I let you go I like to ask every guest coming on the show if you have one piece of advice or one tip, maybe a pet peeve, something people should stop doing or one tip of something to start doing to level up their security foo.

What would that one bit of advice be?

Brian: There's a lot of change going on in the industry right now, in the security industry.

Like I said before, there's a lot of players in the market and there's a lot of tools. I think to be fair there's also almost a lot of noise just in the market itself, and I think as a developer it's a little confusing.

My advice would be to educate yourself on the basics. There's plenty of resources, you can go around to almost any --

You can go to Snyk's website and you can go to WhiteSource website, Contrast's website. Everybody has a blog and they all do a very good job of trying to describe and understand the kinds of ways that security is handled and ways to segment it.

It doesn't take a lot of time to understand the differences between source code analysis and aesthetic application testing of a security dynamic.

I found a new acronym when I was looking this up the other day, it wasn't DAST, it was MAST which somebody referred to as "Manual application security testing."

I was like, "That's--"

Guy: Can I get a pen test?

Brian: Yeah, that's free and that's about right. But understanding that most of that world, especially from a developer standpoint, is very accessible to them.

The SaaS, the SKA, the IaaS and even the RAST worlds are very much within the reach. DAST is a little bit different story, I think you're still going to need a bunch of interesting security professionals coming up with ways in which you can hack into--

Guy: Successfully scan.

Brian: Yeah, everybody's sites and constantly be churning that out. I think I heard you say recently, "There's not going to be any shortage of jobs for security professionals anytime, ever."

Guy: It's the sad reality of security.

Brian: And it's only-- I'm sure there's only to be more job opportunities in the near future as everything moves more online and we do more things via our phones and our computers and our watches.

For all I know we're anticipating that's going to be a thing probably in the next couple of years.

When I worked in IT I never believed that voice stuff would be real five years ago, and now I have an Alexa in almost every room in my house.

So, I get it. I think it's just super easy to educate yourself on this stuff and I think most developers just don't think it's their job.

Whereas I think many of them now are in the mode of "I do testing. I do ops. I understand my environment and I get into the cloud."

I think there's a next evolution that comes to security as part of that.

It rounds out a lot of or most of what's going to become a very developer-centric new way of working over the next decade or two.

You're only going to see more developers popping up.

Guy: Yeah, that would be a good skill and a good talent to have. Sound advice. Brian, thanks a lot for coming on the show and sharing all this info.

Thanks everybody for tuning in, and I hope you join us for the next one.