Career Shifts and Holistically Managing Security Transitions

Guy Podjarny: Hello, everyone. Welcome back to the Secure Developer. Thanks for joining back in and today we have a great guest that actually has a really interesting background in security and that has gone through an interesting journey with DevSecOps, and that’s Dr. Wendy Ng, who is the Global DevSecOps Director at Experian.

Wendy, welcome to the show. Thanks for coming onboard.

Wendy Ng: Thank you very much. I look forward to the session.

Guy: Wendy, before we dig in, we’re going to talk about how you are helping Experian change, how they do security, and talk about DevSecOps as a whole.

But before we dig into that, you had a really interesting path into security. Let’s go back in history a little bit. Tell us how you got started and what was your path to get you to security and where you are today?

Wendy Ng: I actually started off life as a geneticist. I actually did a PhD in Medical Genetics and actually spent two years in a containment level three lab for my research, growing viruses incidentally, in Oxford. I think it’s probably a slightly unusual path into security. And one of the reason that I’ve moved on from the wet lab stuff is, unfortunately I actually have pretty sensitive skin. Imagine if you’re working in a category three lab, where you’re effectively dealing with viruses such as HIV, hepatitis. Hygiene regiment is pretty important. Basically, you wash your hands to death. But my skin just couldn’t cope with that. I developed a bad eczema, and that really is the beginning of the end to my scientific career.

After that realization, I actually managed to get some more funding to do a computational biology, a bioinformatics masters for that transition. Fortunately, I joined Cisco, where it’s a completely new field but it opened up my mind to, wow, how important technology and how important connectivity is for us going forward in terms of the future of business, of interaction, social, professional.

But at the same time, I realized actually things were not necessarily designed – It’s designed with functionality in mind and certainly not security in mind. The first work is not to sort of secure something. I thought as we get more and more connectivity, this is going to be a major problem. It’s going to be an area of concern I think as we have more connectivity.

Guy: Yeah, absolutely. Actually, even a little bit prophetic in that sense. I mean, I think more connectivity has indeed sort of leveled up the challenges associated with cyber. At the time at Cisco, you were working on network. Your sort of formal job was not security-related but rather network engineering.

Wendy: The title was network consulting engineering. I’m actually very grateful for that program because it was a quite intense program, but they really invested in us and trained us up to make sure that when we were in front of the client, we are able to help the client with solving their problems. It’s more on the networking side.

When I got into that field and there’s like computer viruses, malware, I made the connection with biological viruses, and there’s a lot of – In terms of some of the newer monitoring techniques, it uses things like machine learning, which are things that I had been exposed to for my PhD and my masters, so I naturally gravitated towards that.

You probably can tell from my story of my career. I’m probably a bit of a hippie when it comes to my career. I mean fortunate enough to sort of be able to make those choices and I just wanted to do something where I am mentally engaged and excited about.

Towards the end of my time at Cisco, I basically actively tried to move into getting more engagements involving more security side of things, but it wasn’t a security role when I was at Cisco.

Guy: Got it. Cisco kind of opened your eyes to networking and to seeing the interesting kind of analogies that they have to behaviors and connectivity in the biology world of viruses, but it piqued your interest into security. What was the first segue into security proper as a title?

Wendy: The next role I had, which is network architect, the nature of the clients for that particular organization I was more immersed in securing organizations than I had when I was still at Cisco. I sort of progressively tried to move into security, but that was a company called Endava. It’s actually very – In terms of technical skills there, I’m quite impressed with them. My first proper security job I’d say was actually at PwC. That was when I first got immersed in security.

Guy: It’s a plunge.

Wendy: I did take the plunge and I literally did take the plunge. That’s another conversation over coffee, but I literally took the plunge. One thing about working with this joining up consultancy – I was always fairly client-facing anyway and I think it matches my personality somewhat. But one of the advantages of joining a consulting company is that you get such an exposure to the range of clients and the range of engagements.

