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 some. Some large pieces of work that tend to happen up front. So things such as the architecture, the platforms, and security. And so we always struggle with how do we 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 an inordinate amount of time up front 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 yourself for the audience?

Awesome. Well, it's lovely to be here today. 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 that 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. And my second book is due out soon, Security for Everyone. So this is something, as an area that's really exciting to me, and 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 life cycle. So I think what I'm saying is we're trying to put our money where our mouth is and really kind of try and get this at a global scale, so not just one or two unicorn projects. It's 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 seeing? 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 five years now, but really it's being misused and misunderstood a little bit. 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. Shift left, 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. We see that the first cut of the platform will tend to penetrate to some form of testing or CNA or whatever process we want to call it. And then we land the data because we want to make sure the environment's safe before that data is available, and then we never touch it again. 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.

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 very iterative combined testing all the way through. But for the most part, I'd say probably 90% of companies still are stuck in that same loop where they're tying their security checks, their assurance, their activities to very big milestones. You might be happily deploying your code every 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 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. We're still, in a way, waiting till the very, very end. Even though we know when we're moving at development speed fast, 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 there are frameworks out there they're not as well known. 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 storage, 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 10 years ago where testing was okay to run for six hours and that wasn't a problem. 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 and my testing pipeline doesn't explode? 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 by putting security in, you bloat your timelines by a number of hours or a number of 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 preference. So it sounds like the security space is the same thing. Where is part of the problem that when I, 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 siv. Right. 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 at 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. 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.

They'Re sat in teams that that's what they do every single day. And so their skill set is being honed all the time. And it's expensive to keep that kind of person inside your organization, especially if you're not a huge organization. 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 because that's what they do. They're good at that, it's their job. And the more they find, 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 six 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, that they need. Because if they don't have those three, then they're going to feel pretty 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, based on two or three week batches, that are following more of a scrum pattern, so it's more across cross set of skills within that team and ideally they're responsible for end to end process and that kind of thing. Yeah. 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 tested 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. 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 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 design, 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 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 there's a superhero, they're somewhat aloof over to the side, you just call them when you need them. 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 stay. And then they're not cross pollinating into the teams. They're not coaching and doing these 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 skill set is even rarer than our technical folk because 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, 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, 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 three different types of frameworks that your team is working on. PS is a legacy system over there that we still have to keep on because it reps 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, 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, 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's 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. Again, it's the idea of does a coach need to have 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 those machine learning roles where it's not software development like we know it, it is really algorithmic and 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 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 to 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 their four weeks of work shortened down to one day when we're running a more waterfall based process. So at least security people are seen as more important.

Important. I'd like to hope so, but you know, sometimes it doesn't feel like that.

Well, yeah, we don't want the bad news. Right. We just want the green tick because 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? You know, can we get into a place that we don't expect to, we set a bunch of rules and then potentially if we're automating some testing, we may run those rules a little bit later and as we make changes. But I don't see a lot of observability. I don't see. 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. The idea of say well why don't we log all the logins and then why don't we run a simple K means algorithm across it to say here's a cluster of logins. It just looks strange, right? We know that Google does it, right? We know Microsoft does it. We know that when we log in I 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 that rigor, their ability to apply those techniques at scale some of the big companies have. But when I work with, you know, companies that are less data driven or less digital nomads, those type of techniques don't. And patents 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. So that that's probably like the most oversimplification I would 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's historically told me, but what are 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. 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 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 scale 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. Well 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 the advent of the cloud, so the aws, Azures and Google cloud worlds and that's changed the way we have to think about security as well. So 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 is 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, they're 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 helped require a re education of security people? And what's important, I think it's a.

Re education for all of us. The way we learn and the way we've always learned is by taking metaphors and paradigms we are 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 three and button number two 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 it causing? Because without that you're kind of, there's no way to concretely secure it. Because 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 in it we all have our own little three layer 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? TLS 1.2, 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 authentication versus authorization is my favorite example. Those who have 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 helping helpful. I think actually sometimes we use it in a way that obfuscates or confuses 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 back 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 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 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 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 it just the maturity of the security market at the moment? They're. 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 right here, where people feel more comfortable digging to a document that will give them it. 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 point 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 case monkey. By 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 skill set, that energy that comes 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 situations, 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 five 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, that's where the vulnerabilities come from, from people looking outside of the frameworks we naturally sit inside.

Yeah, didn't thought 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 that you didn't find.

Exactly. It's the funny thing about crime, right? We spend a lot of time in security building rule sets and paths, 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, you know, nine times out of ten we're going to use the, you know, 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 if we say 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 you know, we're bootstrapping so we're really conscious on cost. And so for me it's like I just want the basic security patterns. So an example, multi factor authentication, right? For me, basic security pattern. Anybody that's working on our product has to have MFA turned on. 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. So why can't I find those in an easy and consumable way? So I can just adopt and I don't use the word, but I'm going to use the word minimum viable security. Just like give me the 10 dumb things that I should do on day one and then work with me to find the other hard ones. Does it exist?

Well, have I got news for you, it does. Let me walk you through it because actually it's existed for a while. But 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 into three 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 CT 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 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 this.

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's 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 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 three 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, 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 one, 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 three, it's saying, actually you need multifactor authentication and you need this level of control in place around your authentication systems. It's going from a couple of things 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 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. 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 folk that really need to be there and being vocal because it's your software that we're trying to protect.

Again, interesting the number of three letter acronyms.

I told you, our whole industry, it's acronyms all the way down 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 security and wanted to share? Where's the genesis of that documentation that capability come from?

Owasp I think originally started with members of the security community who were more in the assurance space. Most of the original players were penetration testers and security auditors. And 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 now. That's good and bad. There's still a lot of security people in there. And you will hear more security talk about 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. 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 or applications application development specialists who are 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 we find is that in terms of application development, you know, the market I believe is well serve for software, right. For the whole life cycle, 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 off 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 for 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 are very good in pockets that are really still behind a lot of the early applications. 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, the biggest 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 getting to get louder and not just get acquired by big players. 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 I'm kind of ranting at the moment in the Twitter sphere around vendor washing of a term called data mesh. So 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, 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. So the idea of data dog for data, because we didn't tend to monitor what was happening to our data little. I 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. 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 AppSec space, the App dev space, sorry, microservices, Everything's microservice enabled now. But I think even Sam Neumann would agree that. Stop doing it. It's a terrible idea. We need our words back and they need to mean something.

Yes. And 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 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. 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 two people and a big dream or 3,000 people people, but you've only got three 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 SafeStack IO, you can find us on Twitter afestack, you can find me adyournerd 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 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 and the deep blue.

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

I tell you that I think my whole plan in life and building SafeStack Academy is to make people like me 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.

Yeah, 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 that kind of makes sense. 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 some people in the application space who really are forging ahead of where we're at. And as professionals we should to 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 give away our chimp pictures to people on the Internet. So I think we need to remember that's 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. 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, and gets the limelight.

That's, 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 working to your data and analytics, head over to agiledata IO.