AgileData #29 - agile security - Laura Bell

Welcome to the Agile Data Podcast, where we talk about the merging of agile and data ways of working in a simply magical way. Welcome to the Agile Data Podcast. I'm Shane Gibson.

Hi, I'm Laura Bell.

Hey, Laura, thank you for coming on the show today. So today I wanted to talk about agile and security. So what we find when we kind of adopt an agile way of working, there's large pieces of work that tend to happen upfront. So things such as the architecture, the platforms, and security. And so we always struggle with how do we, you know, eat that elephant in small chunks? How do we implement the right level of security at the beginning, iterate as we go, but don't spend, you know, an inordinate amount of time upfront worrying about the security architecture and getting it 100% perfect, but we get it right and we get ourselves safe. So before we rip into that, why don't you just give a bit of a background about Awesome.

Well, it's lovely to be here today. So my background is quite interesting. Like most security people, I sort of accidentally ended up there. I started out as a software developer. My first language was COBOL. You'll forgive me for being too cool. I moved on to Java and later was a PHP developer and in fact contributed to a number of the frameworks. I accidentally became a penetration tester when I realized I was quite good at finding bugs. Somehow now I've made a career of helping teams go really very, very fast and put security through building software. Part of that, I wrote a book or co-authored a book with some awesome people called Agile Application Security, and that's published by O'Reilly. My second book is due out soon, Security for Everyone. So this is something as an area that's really exciting to me. In fact, I have a whole company dedicated to it. So I now run a company called SafeStack. And we have SafeStack Academy, and the whole aim of that is to try and help as many development teams around the world as we can go really fast and weave security through their whole lifecycle. So, I think what I'm saying is we're trying to put our money where our mouth is and really kind of, you know, try and get this at a global scale. So, not just one or two unicorn projects. So, it's a very exciting space.

So, we often talk about shifting left, right? How do we take things that are normally done outside the team, increase their skills, their literacy, their capability, and bring it into the team, right? Just move it earlier in the process. So is that what you're saying, is that actually one of the gaps we've got is around the literacy of developers, engineers, to understand security, what should be implemented, what shouldn't, those patterns? Is that one of the things we need to deal with first?

I think so, but I think also the phrase shift left has been used probably for about 5 years now, but really, it's being misused and misunderstood a little bit. So, we're saying, "Yes, let's shift left," and we all agree with the principles. We move it to other people, we democratize, if you will, we give the power to all of the people in our lifecycle. But in application security, we also still rely on using phrases like, "Oh yeah, well, we shifted secure coding left." Now, secure coding as a phrase That really tells us something about how we're thinking about the shifting left and how we're thinking about the position of security inside our development lifecycle. Because security isn't just about the code, it's about the entire process that we need to shift left. So having a great idea and thinking about security in it, planning and architecting the choices you're going to make, implementing them and writing the code is part of it, but then there's testing, deployment, build, and then supporting that monster for the rest of its existence. So, I think we understand the principle, but we're still slightly naive, myself included, I find myself doing it, in how we understand what needs moving. Because it's really not just about the code we write, but every process that's involved in building that software.

Yeah, we definitely see that in the data world. So, we see that, you know, the first cut of the platform will tend to penetrate, you know, do some form of testing, or C&A, or whatever process we want to call it. And then we land the data, right? Because we wanna make sure the environment's safe before that data's available. And then we never touch it again, right? We start writing code, we start doing things with data, we introduce new components, but we've done the security testing, it's not a repeatable process. So, do you see that a lot? Do you see that still a standard way of working?

Now, don't get me wrong, like in any part of technology, there are outliers. There are definitely companies that are on the edge of this and that they are doing doing a very iterative combined testing all the way through. But for the most part, I'd say probably 90% of companies still are kind of stuck in that same loop where they're tying their security checks, their assurance, their activities to very big milestones. So you might be happily deploying your code every, you know, 10 times a week, who knows. But The penetration testers are only coming in once a year, and that's the extent of security. Or, you know, "Oh, well, we did a design workshop about a year ago when we started thinking about this feature." But that's not how our dev process is really working. Between those two events, there's been hundreds of thousands of little tiny decisions that have all impacted the security of it. And so, we're still, in a way, waiting till the very, very end, even though we know when we're moving at development speed faster, that we should be iterating quicker. It can be quite daunting to figure out how to turn these giant security activities into little things you can do.

So, why is that? Because in terms of DevOps, a lot of organizations have introduced the idea of automated testing, test-driven design, business behavior-driven design and testing, and all that kind of stuff. So, we've got relatively good at writing little tests, Then when we make a change, running them all and making sure we haven't broken something. Yet when we talk about security, I don't see that pattern a lot.