Before I joined PwC, I was very much in the technical aspect of it. Once I was there, I got more involved in the whole rounded policy side, more compliance aspect of it. That was my first proper inroad into security.

Guy: Even back then, you dug into understanding assessing risk around cloud?

Wendy: Yes, I did. It’s because of my background, because cloud is effectively networking, right? There’s public-private clouds, so it’s –

Guy: Some networking involved.

Wendy: Yeah, exactly. They looked at my profile and they’re like, “Okay, yeah. You can support this client. You understand [inaudible 00:06:32] these projects. Go and work with this client.” Initially, they put me in projects where they knew I can do. Then I think one of the things with those organizations is that because there’s a range of different projects and different clients, you have a certain level of choice which ones you get to. If you’re open-minded and you’re curious and you’re open to learn, you can actually pick up so much knowledge from that experience.

Yes, I was at PwC. Then I got poached by Deloitte because of a massive ransomware thing, which again required a networking background or networking knowledge. So, I continued to focus on security aspects at Deloitte.

Guy: This kind of consultancy stretch and then kind of working, you’re jumping around within the consultancy seeing different perspectives of –

Wendy: I was poached mostly. It’s just –

Guy: Yeah, and I meant you did a consultancy. You work with different customers. You see different customers going through sort of cloud security transformations. I guess before we jump, I know that sort of the next step is the work with Experian.

But before we go there, what were some of the common themes? I know in Deloitte, you were dealing with security transformation and already talking about changing security. Were there some patterns you could already see a few years ago when you were at Deloitte across these different companies that you’ve sort of seen trying to do the security transformation?

Wendy: It depends on what stage the company is at, if they had a massive breach or if it’s a critical national infrastructure. I think there’s sort of more appetite to make changes. But I think change is never easy. You’re basically going to your team and saying, “Look. Hey, great job. You’re doing really well, but we’d like you to do this as well.”

I think trying to implement that change is not always the easiest thing and I think in some ways that’s probably the main issue from the management level.

The other thing is security comes with a cost. You’re trying to stop a black-hat hacker from getting into your network or for accessing your systems or your data. To put those layers in, you’re also adding overhead for your sort of legitimate folks, and that’s sort of probably aligned with, “Why do we need to change. What’s wrong with the way that we were doing things previously?”

The other thing I think that I saw a lot is more of a question really and I think on a strategic level. So many clients, when I work with them, they sort of came to me and said, “What is the best technology for X, Y?” It’s going to sound like such a consultant answer, but it really does depend. It depends on what your organization’s current structure is like, what your capabilities are, what the team’s experiences are.

When you do transformations, I don’t think you should change things for the sake of the change, so you really want to try and keep as much of that capability that you already have in house, rather than disrupting it.

On the tooling bit, I think from the strategy side of it, if you’re doing best in a tool – literally stay away from the shiny objects sometimes if you can because you can buy a tool, but the investment is not just the actual purchase. You need to maintain this. Otherwise, you just bought it, and they’re kind of not doing anything. I think you need to have a good strategy on what your plans are before you make those investments.

Guy: Yeah, makes perfect sense. Basically try to understand what are your constraints, what are your intents, and think about how would you roll out a solution, how would you implement it, how would it sort of play along with other tools that are sort of in that surrounding before you jump in and embrace it above and beyond the dollar cost or sort of ease of deployment with a specific tool. Does that sound about right?

Wendy: Yeah, that absolutely. I think you want to plan as much as you can. You want to do as much prep, do as much homework, do as much research so that you’re not walking in blind as it were or with very limited visibility, but you can’t prepare for anything. But if you do as much homework as you can beforehand, I think you’re just putting yourself into a much better position.

Guy: When do you know that you’re slipping a little bit into paralysis by analysis stage? Because presumably you could sort of analyze tools forever and ever to make a decision? What were your key guidelines in sort of saying, “Okay, I feel comfortable that we’ve done enough diligence here to pick the right tool from it.” Are there some key criteria?

