NEWS + ADVICE
Making Your Way From Software Engineering to Cyber Security
Info Security Engineer, Margaret White, shared her career path from software engineering to cyber security and gives insight to those wondering what to do next in their careers in a presentation at BSidesLV. She discussed how to connect the dots for yourself, how to draw upon your own experiences, and how to bring it all together.
I’ve been with Bank of America for 15 years, and though I’m currently an info security engineer, this is a new role for me. I’m one of over 2,100 employees who serve to protect more than 46,000 consumer and small business customers from the bad things that can happen to them and their money. These are customers like you and me trying to take care of our livelihoods, and so I’m very proud to be part of an organization that serves to protect all of us. It’s a daunting task, and it has been a long route because I didn’t start on this path initially.
The long way around
I began my journey majoring in computer science with a focus in software engineering. I didn’t like hardware or networks, and back then that’s where security was—so I was adamantly opposed to doing anything with security. I wanted to build things and make things go, but there weren’t many entry-level jobs for computer scientists at that time.
It just so happened that Bank of America was one of the companies recruiting on campus for technologists. I’ve been with the company for 15 years now and I’ve had many different roles over that time, only truly in security roles for the last four years. I don’t regret my career path and that’s because I’ve learned how to connect the dots between the things I’ve done, the things I’ve learned, and what that means from the security implications perspective.
Consider these three questions
I encountered three questions that shaped the path I’m on today. What are we trying to protect, why on earth do we need to protect it, and how do we actually protect it? These three simple questions apply to anything you work on and anything you’ve done. If you apply these points, you can connect all the dots together and be a successful security professional.
I look at every role I’ve had as being a different cog on the wheel. All these things work together. If you know what that next cog on the wheel is responsible for, the next one down teaches you more empathy for what the rules do. It helps you anticipate what’s needed from you and how you can contribute. I initially didn’t want to do anything related to network and security, because I had no idea that they were all interconnected yet.
What are we protecting
I spent 11 years in our customer data space. I read and created TPS reports and then got into a role where I was doing database analysis. From a software engineering perspective my bread and butter was SDLC, and that’s what I was focused on—delivering new software. Security was still the furthest thing from my mind.
I built data dictionaries figuring out how we were using our data and how it was flowing so that we could build faster, more scalable, and reliable systems with better data integrity. It was a really eye-opening experience. There was instance where I wiped out a pretty important table in our test environment. I pretty much single-handedly brought down all integrated testing for individual customers by wiping out a table inadvertently, because I had direct update access to the database and I made a mistake. So even back then there was a need to be protecting—protecting me from myself. Anyone part of a security organization inside a larger company is protecting us from ourselves in a lot of cases.
From there I moved on to a role where I was in the application design lane. I was actually part of the project where we first rolled out security and fraud alerts to our customers, and in my mind even though the project was called “security and fraud alerts,” I was not working in security, I was delivering software. I had to think through every possible scenario and build the use and functional test cases and test plans to ensure that any time a customer does something with their accounts that somebody else could do in a nefarious way, we need to be able to inform them. So these were some of my early forays into security that I didn’t even realize were going on in my head.
Why do we need to protect it
From there I went into a number of other roles and eventually moved into an application manager function. I worked on alerts and ended up managing that application that sends six million alerts every single day to our customers. From an operational risk perspective I had to know how to recover my app. If there was a smoking hole in the ground because the data center no longer existed, I had to have a plan for that. Implementing change without having negative impacts to systems that provide services to customers 24×7 was a huge part of the role. There are a lot of rules and checkpoints that took away from focus on innovating and I really had to concentrate on a lot of governance. I started to learn why we had to protect our systems because of that.
I was asked to take on a new role because there was so much of this overhead. We had 70 customer data applications to worry about and we needed to have somebody make sure we were keeping on top of security, risk, and compliance requirements. My boss at the time called me the process queen, always asking the painful questions. So I moved into a role where I was overseeing the whole portfolio trying to make us safer, more secure, and compliant.
We still need to service our customers at the end of the day. They still need to be able to bank. You want that protected and you certainly don’t want anything happening to you as an individual customer of a bank that would impact your ability to do that. So I needed to be able to tell my peers the story of why you have to be PCI compliant, why you need to do ethical hacking on your application, and what are all those things that could go wrong.
So I started going to conferences, talks, and seminars to try and learn more. I had the opportunity to hear a couple of speakers early on in this sort of risk management role that blew my mind. One spoke of a small ATM card processing company that had the largest ATM drawdown in history at the time. The company had grown through acquisition and struggled with asset management. Social media proliferation played a part too, as outsiders were able to find out who the developers on their card systems were. They could send an email asking for database schematics, as if they were working on the project as part of the team. From there they were able to get into the code repositories and change the code to remove the withdrawal limits on the ATM cards, ultimately withdrawing more than $4 million all at one time one Saturday morning. So listening to this story I was on the edge of my seat with a really good example of why we need to be protecting our banking technology.
I also had the opportunity to hear Dan Geer speak about the trade-offs in cyber security, finding that balance between convenience and not having those worst-case scenarios happen. I went home that night and realized a turn in my career path. I needed to get into security because now that I’ve spent my career learning about the ‘what’ I’m learning more and more about the ‘why’ and it scares the heck out of me every time I hear another example of a worst-case scenario.
How do we actually protect it
My next step was to learn ‘how’ to protect us from these things. At the time we were creating a Business Information Security Officer role, to be able to take these worst-case scenarios and apply it in context around the ‘what,’ to help influence my colleagues. I moved into that role in our security organization and had to be able to connect the dots and figure out how does what I did before apply to this business context. I also had to be able to convince other app managers of the same thing that I’d convinced my peers of years earlier. I communicated that app managers have the hardest job in the company and we’re asking them to do so much that it can paralyze them if we don’t work together in a smart way. That helped give me credibility because they understood that I’d been in their shoes. It helped them listen to me when I said you need to care about this worst-case scenario that we’ve heard about. Working with other teams within cyber security helped me to tell those narratives.
I recently moved into yet another new role within our operations team, cyber security defense if you will, and I’m overseeing a transformation program that’s taking a look at our existing operational processes from a security perspective. While I’m new to SecOps, the experiences I’ve had in the past and the ability to take a process or a system and deconstruct it and understand the nuts and bolts is directly applicable. The time I spent as an app manager keeping the lights on, working production incidents, or working overnight to deploy change without impact are all directly relevant to the SecOps world. It also allows me to relate to my teammates in that space and understand their processes.
Connecting the dots
I encourage you to consider how to draw on your past experience and how to connect those things together, because they really are connected and they all lead to cyber security. You may even take a step out of a security organization and do something with a security lens in the business to understand the ‘what’ and then apply those three things together and see how the ‘what,’ ‘why,’ and ‘how’ tie together.
Watch the full interview here:This entry was posted on Monday, March 11, 2019 7:05 pm