No, and it's— there are frameworks out there, they're not as well known. So, for example, the BDD testing you're talking about, behavior-driven development, we have BDD security as a framework you can use for security automation testing. So, the same way you would write a suite of automation tests for any of your human stories, you can do them for security misuse stories, if you will. The trouble with them is many of our automation testing frameworks underneath the hood, they hook into security testing tools. Now, security testing tools, they're not written with DevOps in mind. They're written from a time, you know, 10 years ago where testing was okay to run for 6 hours, and that wasn't a problem. And so you can write these minute tests and hook into them and run them quickly, but you spend quite a lot of time trying to go, well, how do I run just this tiny bit of the tool so that my build pipeline or my testing pipeline doesn't explode? And there's an element there that in a way we need to improve that security tooling and make sure that it's respecting the conventions and the expectations of how quickly they need to run that. It's not good enough that, you know, by putting security in, you bloat your timelines by a number of hours or a number of days.

Yeah, we definitely see that in the data world. So in terms of tools to test data, not code, you know, we're way behind our app dev brethren. So it sounds like the security space is the same thing. Where is part of the problem that when I work with large organizations, we tend to use external third-party organizations to do the testing. Now, there is that element of having the cop come in who hasn't been involved to give us that second sift. And I can understand that. But it seems to me that actually one of the core reasons we do it is because around that expertise, that literacy, that in the organization, there's never enough skills to understand how to test security, what's important, what's not, what we should repeat, what we shouldn't. And so, we bring those skills in, and because then they're external, you know, they're done based on a contract and for money, they're not part of the team, they become more one-off behaviors. Is that one of the things that you're seeing?

I think there's an element of that. So there's a few reasons we get these external specialists in, and one is that skill set. Uh, undeniably, if you are sat in a security assurance job, whether it's a code reviewer auditor or a penetration tester, or even in many cases now security architects sitting outside the organization, um, they're sat in teams that that's what they do every single day. And so their skill set is being honed all all the time. And it's expensive to keep that kind of person inside your organization, especially if you're not a huge organization. And there's other bits to it though, internally in your culture. So it can be quite hard to feed and water a full-time security person that is doing these things all the time, because every time they do what they do, they find things. It's 'cause that's what they do. They're good at that. It's their job. And the more the more work comes from security. And so we have this kind of catch-22 because for most leadership teams, security doesn't get seen as a profit-making area, or it's seen as, you know, well, it's part of quality, but it's also part of compliance and risk. And so what they don't want is this continual stream of work that's not going to make more money in the end, which sounds very cynical. It's not intended to be. It's just kind of where we're at now. If you can just do it as a controlled event every so often, you're controlling that flow of work hitting the teams. And it's a naive way of limiting the budget and time that you're having to take on security. The other thing that is sadly true, because we have such a skills crisis now, when we're seeing people train up and go into an organization as a dedicated security person, particularly in the application space, Unless your team is really mature and they're able to go from, "I'm here now, I found some things," to making change in that first 6 months, it's highly likely that they're not going to feel effective. And there are dozens of other jobs out there, so we see very high turnover of these roles. So, we have to be very mindful when we bring the skills into our team that we don't just give them the skills, but we also give them that accountability, autonomy, and authority to make the changes that they need. Because if they don't have those three, then they're going to feel pretty, you know, redundant. They're not going to feel like they actually can get their job done. And so, they'll go and do something else.

So, I see that same problem with testing. So, if we think about teams that are based on iterations, right, based on 2 or 3-week batches that are following more of a Scrum pattern, so it's more across across set of skills within that team, and ideally, they're responsible for end-to-end process and that kind of thing. If they haven't done it before, they tend to think about a tester, right, not testing skills. And if the primary makeup of the team is developers who don't have strong testing skills, we will often see a strong testing capability come in. And the goal then is that that person helps with the literacy of the team, they help with the frameworks, the ways of working, understanding what should be tested when, and then focusing more on the edge cases, right? Because those are the hard ones to find. And so the idea there is testing becomes what the team does, but they've got help in understanding that. I don't see that happening with security, right? We don't see that security person come in early and be part of the team. And maybe that's because we're still treating it as something that happens after the fact. So they, like you're saying, they come in, there's nothing for them to test it secure, but they're not involved in the design process, right? They're not saying, well, actually, if we 'If we design it this way, we're going to have less risk, therefore, let's do it. You know, there's less security holes.' And is that what you're seeing? Is that, again, we're still treating it as another team, a thing that we, compliance, we do at the end to get to go live?