Wendy: Just to answer your question on paralysis by analysis, for technology that’s particularly important because it changes so quickly. You don’t want to spend like a year analyzing and offering and every few months there’s a new feature that you’re not taking into account. Having said that, I think a year will be too long. I think six months is too long.

Guy: It comes back to, it depends.

Wendy: Well, okay, yes. It does depend on the toolsets. I think for me and I’m probably leveraging some of my past experience in research, but in research, when you do the background analysis, you probably want 95% of your data if you’re doing a primary experiment. I just hope this doesn’t come back and bite me. I think in a commercial situation, I quite like the 70, 80% accuracy rule that a lot of consultancies use. The idea is that even if you get a third of your answers wrong, you can do it faster. You’d still come out with the right choice.

Now, it really just depends on what the tool is and what your selection criteria is and what your requirements are. I think that’s actually probably the most important, making sure that you’ve got the right requirements that you need, so the strategy, the requirements, and future analysis. But, yes, it really does depend on what the toolset is, and I think it’s probably a judgment call more than anything else, to be honest.

Guy: This was the journey and it sounds like you went from biology then viruses to network, to security. We arrive at today and we arrive at Experian. You joined Experian to apply DevSecOps across it? Is that correct?

Wendy: I joined Experian for the DevSecOps role, I think. I’m a big believer in sometimes you really have to learn on the job. And I think one thing with a consultant’s background is that you really sort of learn on the job. I probably shouldn’t say this. I will let you decide whether you keep it in. I actually went for an interview. I didn’t actually accept the job because I didn’t think it was the right time to leave. But a CISO at a big UK organization, I interviewed with actually a quite big technical CISO. I spoke to him, he looked at my CV, and he said, “You don’t have any application security experience. You basically have everything. You haven’t had any application experience.”

That was about three or four years ago. Basically, I thought that was really sound advice, so I kept that in mind and I did my work, do it well, stay low, and then try and see if I can find any opportunity to go into that area. That is actually why I joined Experian. It just happened that DevSecOps by chance came up. Actually, I was poached but I wasn’t poached by a recruiter this time. I was, in fact, poached because of somebody I used to work with. I realized that I probably hadn’t had enough experience as previously. But I know, just from the things that I’ve done in the past, I know I can learn and I can pick things up very quickly if required, and I have good beliefs in my judgment.

Guy: I think that’s great to hear the initiative and the push forward, and one of the best ways to learn a skill is to actually dive into it and I think if you have the surrounding elements and if that’s your gap and you build that in.

Wendy: Just to reassure everybody – I know that if I jump in and I apply myself, I will be able to deliver good results and I will have good judgment from it. I’m not the kind of person that takes so much risk. I will just go, “Oh, yeah. I don’t know what I’m talking about. I’m just going to come and join you.”

Guy: Let’s dig into sort of the Experian flow a little bit. You came in. You’re looking to do it. Tell us a bit about the journey. What’s the program? What is the DevSecOps transformation, promotion that you’re applying in Experian? What are the key tenets?

Wendy: I think we are very sort of application-centric company, and a lot of our services and offerings are through applications, effectively through applications. Early on, there’s a recognition as we sort of invest in transforming, and it’s not just DevSecOps. It’s transforming technology, transformation and uplift across the board of our entire technology estate. That is recognition that I think technology would actually provide the sort of differentiation between you and your competitors and allow you to provide better service for your clients.

Guy: The DevSecOps is a part of the same one or did it come after? Is it with the transformation? Did DevSecOps as well?

Wendy: Yes. The DevSecOp is one workstream of the transformation. It’s actually a huge transformation program within the organization.

Guy: Got it. The whole org is going through DevOps, and then DevSecOps is one of the primary motions or one of the streams I guess within that.?

