What is a BISO?
How a BISO can help accelerate Fintech innovation.
Overview of Podcast
For this 15th episode of Access Control Podcast, a podcast providing practical security advice for startups, Developer Relations Engineer at Teleport Ben Arent chats with Alyssa Miller. Alyssa is a seasoned hacker and highly experienced security executive. Alyssa began her career programming for a Wisconsin-based provider of financial software and services. Later moving into a leadership role within the ethical hacking team, conducting pen tests and app assessments. This was followed by working in consulting, which provided a unique perspective on the challenges of the security industry, and then working across multiple organizations and high-level executives to address security at a strategic level.
This brings us to today, where Alyssa directs security strategy for S&P Global Ratings as a Business Information Security Officer (BISO). S&P Global is a 162-year-old finance services company, with over 50k employees. Today we’ll dive into how Fintech companies can learn the best practices and navigate the regulatory landscape, and how to embed these security practices to truly shift left and empower developers.
Key topics on Access Control Podcast: Episode 15 - How a BISO Can Help Accelerate Fintech Innovation
- BISO is a fairly young role within cybersecurity that gets structured differently across organizations. A BISO's primary goal is to provide a bridge between the cybersecurity function of the organization and the individual business lines.
- S&P Global Ratings, part of S&P Global, is focused on credit ratings for organizations and sovereign nations.
- When looking to adopt new technologies, you have to consider what this means in terms of the regulatory environment.
- If you're starting up a fintech, you're going to be working with regulatory bodies. Regulators can help you understand what the right ways are to be compliant with specific regulations.
- The best thing you can do with a regulator is give them reason to trust you, by showing them that you're thinking about the things that you should be thinking about, and by doing the right things.
- Compliance can be broader than regulation. Regulators such as SEC, FCA and ESMA vary based on the environment that they're in. The key is to work with them proactively.
- Getting software to production involves what can be described as a three-headed monster of responsibility: software has to be delivered efficiently, has to be stable and has to be secure.
Expanding your knowledge on Access Control Podcast: Episode 15 - How a BISO Can Help Accelerate Fintech Innovation
Transcript
Ben: 00:00:02.712 Welcome to Access Control, a podcast providing practice security advice for startups, advice from people who have been there. Each episode will interview a leader in their field and learn best practices and practical tips for securing your org. For today's episode, I'll be talking to Alyssa Miller. Alyssa is a seasoned hacker and highly experienced security executive. Alyssa began her career programming for Wisconsin-based provider of financial software and services, later moving into leadership role within the ethical hacking team, conducting pen tests and app assessments, followed by working in consulting, which provided a unique perspective on the challenges of the security industry, working across multiple organizations and with high level executives to address security at a strategic level. This brings us to today where Alyssa directs security strategy for S&P Global Ratings as a business information security officer (BISO). S&P Global Ratings is 162-year-old financial services company with over 50,000 employees. Today, we will deep-dive into how fintech companies can learn best practices and navigate the regulatory landscape and how to embed these security practices to truly shift left and empower developers. Alyssa, thanks for joining today.
Alyssa: 00:01:18.950 Hey, thank you, Ben. It's great to be here.
The BISO role vs the CISO role
Ben: 00:01:21.005 So to kick things off, can you tell me a little bit about the role of the BISO and sort of how it's different from CISO?
Alyssa: 00:01:27.147 Sure. So yeah there's some similarities and differences, right? And the BISO role, honestly, is a fairly young role within cybersecurity and so there's a lot of organizations that have structured it a little differently than others. But the primary goal of the BISO, ultimately, is to provide a bridge between the cybersecurity function of the organization and the individual business lines. So in my case, with S&P, we've got now six divisions across S&P, and each of those divisions operates as a very much independent organization, but all a part of the S&P Global umbrella. And so my role as BISO, I actually report into the division, okay, so I'm the head of cybersecurity security for our division. And rather than reporting to the CISO at the top corporate level like maybe a deputy CISO would or something like that, I actually report to a divisional CTO. And I operate very often as an advocate on behalf of the business when we're collaborating and interfacing with the security team. And so in that sense, it's similar to a CISO, and that I'm kind of that top-level leader within that division for cybersecurity but different because I am a part of the business line, I'm not part of a corporate enterprise function like the information security team.
The challenges a BISO faces
Ben: 00:03:01.778 And so can you give some examples of some business requirements that are unique in this role and how the BISO role sort of navigates themselves, those challenges?
Alyssa: 00:03:09.747 Yeah. I mean, I think the biggest thing is really being able to understand the business itself. If you're in a centralized security organization and you've got multiple divisions and multiple business lines, it can be really hard to have that understanding of what's really important to each of those business lines. That's so much information. So I'm more integrated with the day-to-day ratings business and can understand, for one thing, our business line, our division within ratings is very heavily regulated. As opposed to some of our others, where some of them don't have to conform to any specific regulations at all. And so that right there creates an interesting dilemma for a centralized security team where, okay, how do I build a cyber security program that meets the needs of an organization that isn't heavily regulated, and is very agile. Versus this one over here that is very innovative, but also has to achieve certain regulatory requirements. So that's one of those cases is we're having a BISO involved to really understand how some initiative being driven by a security team may or may not negatively impact the business organization itself. A great example of that is just writing standards.
Alyssa: 00:04:31.830 A lot of times you see security teams will write a standard as a way of trying to influence behavior. So we want our teams to do XYZ so we write a standard that says you must do XYZ, and then it's up to them to adopt that. The problem is if you do that in a regulated environment, our regulators are looking at our standards. And if we have a standard that we're not yet ready to comply with, and we codify that as a standard, now we're out of compliance. And that's something that our regulators have an issue with. So there's a very different balancing act that we have to make sure that the standards that we publish where we say this is what we do all the time are not done as ways to change behavior. But are done as ways to codify behaviors that we already do.
Ben: 00:05:14.098 Yeah. Yeah. So instead of it being sort of aspirational, it has to be stuff that you're actually in practice doing?
Alyssa: 00:05:20.026 Yeah. Stuff that we're — maybe it's not 100% across. And so maybe passing that, or creating that standard, will help bring where there's areas that haven't adopted it up to speed. But we have to at least have that capability. If it's something new we've got to build, you can't give me a standard says I have to be doing it today.
S&P Global Ratings and adopted technologies
Ben: 00:05:39.502 Yeah. And so for those who are unfamiliar with S&P Global Ratings, can you tell me a little bit more about the company?
Alyssa: 00:05:46.463 Sure. So S&P Global Ratings, part of S&P Global. People might also recognize as Standard & Poor's. So the ratings business specifically is focused on credit ratings for organizations and sovereign nations, things of that nature. So you'll see us in the news from time to time when especially sovereign nation ratings are released. You'll see information about that pop up in financial news and whatever. So that's our role, and that's what we do globally. So you can imagine what that means in terms of regulations, because those credit ratings have the ability to potentially impact markets and market movement. And so that's something that within various economies is really crucial to make sure that it's done properly.
Ben: 00:06:33.301 Yeah. And it's a relatively old company, it's a 160 years, so obviously, it's changed over time. How is it currently sort of embracing technology?
Alyssa: 00:06:43.689 That's one thing that's really great. You would think we're all traditional financial services, they got lots of old technology. The reality is we've taken technology and used it to enable our business. And so a lot of the more, I don't want to say cutting-edge necessarily, because that has its own connotation, but definitely contemporary technologies — things like cloud-native and functions and containers and so forth and leveraging a DevSecOps pipeline, that type of approach to technology. Where can we make, use, as you can imagine, with something like credit ratings, looking at the use of machine learning and artificial intelligence, and how can those help, and what challenges do they bring us from the regulatory side? We definitely embrace the latest in technology where it helps enable our business.
Impact of regulation on security and technology decisions
Ben: 00:07:30.570 Yeah. And so I guess, as a global company, you have to sort of navigate this large regulatory landscape. How does this tie into the security and technology decisions of some of those examples, so let's say, AI or machine learning from a security perspective?
Alyssa: 00:07:46.230 I mean, anywhere where you're heavily regulated. So I've been working in — you mentioned I started my career in financial services. It's always as you look to adopt new technologies, you just have to consider what does this mean in terms of our regulatory environment, because a lot of times the regulatory environment — those requirements that were written based on previous technologies that maybe didn't account for what we have today. A common regulatory theme when you're talking about machine learning and especially AI these days, and again, this is across all industries where regulatory issues come into play, one of the ideas is just the idea of explainability. So if I've got this artificial intelligence thing going out and doing what it's doing and making decisions for me from a regulatory perspective, you need to be able to explain those decisions. What happened? How did this particular decision get made and be able to track that back and show the steps? Because in many environments where you're heavily regulated, that's something that is going to be needed. There has to be that audit ability, essentially.
Ben: 00:08:54.570 Yeah. So that it checks for the black box instead of just putting numbers in, numbers out.
Alyssa: 00:08:58.386 Yeah. I mean it's not going to be acceptable to most regulators to just say, "Well, the AI told us so that's what we did."
Tips for startups working with regulators
Ben: 00:09:04.471 Yeah, you need to explain it. So any kind of fintech that's starting — I guess they're going to start talking to regulators from day one. Can you just talk about people starting a fintech company, what sort of regulation will they sort of see and sort of what are some tips for working with regulators once they sort of go apart that journey?
Alyssa: 00:09:23.128 Yeah. So it's always people kind of balk at the idea of regulation and regulators, right? I mean regulators kind of have gotten this really negative connotation. But yeah, first of all, if you're starting up a fintech, obviously you're going to be working with regulatory bodies. If you're getting into banking, you're going to be dealing with here in the US, it's FFIC. If you're in the UK, it's FCA. If you're getting into the markets, of course, you're going to have the SEC is going to be interested in you. It all depends on what part of financials you're getting into, but certainly, there are different regulators out there and it depends what country you're in. If you're in the EU, ESMA is another one that I'm very familiar with, and some countries — and that's a challenge too, right, when you go globally is you're dealing with different regulators. But where regulators kind of get this bad name, or this sort of negative connotation, honestly, regulators can be your best friend. I mean, regulators can do a lot of really good things for you. They can really help you understand what the right ways are to get through and be compliant with specific regulations.
Alyssa: 00:10:35.611 And the key there is just working with them proactively, right? Building relationships with the regulators is crucial. Finding who are the people that you're going to be working with, year after year, and how can you establish more of a conversational relationship instead of just waiting for them to come audit you or to do a review or something like that. Be in touch with them and be honest with them. I think where a lot of organizations kind of get frustrated is they feel like the regulators are maybe too involved or too nosy or whatever or they're too strict on things. My experience in now God, almost 25 years of working with regulated environments, what I found is that when you get a good relationship with your regulators you understand who they are, they understand who you are, and they understand that you're trying to do the right things. The best thing you can do with a regulator is give them reason to be confident in you. So show them that you're thinking about the things that you should be thinking about. Do the right things. If you're making sacrifices for the sake of the dollar or the pound or the Euro, well, that's a dangerous territory. But even then, there may be explanation for that. And again, it's not regulators are just chopping at the bit to find a violation and define. No, but they also want to make sure you're doing the right things. And what they don't want is to have someone sneak under their radar and to see them or whatever where they think you're complying with regulations and you're not. So just take that a little bit of empathy and understand what their structure is and use them as an ally rather than trying to work against them.
The difference between compliance and regulation
Ben: 00:12:30.576 Yeah. And I don't know if you can explain a little bit the difference of sort of compliance and regulation. So people are pretty familiar with the frameworks of SOC Two or PCI, which is sort of guidelines and frameworks to get to a certain level. But I guess compliance can be different from regulation.
Alyssa: 00:12:46.512 Yeah. I mean, compliance can be so much broader. Obviously, there's compliance related to your regulatory environment. Right? I mean, you need to be compliant with your regulatory environment. But that conversation before about standards and things. Now if I say, "Hey, I'm going to adopt ISO 27,002, and that's going to be my framework." Well, now I need to be compliant with that framework. Right? If I'm establishing standards and other things within my org that speak to how we're adopting ISO 27,002. All right, great. But now I have to demonstrate my compliance with that. So of course, you're doing that with the regulators. You do need to demonstrate that compliance. But it's so much broader because it covers more than just those regulatory pieces. Or hopefully, it does. I mean, hopefully, your organization is implementing your own frameworks. It could be NIST, it can be ISO, it can be whomever. But one, just showing that you have guiding principles outside of what you're just being told you have to do by your regulator. And then two, that you're actually demonstrating that you're achieving those and that you're following those and even where you have exceptions to that process where you can't achieve a certain thing or you don't follow a certain thing. But there's a reason for that. And you're understanding and acknowledging that risk and then documenting that and just accepting that this is something that within our organization adds to our risk profile and we need to be aware of it going forward.
Approaching regulatory requirements in flux
Ben: 00:14:21.757 Yeah. That kind of leads me to my next question, which is around sort of new and interesting areas of sort of like fintech. It's the whole cryptocurrency markets. It's always in a constant state of flux between what the ecosystem is doing and then also the regulatory requirements. As a BISO, how would you sort of approach these regulatory requirements that are sort of always in flux?
Alyssa: 00:14:41.788 Right. This is where you get deep into the business, right? So coming from a security side and having business kind of these are types of conversations where it's important. So for me as a BISO, as I look at something like that, as I look at the expansion of cryptocurrency markets and where the business might want to get involved in some of that, what I'm really looking to understand is, all right, how are we building this according to best practices? Because truly, as you said, that regulatory environment is changing a ton. Here in the U.S. we just saw some new actions being taken by our President towards the cryptocurrency markets and how some of those regulations should be applied. And so you can't predict that, right? There's just not a way to predict it. But this is where it comes back to if we focus on our best practices, we follow our frameworks from cybersecurity, from business risk, from all the way up and down. If we're doing the right things and we're addressing it responsibly and we're doing the responsible thing on the part of our customers. It doesn't matter if we're a bank, if we're in investments, if we're an insurance, whoever we are. Working to establish those best practices, regardless of regulation makes it a lot easier than when the regulations do come or they do change because you're already ahead of the game.
Ben: 00:16:06.763 Yeah.
Alyssa: 00:16:07.324 You've already done the right things. And now it's just a matter of making the translation from, okay, this requirement is here that they just passed this whole new set of requirements. This one maps to what we're doing here. This one maps to what we're doing here. That's where when we think about the value of a BISO. Right there is a great example of I can sell to the business my value and the value of cybersecurity because, hey, we're building this program, we're really focused on how we do the right thing from a security perspective so that when the new regulations do come at us or we want to expand into a whole new line of business, a whole new market, something like that, we've already done the right things to achieve that compliance. We're not having to go and make a mad scramble to make sure that we're covering all the bases on the regulatory side. We can be confident that we've got what's needed in place and just simply provide that mapping to demonstrate our compliance.
Ben: 00:17:02.811 Yeah. And I guess it's probably common sense. Like in the US, you know your customer rules are pretty strictly enforced, which is the same for any financial service. It's maybe not a hard requirement. You can transfer from one wallet to another. But KYC is there for the protection of both the customers and the businesses.
Alyssa: 00:17:21.280 Yeah, exactly. And I mean, obviously, there's national security and other things that get involved in there sometimes, too, right?
Ben: 00:17:27.104 Yeah.
Alyssa: 00:17:28.200 But no, that's the reality of it. And it's not just the US. It's, of course, many countries that kind of have that same principle. And certainly, it applies to some sectors of Fintech more than others. But it's always something you have to be aware of. So, again, knowing that you're doing the right things on the front end, and this is why as we're thinking about startups, it's very uncommon for a startup to think about security right out of the gates. Very few startups are looking at, I mean, you look at the numbers on how long it takes from startup to the point where a startup company is adding a CISO.
Ben: 00:18:07.626 Yeah, or even a first security hire could be employee 30 plus.
Alyssa: 00:18:11.678 Yeah. That first security hire is like years down the road. But if you're getting into a highly regulated industry like Fintech, it's really important that you start addressing it early because it's going to save you headache in the long run. It's going to provide you immediate value that will save costly changes down the road, costly efforts down the road. You've got somebody there who's doing the work from the start and who's bringing those aspects to the table early, making sure you're proactive and really helping drive that value for your business.
Comparing regulators: SEC, FCA and ESMA
Ben: 00:18:46.478 So you kind of said there's the three different main regulators, like the SEC, the FCA, ESMA. Can you say how these bodies are both the same and sort of how they're different?
Alyssa: 00:18:56.525 I don't want to get into the specifics of talking about each and every regulator, but it's just to understand that they vary based on the environment that they're in. So what political environment they're in. Certainly. EU has its own areas to think about. So when we think about ESMA, you've got this, sorry for the bad term, but League of nations, right? A whole group of nations who formed themselves under the European Union. There's a lot of different cultures. There's a lot of different approach to what's acceptable and not what's not within financial services in the UK with the FCA. Of course, you look at what goes on politically within Great Britain, and it's a very different story. Singapore is another one that has a really strong financial regulatory body. And I work with Maas. So they're again, very different country, very different thing. Every one of them is implementing things that are very important to them for different reasons politically and otherwise. Just culturally and geographically there are things that may be very different from one regulator to the next. And that's why it can be challenging at times when you do decide to go global, because you will find that it varies considerably just as you go from one country to the next, you go from one form of government to the next, governments with different motivations, all of that.
Ben: 00:20:17.779 Yeah. And I guess it's even in the US, like different tax, different states, different cities. It can get pretty complicated pretty quickly.
Alyssa: 00:20:24.027 Thankfully, in the US, most of your regulators are going to be federal, so they're going to be at the US level. But yeah, there's still, I mean, there's legislation at a local level. Certainly, here in the US, we don't have a federal privacy law, for instance. But if you're doing business in California, which is pretty hard to avoid doing business with, or in California, you have to be aware of CCPA, which isn't all that much different from GDPR, and so those types of things, that's where that can get challenging. The regulatory bodies, not so much because those tend to be federal. But some of that can even vary, too, based on, again, which sector financial services you're digging into.
Regulators as a force for innovation
Ben: 00:21:03.386 Yeah. And I know as an Englishman, I'm sort of glad to see the results of the Bank of England's new bank start-up unit. And I think it was maybe a decade ago, it was created to enable new fintech companies to not only provide a better sort of UX for a bank as a layer but also be the bank. And I think Monzo is a great example of one of the startups that sort of gone through this new program. And I guess it's sort of counterintuitive. I see this as a way in which regulators have actually helped with innovation. Given any other examples in which regulators are like pushing sort of startups to be more innovative?
Alyssa: 00:21:35.745 I don't know that I have a specific example, but in general, that is a motion we're seeing. Again, back to the point. Regulators do not want to — they don't want to stifle business as much as that's kind of the line that's thrown around sometimes politically and otherwise. Everything that I've ever experienced with regulators is they just want to make sure that business is being done correctly. And they actually like to see new technologies, I think even more so now than ever before. And I've seen that progression, right? But where they certainly seem to have — they've embraced the idea that new businesses, new innovation is actually good. It's good for the market, it prevents that — the infamous thing we get to talk about here in the US is this idea of banks that were too big to fail back in 2008 when there were all sorts of global issues with financial services because of just massive global recession. Those situations, regulators definitely come to see more of that. Okay. Where we have innovation, and it pushes, and we have more of that fluidity in terms of who's in that market space and who's driving who, they've come to accept some of that and provide runway that makes it easier for those organizations to get started.
Incorporating business requirements into software creation
Ben: 00:22:52.963 Yeah. So we talked a lot about regulation and regulatory requirements. How can we sort of take these sort of business requirements into account when sort of developing and creating new software?
Alyssa: 00:23:05.210 So this is where things like reference architectures come into play, understanding that your engineers are going to have certain repeatable patterns, right. It's a win-win when you're able to create things like that. Because now it's, hey, we did this once before. This was the way that we went through and it worked. We were able to establish it. So now the next time we do it, it's a lot easier if we just follow that same path. So that whole idea of just that reference architecture concept where, yeah, we're going to have to blaze some trails, so we're going to have to create new ones. But really, as we're working through design, putting up something that makes sense in the long term, it doesn't have to be that you have some big design cycle, right. I mean, especially for those of us doing DevOps, CI/CD, it's just user stories. We're pounding out one after the next. But you still have that opportunity to say, all right, we built something that worked. We built something that addressed these needs. Let's capture that and let's leverage that. And we can always be reiterating on it, on how it can be improved. But it gives us a starting point. Where we get into trouble so often is, someone creates something over here. Then a new business line pops up over here with their own engineering team, and those engineers go do their own thing. And no one's really looking at this idea of reuse, has been around as long as I have. I was an engineer 25 years ago, and we were talking about reuse. Now it's taken on different forms. And I'm not talking about reuse and using the same code or things like that although. Obviously, we're doing plenty of that with the open-source world but just being aware and being able to follow some of those key architectures, what it does is let you create that paved road where now it's like, all right, the easiest route to get from user story to post-deploy also happens to be the route that I want them to take because it's the most secure. It's the one that addresses our regulatory obligations and hammers all of it. And so that's what you're ultimately trying to build.
Security as part of the development process
Ben: 00:25:02.188 Yeah. And so you sort of touch a little bit there on sort of DevOps which was a very successful model between the combination of operations and developers, and yet we still sort of see security post-development process. Can you give some thoughts on why security is still a bit of an afterthought?
Alyssa: 00:25:19.251 Yeah, I'm going to make all my security peers probably angry when I say this but security people are arrogant, quite bluntly. So DevOps introduced the idea of the concept of shared responsibility. And the idea was that the engineering teams and the operations teams were both responsible for the same set of goals. They were both responsible for making sure that software got to production fast and that it was stable when it got there. Security came into the mix and we kind of said, ''Oh yeah, that's great. Shared responsibility.'' Security is a shared responsibility. Everybody has to do security, but we kind of forgot about the other half of that. And that is that we have to take on responsibility then too. Now you've got this sort of, if you will, three-headed monster of responsibility of software has got to be delivered efficiently, it's got to be stable, and it's got to be secure. So if I say that my engineers and my devs, my SREs, and my devs are going to be responsible for all three of those. Security has to be responsible for all three of those which means that when we bring things like threat modeling or code analysis or dynamic security testing to the pipeline, we can't do it in a way that breaks that efficiency. We can't do it in a way that's going to impact the stability of that code when it's deployed, but we don't come at it that way.
Alyssa: 00:26:41.219 Unfortunately, security still has this attitude of, well, we're going to build quality gates and we're going to install security things and we're going to stop the pipeline, run a security scan task whatever, and then we'll come back with a long feedback loop. We'll finally come back and give you results. And if the results aren't good, well then you got to start over. And that just breaks the pipeline. I mean, that breaks down everything that DevOps was ever about. This is where, as security practitioners, we need to be looking at things like security champions programs. How do we embed security expertise in those development teams because especially as we move to a CICD function and we're doing DevOps where we're just we're constantly pulling user stories and our deployments are happening faster and faster and faster. We can't slow things down. We need to be a part of, instead of building a gate between phases, we need to be a part of every phase and approach it that way in that it doesn't have to be a security person. I don't need to have my whole security team have every one of them assigned to every phase. If I'm building security champions, I'm taking engineers and I'm empowering and enabling them to take on some of that security tasking. And I'm trusting them with that. And I'm taking my QA team and where they're involved in that, Hey, if I'm establishing a security champion within QA, how can they be a part of that when that phase hits them? And that's where it's a very different mindset for security than we're used to.
Ben: 00:28:16.702 Yeah. I guess in the world of sort of continuous deployment, if you're always deploying all the time, you don't have to worry about like patching servers that are old because within an hour or two days or an hour or two, like the whole — everything's going to be cycled again. And I guess as long as you update whatever have problems at that point. It's a short window, I guess.
Alyssa: 00:28:36.916 And that's exactly the case. Right. So this is one of the things that's really hard to get security people to accept. And that's the idea of, you can deploy with a known vulnerability. That freaks them out. Right. I mean, that freaked some of my peers. I talked to people about it, they hate it. They hate the idea. But if your CI/CD is mature enough and you're releasing fast enough. Yeah. You found a vulnerability. Instead of breaking the build, continue on, document that, put that in the P1 item back on the backlog. That's the next one that's coming in the very next cycle. You know it's going to get fixed. And as you said, if you're deploying every hour, if you're doing 24 deploys a day because you're that mature in your CI/CD, you know it's going to be fixed before it even has a chance to really be an issue. Now, there might be a few exceptions where, for instance, let's take an easy one, log4J. So log4J gets discovered, and now maybe you do break the build if that remote code execution vulnerability is in the code, and you know about — you might stop that one just because you know that there's a concerted effort in the interwebs to exploit that. Like there's exploits going on all over the place because this thing was just announced and so everybody's trying to find it. So maybe in those rare instances, you might implement a build-breaking step. But on a day-to-day basis? No, not if you are mature. But that's where we as security have to look at it differently. Right. Because now security's goal is to make things more efficient. It is actually addressing that security goal, too, because, hey, let's get that pipeline to the point that they can deploy every hour, because then I know if I've got a vulnerability they got to fix, they can fix it pretty quick, too.
Examples of security increasing team velocity
Ben: 00:30:16.221 Yes. And so I think there's obviously a lot of talk on the Shift Left part. It's sort of been earlier in the process. Can you sort of talk about how security, or maybe this is to do with the Security Champions, but how you sort of embed, and some practical examples of how you've seen shift left be efficient.
Alyssa: 00:30:37.156 Sure. Yeah. Security Champions is one, right? I mean, we've been talking about Shift Left, at least for the 25 years that I've been in tech, certainly for the 16 of those that have been in security roles, it's always been the thing. And we've always talked about, well, there's that thing. It actually comes from the development world. But if I have a bug and I fixed it in development versus if I fix it in test versus if I fix it in production, how much it costs. And we've been using that rightfully so, for a long time to try to push that message. But yeah, Security Champions is one of those ways, because you get that expertise, you get it in there from the beginning, especially where you have a very mature DevOps pipeline. And Devs are just grabbing the next prioritized user story and going. Having that inherent in those — if you got Scrum teams or whatever you're working with, whatever model you're in, having that expertise there is important. It also provides information sharing, like I was discussing before. Certainly, those reference architectures are another way because they give you a library of "turnkey," quote-unquote, I hate that term. But I just used it, turnkey solutions, but really designs that, hey, if I'm a developer and I want to move fast, I can go look at how someone else did it, and I don't have to come up and reinvent the wheel. Great, let me do that. Right?
Alyssa: 00:31:57.606 I mean, engineers will love that. And then the other one — and this is where people are going to kind of freak out at me again, threat modeling. So threat modeling is this thing that everybody thinks of as like, oh, my God, we're going to put a bunch of people in a room, our engineering teams have to create a bunch of drawings in advance, and then we're going to sit for hours and talk about threats and blah, blah, blah, blah. Forget all of that. If we return to the basics of what threat modeling is, it's just answering, hey, what are the most important assets? And what could go wrong with them? And then that can inform how we develop. So if you bring threat modeling to user story. And don't make it the security stuff of STRIDE and PASTA and all the weird frameworks and things that we've created for years and years and years. Ask the people who write in the user story, "What's the thing that's most important in this user story? What is that one said that's most important? And then what is the worst thing that could happen to it?" Just get that much information. Get that in the user story. So now when your engineer takes it they understand, and they can start to think about how do they build security around that? And if you've got the reference architectures, they can pull that and then that information can feed and it feeds all the way through the pipeline because it can help you when you're building security test cases, because you understand what you should be looking at, what's most important to look at from the security test case perspective, post deployment, you know what you need to be monitoring because you know what's most crucial? Instead of trying to boil the ocean, let's get incrementally better by just understanding what are the key, most important aspects of each user story and what do we need to defend them from the most and address those.
Ben: 00:33:40.938 Yeah. And I guess that's often a critique of the security industry. It's always focused heavily on the offensive side as opposed to defending. And maybe that's because there's not that many developers — the security people are creating tools for, let’s say, pen testing or assessments as opposed to writing tools to stop them. And I think that's sort of an entity might take your tactic and bake it in early when you're sort of there writing the code.
Alyssa: 00:34:05.489 Well. And we're creating security tools for security people. Right? And this is a problem. You need to create security tools for engineers, for your developers, for your QA folks. Tools that they can leverage easily without having to have a master's degree in cyber security or something.
Ben: 00:34:25.088 Yeah. And it's probably even as simple as, like writing a secure Regex or cross-site scripting or CSRF. There's like well-known vulnerabilities that you can easily trip yourself up on, which I guess, to kind of go back to your reference, they're sort of standard patterns that you can solve them.
Alyssa: 00:34:39.832 Yeah. Again, it's where you can't try to think that you're going to solve every vulnerability ever. We know that that's not the case, and that's where the whole conversation turns to resiliency and so forth.
Making the business case for security and technology initiatives
Ben: 00:34:51.689 Yeah. So my other sort of question is you take a security and technology initiative, let's say, for example, an investment in Zero Trust, how do you sort of take that initiative and make sort of the business case for it? I guess it's sort of the inverse. Instead of taking business requirements, you take technology requirements for the business. How is sort of that flow sort of back to the business?
Alyssa: 00:35:12.440 You hit it on the head again. And this isn't even just a security problem. This is a technology issue, too, right? Technology teams do this a lot, too, trying to drive the solution into the business instead of letting the business drive what technology, what security, you adopt. So when it comes to security, really, the key is showing them how does what I'm proposing enable the business. I'm going to stop right here and address something that drives me bonkers. Enabling the business is not reducing risk. That is not a business-enabler. All right? And again, I feel like I'm probably going to — nobody's going to want to talk to me anymore after this. But seriously, business enablement means how do I make the business stronger in terms of creating revenue, in terms of innovating, in terms of finding new markets. Yes, reducing the risk of those might be one element. But here's the thing. Consider this for a minute. When the business looks at risk, cybersecurity risk is not the only risk they face. There's market risk. There's financial risk. There's competitor risk. There's all sorts of risk. If you have an MBA, these are things you learn about.
Alyssa: 00:36:28.146 Cybersecurity risk is 10, maybe 20 percent, depending on your business, of that entire risk picture. So if that's your story, that's the value you're bringing, you're not bringing a very compelling story because your story says, "Well, I'm going to fix this 20% thing for you." No, who's getting excited about that? That's not enabling the business to move forward. What does enable the business to move forward is again, where you can show them, "Hey, we're going to do threat modeling like this and look at all the stuff that it's going to do to actually speed up your pipeline. It's going to get you deploying faster. We're going to bring in this automated tool that's actually going to get you through these steps faster in your pipeline. We're going to implement this new CASB technology that's going to allow you to offer all sorts of really cool new cloud- based services or SaaS products that you weren't able to do before. And when you start making those connections with the business and you say, "Hey, this is going to enable you to do this," you win a business sponsor. Now it's not just about getting them to adopt it, it's getting them to want it because, "Oh, I could do a really cool thing here if I implement this security thing." Well, I'm going to support this security thing because it's going to let me do that really cool thing. That's the key focus.
Alyssa: 00:37:53.953 And it takes, again, a different mindset, a very different mindset than what we're used to in security. We're used to being oversight and instead really just be a part of the business instead. And let's drive those conversations that way. And this is, again why we started off talking about the BISO, why I think a BISO is so critical, because that understanding of the business side of things. I, as BISO can see where there might be new motion. I'm talking with the business all the time. I'm understanding the things that they're thinking might be cool or new exploratory markets for them and so forth. I can now recognize how a security initiative that I feel like we need links to that and gain those sponsors for it.
Tip on achieving business and security goals
Ben: 00:38:41.087 Yeah. And ultimately empowers the whole organization beyond just a check mark. We have cyber security. We've not been hacked yet. Go about our business. So to sort of wrap things up, can you give a closing tip on how teams can work better with businesses? Kind of temporary to your last point to achieve both business and security goals.
Alyssa: 00:39:00.694 Yeah. So sit down with your business and understand what it is they do. It's this empathy card that thankfully more and more people are talking about in cyber security now where we need to have the empathy for the business. One of the key things that I love to bring up in this conversation, somebody asked me a while back, and actually it's come up a few times, if I want to get into security leadership, what is one thing I should learn or what is one book I should get or whatever? And my suggestion is learn MBA concepts, learn that business side of it. And I don't care if you're looking to get into leadership. If you're an individual contributor and say, a SOC analyst role, at some point you have to communicate something about security to a non-security person. So understanding how they look at the world, like I said before, like that whole risk picture where we're only 20% of the risk, when you're talking to a CEO and he or she's looking at like, oh, my gosh, there's all this risk I got to be aware of, cyber security is only a small part of it. So how can you speak to the rest of that? It's the same if you're an analyst and you've got some alert you're trying to convince the business they need to do something about, well, okay, yeah, that's one thing I'm worried about, but I'm also worried because, hey, AWS is having an outage and this region is down. How do you sort that out and how do you communicate to them in a way that they're going to be motivated to deal with that even though they've got these other things they're worrying about too.
Conclusion
Ben: 00:40:30.369 Cool. That's a perfect way to end this podcast. This podcast is brought to you by Teleport. Thank you for your time today. Teleport is the easiest —
Alyssa: 00:40:34.647 Yeah, absolutely. Thank you.
Ben: 00:40:35.288 — most secure way to access all your infrastructure. The open source teleport access platforms consolidates connectivity, authentication, authorization, and auditing into a single platform. By consolidating all aspects of infrastructure access, teleport reduces the tax surface area, cuts operational overhead, easily enforces compliance, and improves engineering productivity. Learn more at GoTeleport.com or find us on GitHub at Github.com/gravitational/teleport.