Yeah, there's definitely a bit of that. And there's a weird bit of psychology about it as well. Now, security is one of those areas where if it was your job to find security bugs and you don't find them and then a bad thing anything happens. That makes you feel very, very vulnerable as a security person. Now, anyone who's been in testing will know it's impossible to find all of the bugs. So, it's an unwinnable situation. So, in a way, we feel a little bit more comfortable in our teams if we think a bit more like Batman. So, if you like go back to the old comic books of, you know, there's a superhero, they're somewhat aloof over to the side, you just call them when you need them, They take care of the bad thing for you, and then they go away, and you don't have to deal with that again. Nobody else in Gotham is really learning to be a superhero. They just call when they need. Now, that makes us feel safe because we don't have to care about that. It's not our fault if the security thing fails. It's Batman's. It's that person on the team. Now, that doesn't help the team long-term, though, because it doesn't scale. And as that person realizes that there's too many of these things, they can't possibly save the day over and over and over and over again, then they're less likely to stick around and, and stay. And then they're not cross-pollinating into the teams, they're not coaching and doing this up. Now, some of the solutions we see to this are things like Security Champions programs, where we're— instead of hiring just somebody who is technically very good at application security, we're hiring people who are also for want of a better phrase, good humans. They're there as coaches and as mentors and as in-team evangelists. So, their job is not to say, "Hey, I'll take that off you." It's to say, "Hey, I see you need to do that. Let me help you with that." And it becomes a coaching pairing activity where you're kind of giving knowledge as you help others. But that skillset is even rarer than our technical folk because, you know, I love my community, but many of us come from backgrounds that are not focused heavily on communication skills and coaching and mentoring. So, it's really hard to find the right person for that who can do the technical side but also can connect, reinforce, and coach so the team are empowered to do it themselves.

Yeah, I have a framework that I kind of think about in terms of skills, in terms of people start off with novices and then they become practitioners and then experts. And then some people want to move on to coaching. And for me, to go from an expert to a coach is a completely different set of skills. You need to be an expert ideally, but now you actually need to be able to mentor, train, facilitate, and help people do it the way you did it. And that is hard. And so we see the role of an agile coach, right, being kind of familiar now, but I hardly ever see a QA coach or a security coach. So yeah, I resonate with that. The idea that actually we need people to become coaches coaches in that area that help other people do it the way they did. And maybe that's actually a really good technique if you're an organization that's large enough and you're worried about your security person not being busy enough. Well, if they move into a coaching role, you know, there's always enough teams to help, there's always enough work to be done when you are helping other people get better at what they do versus doing the work yourself. So yeah, maybe that idea of a security coach is something that should start coming out in our market and our domain.

Yeah, and I think if I was honest, we want to get those people coming from application development itself and cross-skilling into security. It's quite hard if your security background is in risk and compliance, or you start out in networking or in physical infrastructure, because the application development world, you know, for want of a better phrase, moves really quick. And I don't just mean in the agile sense, I mean in terms of the technologies being used, The architectural frameworks, the way we build software is changing rapidly. It looks nothing today like it did 10 years ago, and it will continue to evolve. So, when you're saying you need to be a coach, you don't just need to know the security stuff, but you also need to be able to adapt that to, say, 10 different languages or the 3 different types of frameworks that your team is working on. Oh, and PS, there's a legacy system over there that we still have to keep on because it represents 30% of our revenue. And so you need somebody who is confident navigating the application space before you worry about the security space, because if they don't have that foundation there, whatever they give will not be able to connect and resonate with the underlying technology.

Yeah, and I'd extend that out in terms of the domain you specialize in. So if you specialize in, uh, you come from an application development background, then you applying your security practices and principles and patterns in the data world is actually quite hard because we go, well, we don't control the app. Typically, it's off the shelf. We've got a Qlik, Tableau, Power BI, whatever, right? That's a commercial product. Yes, we're going to do some testing of it, but not a lot because it's outside our sphere of control. But the way the data is surfaced in those dashboards, what we show to who, that's what we care about. And that's a paradigm shift if you haven't worked in the data domain. So again, it's the idea of does a coach need to have been been on the field, to be good at helping other people. And I think in the security space and in the data space, it helps. If you've been a player, then you are a more effective coach.

Absolutely. The area of security and data science, I think, is even less mature than application security. And the number of people now in really exciting data science or kind of those machine learning where it's not software development like we know it. It is really algorithmic, and it, it's based on the quality of the data going in and how much you can trust it and the bias that's in it and how that data has been prepared and put into its systems to begin with, as well as then how we choose to tell a story with it at the end. All of that impacts its security in terms of the confidentiality. Are we exposing too much or too little? The integrity of it, does it actually mean what we're saying it means anymore? Can we trust it? And the availability of making sure that we've got these big areas of data that are available when they need to, because sometimes we go too far with our security and say, nope, no, no, too insecure, lock the doors. When actually that's getting in the way of getting the job done. And anytime security fights getting the job done, getting the job done is going going to win. So, we have to make that data science and security area something that's much more front of mind now.

Yeah, I think one of the things the security teams have in their favor is they are seen as a risk and compliance team often, and therefore they are the people with the pen to say go/no-go. It's our testing and our documentation brethren who typically get the, you know, their 4 weeks of work shortened down to 1 day when we're running a more waterfall-based process.

So, at least security people are seen as more We'd like to hope so, but sometimes it doesn't feel like that.

Well, yeah, we don't want the bad news, right? We just want the green tick that we did everything right.

Yeah. Absolutely. Dreams are free.