Wendy: The DevSecOps is a workstream. The organization – We are a co-development house in a way. The things with Experian is historically we grew through mergers and acquisitions, so it’s a multitude of different companies that came together and they bought in their own kind of histories, their own cultures. One of the difficulties is it’s difficult to try and transform them when they are actively serving clients. I think there’s an understanding that if you want to do this and you want to do this properly, there should be a pretty significant effort, and that was decided that DevSecOps was one of the work streams, and it is absolutely the right thing to do.

Guy: Fascinating. How are you getting it done? What are the key motions within this workstream?

Wendy: We’ve done a strategy piece initially and we did have some industry experts to help us with that. We really want to make sure that we’re doing the right thing. At every stage, we’re basically gauging what’s the industry best practice? How to do that from strategy, from the tool selections, from the organization set up? In terms of DevSecOps within Experian itself, we actually have a kind of mixed environment. Some of these are really quite mature. They’re just kind of doing infrastructure’s code. Everything is sort of automated deployment. Then there’s some that’s sort less so.

If you’re an organization that’s trying to go through this journey, I think what really helps from what I’ve seen is that if you have senior-level support and the developer willingness to undergo that journey. I think if you have the two, then it can actually work very well and can actually happen very quickly to transform.

Guy: You mentioned to me that you actually learned from those teams, right? The more mature teams and the ones that are further back that you’ve sort of embraced. I guess kind of learned from the teams that are ahead and tried to sort of instill those practices backward. Was that one of the primary methodologies?

Wendy: Well, for me, it was. I mean, for my sort of selfish reasons. I believe in learning from the masters and sharing that information. So, I’m quite curious. I’m open-minded. I would go and talk to the teams and sit down with them. I’m like, “Look, I’m really grateful for your time. Can you just run through what your work stack looked like, what your processes are?” Through those conversations, we kind of knew just about what different teams are doing, so we can categorize them initially. Basically, as the pro-transformation team and the DevSecOps center of excellence which was setting up as part of this transmission initiative, we are effectively learning from those.

But then the other side, your company is basically as strong as your weakest player. The ones who are less mature as it were, we’re basically trying to bring them to a certain level by providing support, providing templates. The type of support and the type of help we gave is all through conversations with the team. So, we’re not like, “You must do this.” We basically want to speak to them. We spend a lot of time engaging with them and just like, “What would be helpful to you?”

In fact, through some of these conversations, we had initial idea for a process of what would be helpful to them and some of those we’re thrown out through those conversations, because we went to the teams and they’re like, “No, no, no. That’s not helpful for us,” or, “Yay, that’s helpful for us.” So, we listen to that feedback. I think that worked really well and I would really encourage that if an organization is trying to transform it, because there is a lot of knowledge within the company.

But I think I’ve also been quite lucky with Experian. It’s almost like a multitude of different company because of its history and through some of the teams that are doing amazing things. I’ve learned so much from them. I mean, I can’t thank them enough and I can’t really say their names, so let’s leave it at that.

Guy: I love the core notion of it. If I understand this correctly, you’ve got a DevSecOps sort of central service. A lot of the practices that might get accumulated here within that center are learned from not just sort of outside world and best practice with DevSecOps but also inside the organization from those teams that are doing it well, and so there’s this almost facilitation of knowledge transfer and help to sort of say, “Hey, these are the teams, the groups, the acquired companies that are doing it well. Can we learn from them and see how it’s done already internally?” So, presumably a little bit easier to mimic for the others. And then go to the teams that are further behind and try to level them up maybe not quite all the way to the mature teams all at once but sort of above a certain bar. Am I understanding correctly the rough flow here?

Wendy: Yeah. It’s a step-by-step process. And the center of excellence – One of the goals of the center of excellence is knowledge share, and it helps if you already have the knowledge in your company. I mean, this is like with a transformation project, you want to keep using the knowledge that you only have in your company. You don’t need to go out and get as much external input into the company. Use that.

One aspect of center of excellence is to basically share the knowledge across different teams and encourage them to work together, because I’m sure they’re probably seeing the same problem multiple times, and there’s no point trying to troubleshoot the same problem. If somebody can say, “Look. We had this problem, we’ve solved it, and here’s the information.”

Now, the problem with that is actually – On the kind of how to store and how to display information so that is current and so that is easy for developers to sort through so they can share, that is not necessarily easy thing to do.

If any of your listeners have any advice on that, please reach out to me. I’m always happy to learn, getting that knowledge, getting people to work together, and getting knowledge share for global organization with multiple different cultures and multiple languages is just quite a big task.

Guy: Yeah. It’s a big excess. I think maybe just one more question, I know we sort of started to kind of long a bit, is maybe coming back to the conversation about tooling. Now, you’re in the hot seat, right? You’re sort of running this and you need to kind of help facilitate some –

Wendy: Well, no. I don’t want to take all the credit [inaudible 00:20:12]. There’s actually a program director. I’m kind of there as an SME advisor type thing. I don’t want to take all the credit, please.

Guy: Understood. But still you’re in the spot where you’re a bit more active, in active ownership over these decisions. How did you approach tooling decisions in this case? If you had multiple teams, did you try to streamline the tools? Did the different teams still get to pick them? Did you purchase tools centrally to help the journey? What approach did you take on the tooling side?

Wendy: On the tooling side, we did stakeholder engagement, and it is very much a collaborative approach, right? I mean, really use this collaborative framework. We didn’t go and, “Oh, we think these tools are great.” We don’t go in blind, so we do our homework. But then we actually speak to the business units and say, “Look. What are your pain points? What could help you? Do you have any suggestions?” We actually took all that information and took it and digest.

Now, for an organization like ours, part of the rationale of the transformation is to consolidate the technologies that we have, because that improves manageability. It improves visibility and allows people to collaborate more, rather than having five different tools for one thing.

But it would not get 100% or even 90%, so the idea is to try and identify the main players and, again, working on the assumption that we don’t want to disrupt what skills do we have in the organization. Let’s try and keep that unless identify reasons or gaps that’s not currently being fulfilled. It is very much engaging with the different BUs, multiple individuals and BUs. From the developer to the CTO across the board and users so that we are getting as clear a picture as possible.

Actually, the team, I’m so proud of the team that’s been involved. They work so hard and because the team is global – Before this coronavirus situation, we actually did most of our engagement virtually using technology. It’s actually worked out really well. I think we had lost of efficiency savings from it, in fact. Rather than having to fly people from countries in the world or what have you. I think it’s worked out really well.

Guy: Yeah. Again, ahead of its time. I love the consultancy mindset over there. You bring people together, and it sounds like that’s kind of the recurring theme a little bit in the program, right? It’s about learning inside and bring people together towards this motion. One last thing I ask every guest that comes in is you’ve done this journey. You’ve worked for different companies. You’re helping out with this great transformation within Experian. If you’re talking to a team that’s maybe looking to level up their security or maybe they’re sort of looking for a security transformation of their own, if you had to give them one key tip or one sort of key focus area for them to focus on, what would that be?

Wendy: I think collaboration. I don’t think anyone of us is an island. So, there’s an osmotic process between us with field knowledge.

I genuinely believe this and I’ve been trying to do this through just sharing our knowledge through blogs and so in the past few years now. I think instead of trying to reinvent the wheel or just trying to solve a problem from scratch by ourselves, collaborate. Share our knowledge. I think that is so important.

Coming back from my academic background, that was second nature. I’m really hoping forward that we can sort of work together more and share knowledge. I truly believe this. We are stronger if we work together. We will always be stronger when we work together.

Guy: I love the guidance and I think it’s spot on and it’s true in so many layers, right? Anywhere from how do you drive a change to security to the actual theme of the change. To end up more collaborative all the way out to sort of the humanity collaboration aspect of working remotely or just sort of dealing with this crisis. I love that tip.

Wendy, it’s been a pleasure having you on. Thanks again for joining us.

Wendy: Likewise. It’s been an absolute pleasure. I’ve really enjoyed chatting to you.

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

Wendy: Thank you.