But if we think about that idea of algorithms, machine learning, and the— I'm using my fingers here— AI, again, I see a lot of the times when we look at security, we look at rule-based paradigms, right? So we're saying, we're going to go test this. Can this person access this piece of system? Can we get into a system? To a place that we don't expect to. We set a bunch of rules. And then, yeah, potentially if we're automating some testing, we may run those rules, you know, a little bit later and as we make changes. But I don't see a lot of observability. I don't see, you know, the example I use is, yes, we need to test that people can't access the system if we don't want them to, but we should actually set up some automation that observes what's happening and then alerts us when things look a bit weird. You know, the idea of saying, well, why don't we log all the logins? And then why don't run a simple K-means algorithm across it to say, here's a cluster of logins that just looks strange, right? We know that Google does it, right? We know Microsoft does it. We know that when we log in, you know, take my laptop and I go into another caf, it asks me a little bit of a different security question because it knows I'm not in a place that I normally are. So, so that rigor, that, you know, their ability to apply those techniques at scale, some of the big companies have. But when I work with companies that are less data-driven or less digital nomads, those type of techniques and patterns don't seem to be top of mind. So, why is that?

I think in a way, it's a scale problem. Unless there is an off-the-shelf solution that you can find that helps you with it, gathering the data isn't hard. That's probably like the most oversimplification I will say today. But gathering the data at its root is not the complex part of that puzzle. You can gather data together from all sorts of locations, pop them into one nice pot, great. It's then using the appropriate technology and thought process to really know, well, how do I know what this data is telling me? And not just what the data has historically told me, But what are, you know, in the metrics world, we'd call the leading indicators. What are the clues we have that a bad thing is about to happen? Now, security monitoring tools historically, to again, simplify something, are generally a regex over a large set of data. You know, our old Snort and all of our old security alerting and intrusion detection systems were just regex. They were big complex rules looking for common patterns in packet capture. Now, to do, you know, analysis based on, let's call it heuristics instead, so patterns of behavior, the fingerprint of a person, that's much more than just a regex. That's the correlation of dozens of sets of data at once. It's understanding how to rank that data in terms of priority, how much you can trust each piece of data. And each part of that then has to come together in quite a complex scoring system. Now, this is an area that I'm really excited is emerging in security because what my thesis— my studies were in artificial intelligence back before it was cool and I think you could get a job in. I wrote natural language systems. And the interesting thing about it, and it was interesting then, it remains the same now, is to get to the quality of analysis and interaction you need in these monitoring systems, the technology you're building is not as finitely predictable as standard software. So, you know, there are so many different logic pathways through it that interact with each other that it becomes very, very difficult to track whether you've got a complete picture or whether you are really taking into account all of the different combinations. So, I think, to be honest, it's a hard problem that only— the only people we're seeing solve really very well right right now are the people who have so much data to begin with and have made their business models about already aggregating it together. So they're applying something they already had. For most of us, we couldn't achieve that.

Yeah, and so we've seen, you know, the advent of the cloud, you know, so the AWS, Azures, and Google Cloud worlds. And that's changed the way we have to think about security as well. So, you know, example I have is I'll often work with teams that are new to the cloud still, and they'll still think about firewalls. They'll still think about security as controlling the network pipe. And when they then realize that actually with those cloud providers, everything is an API, you know, you can come in and get access to everything through an API without going through, you know, a closed network. And therefore, we have to think about things slightly different. That's quite a shock to them because the techniques, the patterns that they use from an on-premise, which the challenges the cloud providers make it look like you can still apply those techniques, right? You can set up VPCs, you know, you can install, you know, third-party firewall software and it gives you that sense that those patterns are working. But the world has changed and same with penetration testing, you know, the number of times I have to have a conversation about, so before we go and do any form of penetration testing with one of those cloud providers, we need to talk to them first. Because if we try and do penetration testing, their quite good penetration testing software will shut us down because that's what it's designed to do. So, have you found that? Have you found that this move from on-premise practices to cloud has required a reeducation of security people and what's important?

I think it's a reeducation for all of us. The way we learn and the way we've always learned is by taking metaphors and paradigms we are what we're familiar with and applying them to a new context. So, you know, we learned about email because we'd done letters. Now there's a generation that doesn't know really about a physical letter, and they'll apply email to whatever comes next. In the cloud space, we're applying what we learned over, in some cases, you know, 15 years of career in building on-premise solutions, and the only thing we have in our metaphors that we could apply to it are those things. So we take them with us and we look for that familiarity. Now, marketers know this. So when they're putting together the, "Here's why you should join the cloud," they go, "Well, it looks just like the thing you've done before, so it's familiar and it's easy." And, you know, it's— I'm a security person, so for me, it feels a bit like social engineering. But I love marketing people. Please, marketing people, don't hate me for that comment. But that's hard when you learn by metaphor, and those metaphors aren't really appropriate, but they're all you have. So, that education layer isn't just about saying, "Hey, click button number 3 and button number 2 and turn on this thing." That's that implementation layer of education. We also need to actually teach, before we get to that, the fundamental concepts. So, what are the paradigms? What is our new metaphor here? What is it that we're talking to? And I think we spend a lot of time abstracting away from that now and getting straight into implementation without teaching, "Well, actually, that button is on the back of a giant space console and this is what it looks like." And by doing this, it opens this floodgate over here. When I teach, one of the most fundamental things that we do with our apprentices and with our learners is making sure that we understand for whatever button we've pressed, what's physically happening, what is happening underneath, what is what is it causing? Because without that, you're kind of— there's no way to concretely secure it because you're, you're— it's like trying to lock a door when you don't know what shape the door is, where the keyhole is, or what kind of mechanism it has. You've got no hope.

And so one of the problems I see is this idea of a shared language that, uh, you know, in IT we all have our own little three-letter acronyms. You know, you go talk to somebody that's outside of IT, and they ask you to fix their PC and you're going, well, I work in IT, but I don't fix PCs. So, to them, the words we use are alien. And then when we look at data versus app dev versus security, same thing, right? You know, TLS 1.2, right? Well, I kind of think I know what that is, but even within the security world, there's their own language. So, where are we in getting that shared language so that people that are experts or coaches in security can use words and paradigms that we can understand what they're talking about. And we go, "Ah, now I know what you're looking for." And then, yeah, we can have that shared language. Is that starting to happen?

Oh, maybe, maybe in places, but probably not. I mean, security, we are terrible for having many acronyms that mean the same thing or many different acronyms for the same words. And I think, I mean, authentication versus authorization is my favorite example. Those who've ever listened to me talk before, it's the one that drives me nuts as we abbreviate them both the same thing and then expect us to understand implicitly which one we're talking about. For me, and I think this is where I differ in my approach to others in my same field, I don't think the technical language we use in application security in particular is helpful. I think actually sometimes we use it, uh, in a way that obfuscates or confuses the, the matter at hand. Security at its most fundamental elements is the same set of rules it has always been, whether it was physically protecting a building or a castle or a cave or a treasure chest. It's the same kind of things. We have preventative controls, we have things that stop stop bad things from happening. We have detective controls, things that spot the bad thing is happening, and responsive controls, things that allow you to do something when a bad thing has happened. And there's no shame in us, instead of going, "Well, you know, the preventative controls in this audit have showed blah, blah, blah," saying, "Well, how are we prepared to stop bad things happening?" I'm a big fan of bringing the language to its plainest form and increasing our engagement that way because there's so much jargon and it's a nightmare to wade through, even if you spend all day wading through it. So I think the time has come for us to actually call it out when we see it and go, can we just speak plainly about this, please?

And the other thing that I see is when I'm working with people is like this kind of idea of unconscious behavior versus conscious behavior. And the way I articulate it is, you know, as we increase our level of expertise, we get good at unconsciously identifying the things we know we need to care about. But when we move to more of that coaching-type role, we have to become more conscious about why do we look for those things. So, as we're working on a new, say, deployment of a data platform and we have a security team that's outside the team, we'll tend to say to them, okay, what are you going to look for? If you can explain to me what you're going to look for to make sure we're doing the right things, then that will help us to design upfront to make sure we're doing those things. And ideally, we can automate create some of the proof, right? We can actually go, well, here's the things we're running and here's the green ticks to say that, you know, those things are in place. But a lot of people struggle with that, right? Because what they want is a design document or they want to be able to explore the system because they know unconsciously they'll find what they care about, right? But if they had to describe it, they struggle. And again, is that just the maturity of the security market at the moment? That there's never really been a focus on embedding those skills in a team, so therefore, having to explain them is not as important as being able to execute them?

I think potentially. I think when it comes to that level of assurance that we're talking about here, where, you know, people feel more comfortable digging into a document that we'll give them, I think part of that, again, is that sense of vulnerability you get in that security space. It's really hard in security to sit in a room with nothing documented and try and navigate and go, "Right, I need to find all of the bad things and I have no map." So, while documentation is undeniably almost always out of date and irrelevant and doesn't really represent the end product, that's okay, we get that, there's no judgment there, it just is what it is. It at least is a starting starting point. Now, that said, I don't think it's the best starting point. I've seen some incredible threat assessments with no paperwork in the room at all, but what they've had is they've pulled in people from, you know, end users of the system. Say, say we're talking about bank, pull in, you know, you've got some customers, you've got some people who are bank tellers, you've got people who work in the call center, you've got people who are developers, and you know, the technical roles are there too. And then somewhere in there you insert a chaos monkey. By a chaos monkey, I mean someone like somebody who's in the arts, somebody who's an improv person, somebody who writes scripts or fantasy novels. Now, throwing a chaos monkey in gives you this voice in the room that is just there to go, "Ah, yeah, but what if I press that button?" Or, "Hey, oh, wouldn't it be cool?" And that natural skillset, that energy that comes from from somebody who is completely divorced from both technology and the original product, but they're also a creative and artistic type. So, they've got that ability to go, "Yeah, but let's ignore physics for a second, and let's pretend that laws don't exist. What if?" That is incredibly freeing, and I actually think we need more of it. We need more conversations where we can sit in a room and ignore the fact we've all been taught to follow the rules and to be law-abiding citizens. Citizens and not get in trouble, and just for a second go, "Wouldn't it be cool if I went through Farmer's Department Store and put my arm across the top of all of the tabletops? How long do you think it would take them to catch me if I destroyed all of their glassware in 5 minutes?" You know, would we do it? No, we're not evil people. But we need to talk about the chaos. We need to talk about the people and the thought process of what if there were no rules, because That's where the vulnerabilities come from, from people looking outside of the frameworks we naturally sit inside.

Yeah, didn't think about it that way because the people that want to get in aren't going to follow the rules. In fact, they're going to look for the exceptions outside the rules, right? They're going to do weird shit because that's how they find the little gap you forgot about and that you didn't find. Yeah.

Exactly. It's the funny thing about crime, right? We spend a lot of time in security building rule sets and patterns patterns of behavior. The literal point of somebody who is criminally minded is to work around any rule set that exists and find a way around it. So, our natural tendency to follow and create rules is one of the reasons we're not that effective all the time at stopping bad things from happening. It's a catch-22, really.

So, for me, I spend a lot of my time working with data teams around patterns. And the idea goes that There's lots of things we do in the data world that we do every time. We typically will do it, right? So we will typically collect some data, we'll typically combine some data, we'll typically consume some data. There are a bunch of patterns for the way we store it, the way we model it. There's lots of horrible words like SCD2s and things that we use to confuse ourselves. But there are a bunch of patterns and you can say, 9 times out of 10, we're going to use a pattern that looks like this, right? And so if we could document those, if we can put them in our toolkit, we save time, right? We save effort, we save argument, really. And that's good. But we're not particularly good at it, right? We're nowhere near as good as the app dev domain yet. What's that like in the security world, right? So I'm doing a startup at the moment, and we're bootstrapping, so we're really conscious on cost. So for me, it's like, I just want the basic security patterns. So an example, multifactor authentication, right? For me, basic security pattern. Anybody that's working on our product has to have MFA turned on, right? So it's just a no-brainer. It's what I know about. But then I'm going, well, there's probably 10 or 20 other patterns that a security expert or coach knows about. Why can't I find those in an easy and consumable way so I can just adopt, and I don't wanna use the word, but I'm gonna use the word, minimum viable security, right? Just like, give me the 10 dumb things that I should do, you know, on day 1, and then, you know, work with me to find the other hard ones. So, does it exist?

Well, have I got news for you, it does. So, let me walk you through it because actually, it's existed for a while. One of the things we're not great at in the security community is sharing the amazing resources people have built in a way that people actually ever find them. So here's a few things you can go track down, and I'm going to split them into 3 groups. There's securing your company, securing your secure development lifecycle, and then securing the product you're building. So starting with securing your company, there is an amazing open-source checklist. It's available on GitHub. If you Google, literally Google, SEO Security Checklist or Startup Security Checklist, you will find this list. And it's based by the stage of your company and how much funding you've had. And it's the basic controls you need to have in your organization. That's everything from having a basic policy to, you know, turning on MFA. And it goes from the real basics onwards. And it's a great way to going, "Have I done this or not?" No auditor required. Next is your SDLC. Now, OWASP, the Open Web Application Security Project, Security Project has two projects that are going to be really, really useful to you and your audience who have similar challenges. So the first is the OWASP SAM. So that's the Software Assurance Maturity Model. Apologies, my brain just went, ah. So it's a way of us modeling and measuring the maturity of our software development process. So it splits our software development process into chunks and for each bit it says, Okay, what does a mature process look like versus an immature process? What would we expect to be happening? Now, the nice thing is they give you away the spreadsheets and things, so you can go and do a little assessment of what you're doing right now. Doesn't cost you anything to do, and then there's a guide as to how to get further and more mature. So that's your SDLC, and then on your product itself, also in the OWASP space, we have the ASVS, which stands for the Application Security Verification Application Standard. But don't worry if you call it ASVS, nobody will care. Now, what that is, is firstly, you get to prioritize your application in terms of its importance or sensitivity. So there's 3 tiers of application from the least sensitive to the most sensitive. And then there's a set of about 16, give or take, what they call domains or areas. And those are things like authentication, Authentication, data connections, networking, all of the areas and patterns or architectural areas of your application are there. And for each one, it defines what the minimum expected implementation should look like for each level. So if you're a Level 1, say for example, the least sensitive application, it might say, well, you need to have decent authentication, so a good username and password. But it might not go so far as saying multi-factor authentication. But by the time you get to Level 3, it's saying, actually, you need multi-factor authentication and you need this level of control in place around your authentication systems. It's going from a couple of things for less sensitive to a much more comprehensive list for more sensitive apps. Now, the thing I like about that is you can start where you are. If your application is just, you know, a Hello World type app that you're building for fun, start with the basic controls for a least sensitive app. If you then start building a bank system, you're going to move down that sensitivity and you can start building up your security as you go. Now, the final thing that OWASP has, it doesn't have a great project name, so I will get back after this recording and I'll give you the actual name for you to give a pointer to it. They have a set of architectural design patterns that are now open source in their repos too. So these are documented design patterns and diagrams for common application architecture processes. Now, the one thing I would say on that is, just like there are a lot of languages out there, there are a lot of design patterns, especially when it comes to the nuance of security in each one. So that's still one of the more fledgling spaces for OWASP, but definitely want to watch and be involved with if you want, because The security world doesn't belong to security people. It's actually, we're there to support. It's the development folks that really need to be there and being vocal because it's your software that we're trying to protect.

So, again, yeah, interesting the number of 3-letter acronyms.

I told you, our whole industry, it's acronyms all the way down.

So, in terms of that content, did that get created by security people that wanted to share, or was it created by application development people who then understood understood security and wanted to share. Where's the genesis of that documentation, that capability come from?

Sure. OWASP, I think, originally started with members of the security community who were more in the assurance space. So, most of the original players were penetration testers and security auditors. The idea was they were seeing common patterns. So, when you look at things like the OWASP Top 10, which is one of the things you'll hear talked about a lot. So our top 10 common vulnerabilities in web applications, that was basically them crowdsourcing anonymized findings from penetration testing companies and going, well, what's commonly coming up time and time again? I think as time has passed and, you know, OWASP has celebrated a big birthday recently, you know, we're measured in decades now, you really are starting to get to the point where it's a more mixed community. Community. Now, that's good and bad. There's still a lot of security people in there, and you will hear more security talk about, oh, things at security conferences than you will at development conferences. And that's a problem because we actually need to reverse that. It needs to be more in the development space. Um, and we've also got vendors starting to be as part of that community, so that comes with its own challenges. But there is an increasing number of application security engineers application development specialists who are, you know, hybrids that are emerging and becoming vocal champions. So it's an exciting time, and I think it will get better and better as we become more aware of it as a development space.

Yeah, I mean, it'd be great if actually we could put a data lens on and actually build out that patterns and toolkits to include more around data security or security when working with data platforms over those app dev platforms. So you mentioned a couple of times about the software market. So again, what What we find is that in terms of application development, you know, the market, I believe, is well served for software, right? For the whole lifecycle, for the whole way of working, there is typically a good choice of tools or software you can use to make your life a little bit easier. In the data world, not so much, you know, like if I think again about testing of data, you know, it's dire, it's finally getting better, there's some new stuff coming out, but you know, it wouldn't be uncommon to kind of articulate it as, well, we put the data in front of the user, and if they don't notice it's wrong, then it's not. And we're getting better at that, right? So we are bringing in some of those practices and patterns that we should do as professionals. But is that the same for software? I mean, in terms of security, is it that the software market is kind of behind the changes in the way we work now and trying to catch up?

There's pockets of very good and pockets that are really still behind. A lot of the early application security tools in particular, they were written by security people who— it's kind of when you write a tool from outside the community, it's kind of like saying, "Hey, I see your baby is ugly. Here's my solution to your ugly baby." And that never clicks well with the community because you're kind of coming in, you don't really know anyone in the room. And you're saying, "You screwed up and I know better than you." And that's not a great way to start a relationship, really. There are, however, a new wave of things coming through that are much closer to the development space and are doing a lot more product-focused development. So, if you look at what's happening, for example, with Snyk, so they do checks to see if you're using vulnerable third-party code in your stack, or you look at the stuff that GitHub is doing with its security monitoring. So it's doing checks for secrets embedded in code bases. These excite me because they are very close, if not already embedded in the development tools. And they're being written by people who've come from application development and are applying security on top rather than kind of shoehorning it in. There will always be, I think for a long time yet, there's the old guard, you know, the, the big the big brand names we expect to be there, and they sell because, you know, people know the company name. And sometimes the buyers aren't developers themselves. Perhaps it's a security team trying to help the development team, and that help is well-intentioned but not really aware of the challenges that the team's facing. So I think hopefully these smaller players that are more AppSec-focused and coming from dev are going to get louder and not just get acquired by big players. Um, and these bigger ones over time will start to fade away in terms of relevance. But only time will tell on that, and it's all going to depend on a few things that are happening in the world with mergers and acquisitions, and also things like in the US, the software bill of materials. There's a lot of big global change in this space that's going to make big difference in the next 12 months.

Yeah, we're seeing that in the data space as well. So these, uh, I'm kind of ranting at the moment in the Twittersphere around vendor washing of the term called data mesh. So, you know, a new paradigm's come out. It is a little bit of a restatement of things we've been trying to do for years, but it's articulated in a different way and it's got a lot of momentum behind it. Yet, first thing that happens is all the vendors take their old lamps, call them new, and say, you know, here's our old legacy software that's now data mesh enabled. And it's frustrating because people who aren't in the domain don't know that actually it's no different to what they were sold last year. So yeah, it takes a while. And same thing, we're getting consolidation, right? We're seeing a lot of startups in the observability space, you know, so the idea of Datadog for data, because, you know, we didn't tend to monitor what was happening to our data, let alone test it. So we see a lot of those come up and have value and then get swallowed up by the big companies and that innovation or that focus on that category gets lost. So it sounds like the security world's in the same place.

Absolutely. I think if I was going to take your data mesh as our zero trust, and in the app dev space, microservices, everything's microservice-enabled now. But I think even Sam Newman would agree that stop doing it, it's a terrible idea. We need our words back and they need to mean something.

Yes, and you know, which version of auth did you mean? Was it authorization or authentication? Because they are slightly different. Even I know that.

Don't even get me started on OAuth and what we're doing with the definitions of that these days, because that's a feral mess, but that's a rant for another day.

Yes, it's one that actually we're struggling with at the moment is how do we actually use multiple authentication systems to allow our customers to come in the way they want. And, you know, the amount of technical learning you have to get to understand those many moving parts and what they do and don't do and the new terms they're introducing is is a big challenge for people that don't typically work in that space.

So.

I found that really interesting. So what I didn't realize is actually there is a bunch of patterns that have been published that actually are readily available for anybody who wants to start their journey. And I really like that idea of maturity model that you can start off small, adopt the things that just make sense when you're in that space and then grow. So the other thing is that idea of that security coach. So, Having a look at what you're doing, that's kind of where you're going, isn't it, in terms of what you do is that security coaching, that idea of increasing the literacy of people that aren't in the security domain to do good things. So, if people wanted to talk to you about that more, where would they connect with you?

Yeah, absolutely. And just to kind of give them the hint of if it's the right thing for you, we want you to be able to, whether your team is 2 people and a big dream, or 3,000 people, but you've only got 3 security people in the mix for some reason, there is a foundation of skills you can build for every stage of that lifecycle. And when you build that foundation, you make everyone stronger and more secure. Now, you can come along and find us at academy.safe-stack.io. You can find us on Twitter @safe-stack. You can find me @lady_nerd. And just come and chat with us. What I would say is, We are on a mission to try and bring security through as many development teams around the world as we can. And that means that we're not there to aggressively sell to you, we're there to listen to how your world works. And if nothing else, I would love to hear how application security works in your team, because every day is a school day in AppSec, even for people like me. So I'd love to hear your stories, so please do reach out.

Yeah, and let's hope that the security domain carries on improving and growing. I mean, I'd hate great to see it go, the land of COBOL, where, you know, very few people do it, and there's still systems running on it.

But they are paid very, very well for those jobs now. So, you know, it's the devil in the deep blue sea.

Yeah, I do believe it's a great retirement scheme, is to go back into COBOL world in your later years.

I tell you that I think my whole plan in life and building SAFE Stack Academy is to make people like me redundant. Redundant. I want to get to a point where we don't need application security specialists because it's part of what we do as developers, as testers, as architects, just like we do scalability and observability and testability. Let's make securability an -ility and part of everyone's role. So yeah, help me become redundant really and start doing this.

Yep, I agree. And adopting those patterns and approaches and helping upskill people to do the work themselves when they can do it safely and do it well. That's what we should all be striving for. So, you know, that kind of makes my heart sing. So, look, hey, thank you for your time. That's been great. I've learned lots more about security than I did from the beginning. And also, yeah, it's kind of interesting for me how the security domain is following closely with the data domain where we're still what I see as second-class citizens in the way we work compared to, you know, some people in the application space who really are forging ahead of where we're at. And, you know, as professionals, we should pedal faster and catch up because it's just the right thing to do.

I think, you know, to be a bit fairer to our communities, sometimes we're seen as unsexy problems. You know, it can be really tempting to say, well, I'm building a self-driving car, what are you doing? Well, I'm, you know, doing the quality of data, or I'm securing a system. But without these systems, without data, without security, the self-driving car, you know, kills people. The rocket crashes and burns and the financial transaction systems don't work or they lose money and we, you know, give away our chimp pictures to people on the internet. So, I think we need to remember that's an important part, albeit like the unsung hero supporting character rather than the main event.

I think we're lucky in the data and analytics world that we're the hot hyper curve at the moment. You know, it's scarcity of resource and all the vendors piling in. Data is definitely the cool place to be at the moment, so hopefully security follows straight behind us and gets the limelight.

That's what we're trying to do. It's been lovely to talk though, Shay.

All right, no, thank you for your time and we'll catch you all later. And that, data magicians, was another Agile Data Podcast. If you'd like to learn more on applying an agile way of working to your data and analytics, head over to agiledata.io.