 Hi. Good afternoon. I guess, given it's 3.40 on the last day of a five day conference, I should award you all some sort of achievement for turning up and not looking like you're kind of glaring into my soul wondering where the beer is, so thank you. My name is Laura Bell. I'm the founder and lead consultant at SafeStack, which is a specialist application security firm. And I'm here today to talk about security in an agile context. Now, before you all get alarmed, I'm not going to be talking scram at you. When I say agile, I mean any sort of fast paced, normally highly innovative, slightly erratic development life cycle. In fact, many development life cycles meet this category, so don't be alarmed by the word agile. It's not all as it seems. Now, before I begin, I will break the rules of presenting and I will apologise. I'm really sorry. We borrowed a word from you guys a little while ago, and we've been really mistreating it. So, yeah, I'm going to use the word hacking liberally and incorrectly for the next 45 minutes. Okay, so get it out of your system now if it bugs you. Really sorry. Yeah, forgive us. Forgiveness is golden, they say, you know. The other thing, going back to Leslie's talk earlier in the conference, I may be a female presenter, but I am just as flawed as everyone else when it comes to using the wrong pronouns at the wrong times. So again, I will do my best on that front, but again, we're all learning. So sorry about all of that, but let's move on and let's tell a story. So once upon a time, in fact, for most of you as recently as this week, there were software development teams. Now, how many of you are involved in creating code, who actually write code? And I don't mean like web application, I mean any sort of code. Okay, how many of you manage the security for that code? All right, okay. How many of you just do security and you're here to see how you manage this for errant developers? All right, hi. You guys are a bit special, but we'll cover you. Don't worry. So once upon a time, we were engineers, and engineers like building things, right? And we like building big, awesome, innovative, feature-filled things. We like doing that regularly. We build all sorts of crazy things. The internet has given us the ability to build things that connect people and countries that are so spread around the world that previously their cultures had never met. And we live in a world full of components and libraries and things where we can actually not become kernel developers anymore. We don't have to. We can just use libraries and frameworks and focus on the objective of our software, not on getting down to the kernel level. Meanwhile in the security industry, we got quite good at spotting car wrecks and monetising car wrecks. And we created an entire system of governance and frameworks and applications and environments and devices you could buy from us for hundreds of thousands of dollars. And we were very happy selling them to you. But it turns out it didn't all go that well. So raise your hand if you can name an incident in security in the last 12 months that affected someone on the planet. Yeah, I don't think we met that KPI. How many of you were personally affected by a security incident in the last 12 months? Yeah, how many of you have attended another security talk this week at LinuxConf? Yeah, how many of you left it feeling like the world was actually an impossibly evil place and there was no hope for mankind? Yep, we are meeting and exceeding that expectation. So what do we need to do, right? Why am I even here? What am I going to talk about? Now they bring me on last normally because I'm not here to tell you your application is an ugly baby. We know this. We've all written that application. I'm not here to tell you that the hackers are coming and you need to check and lock everything twice. You know that. And to be honest, I probably already need a network, so shift has sailed. Okay, I'm here to give you 10 things that you can actually do yourself, not with a specialist, not with a lot of money to actually bring security to whatever project you're working on. I don't care if you work for a giant bank, a giant software firm or you just write some open source software as a hobbyist for fun in your spare time. There is nobody in this room who cannot do security, every single one of you can. And I'm going to show you how. So we're going to come up with a few common misconceptions to start with because I'm bored of hearing them and if I spread the word to you that they're lies, you'll spread it to friends. I'm going to give you 10 steps that you can actually bring to your own workflows no matter what they look like, no matter how many post-it notes you have on pieces of glass in your office. And I'm going to show you some of the challenges and pitfalls. So why can I even talk about this? So I'm actually a reformed software developer. I started out writing COBOL at the tender age of 16 for taxation systems. I'm that cool. I then went to real time C for CERN, radiation monitoring software specifically. And eventually I made it into Java because I've been told that's where all the cool kids end up. Turns out I was quite good at breaking code as well. And eventually the Java people said please don't play with us anymore. Go play with the other naughty children in the basement. And so I became a penetration tester. So these talk and everything covered in it today come from over a decade of making and breaking things. So I hope you can see that I have a few war stories that I've been around the block a few times. And if you have any questions, please do feel free to ask because this is your talk. You're here to learn, not me. So let's talk about the basics of development life cycles, right? We're quite familiar with this. We have an awesome idea. We design it a bit maybe on a piece of paper, maybe just in our brains. We code something if we're really lucky we test it and eventually we deploy it into the unsuspecting real world. Fantastic. Now traditional security likes gates. Now when we talk about gated security basically we insert things between parts of the development life cycle. So we insert risk assessment between ideas and designs. We insert penetration tests. We just make the process longer. Now that worked really well in Waterfall kind of. Never found any bugs obviously. But in Agile, can we do the same things just more frequently? Of course we can't. So some of the processes we've gated in here, so code reviews and penetration tests, they take ten days, three weeks, all on their own. Now if you're working on two-week iterations or in a continuous deployment environment you can't stop for two weeks every time you need to test new code. So we need to rethink the way we do security from being a gated approach to being something slightly different. Now there are some common misconceptions and let's get those out of the way first. Ignoring security and doing it later is not the same as managing security. Now I have to mention it because many people have long lists of things they're going to get to or they know they need to care about. Unfortunately security ends up on the same list for most people with global warming and curing cancer. I want you to prioritise it off that list which are all very valid noble missions and put it into the more practical day-to-day things. Because avoiding it isn't going to save you. People are still going to actively research security vulnerabilities. They are still going to go around the internet looking for things to play with. I use the word play very intentionally because not all hacking, see I told you I was going to use it, is destructive intentionally. A lot of it is very bright people who are very curious and may have some boundary issues. The other thing to note is you're never too little to fail at security. So that's something, right? Every tiny application on the internet has the potential for security vulnerability which means every single script you've ever put out there is probably vulnerable. There's no such thing as an organisation that is too big or too small for security to be important. So whether you are able to spend thousands of dollars and get professionals in or not, the size of your organisation matters there. But in terms of whether you need to care about security in general, not so much. I commonly hear that security is impossible, that people have gone to talk after talk after talk where people have gone in the traditional security presentation style a bit like this. Hackers are coming. I have developed an exploit tool that will break into your system in three clicks. Click, click, click, ta da! And there we go. And that's where the talk ends. And everyone leaves a room feeling really, really dejected because how on earth can they save themselves hundreds and thousands of these scripts and tools when there are literally ten or more malicious perhaps people out there doing strange things on the internet to every one person defending. But it's not impossible. It's hard, absolutely it's hard, but scaling is hard. Anything in Gentoo is hard. You know, we don't avoid these things. We just kind of get on with it and we learn. Agility doesn't increase risk. It's one of the biggest myths out there that you can't switch to being agile. You can't move quickly because risk increases. Now this is based on the fear that you can't do your traditional gated approach. You can't have a pentest every time you release because you're releasing three times a day. Now there's another side to agility that isn't reflected in this statement. And that's the fact that if you are deploying three or four times a day and you've got mechanisms in place to spot problems in your code quickly, the time from spotting something to resolving it and deploying a new version is very, very small. In a waterfall life cycle, if you find an issue, chances are it's going to take you a matter of months before it's gone through the entire process and can be deployed in a regular deployment window. If you are in a waterfall and then have to do it out of band because it's serious and it's got to go outside of the patch cycle, then that's entirely complex too. You can't move at the same place, you can't react at the same pace and you can't therefore resolve the issues as well. So while agility changes the way risk looks, it prepares us to react quickly when we do find those problems and we will find problems. My personal favourite of all of the problems that people have with agile security is that we've always done this. The code has remained unchanged now for 15 years and nobody has hacked us. The only response I have to that is bash. We learnt in the last 12 months that old code is also vulnerable code. And just because it hasn't been found until now, it doesn't mean it won't be found. There are thousands of people full-time employed looking for security vulnerabilities in known software packages. And it's just a matter of time. Bash gave us a really good example this year where we need to not just consider the security of our new code, it's easy to go in going, oh we're going to do security from the start when you have nothing to begin with, but why we need to revisit the security of existing code. And I don't mean re-engineer it, I just mean look at what we wrote and understand where our risk is. So let's give you ten steps, right? Let's give you ten things you can take back to your organisation or your project or whatever it is you work on. Wrong way. Right. Now this is not a reflection of all of the community but some of the Linux community have been prone, and I do generalise, to say statements such as, well, I run free BSD, therefore I don't need to care about security because it's more secure than other distros. Or I write everything in Node.js. And Node.js is inherently secure because it's modern. Or I'm a C developer and therefore this new fancy pants vulnerability thing doesn't affect me because we've always done it this way. Firstly, all technologies have security problems, sorry, all of you. They're all a bit different, they're all a bit special in their own way but they all exist. The debate of which technology you use versus another is sort of boring. So kind of get past that and just know what is in your stack. Every layer, right from the operating system, that's important. But right the way through up to every single library, every framework, every CMS you're using and every bit of code you decided to get off stack overflow. Every bit of that stack could introduce vulnerability and it's your job to keep an eye on those technologies and see when they get updates and see when you need to change your code to prevent a threat from happening. So knowing your stack is actually the most fundamental thing you can do and then stalk your stack online. Find its Twitter feed, find the news groups, find the IRC channels, find where people actually talk about this stuff and keep a track of it. Now that can be daunting, right? You've got hundreds of technologies in your life, following all of them is hard work but you'll find a way. You guys are engineers and scripters, you've got things that make this easier for you. Adapt, adapt and abandon, right? So what am I talking about? I'm talking about the dance of security. If you read a book on security, any of them, it will talk about governance frameworks and processes and many things have been developed over 10 to 15 years and if you're in a very large, very bureaucratic organisation many of them will still work. But when agile organisations try and incorporate these security routines, they get crushed by them. And so people go, well, I'm not going to do that because now we can't do anything. Now we are stopped, now we are not innovating, now we are not delivering. So when you know there's a process you need to do such as code review, such as an architecture review, such as penetration testing, whenever there is a security thing you know you need to include, look at the process as it is written, how it is recommended, but then feel free to add to it, adapt it or say screw this and abandon it all together. I give you permission to not do it if it doesn't make sense. Look at the objective that that routine or that workflow or that task was trying to achieve. And then try and find a way to do that objective in your workflow. It's not about doing the right steps to the dance, it's about reaching the objective and that objective is to reduce risk and help you survive a security incident. Communication number three. So security people, myself included, were very guilty of this and technical people in general, we are terrible. We are terrible at jargon and at absolute meaningless twaddle in every aspect of our life. We baffle people like it's a magic trick. Now, as security people, we are trying very, very hard to pull back from jargon and work in plain English terms. Now, another thing I give you license to do from now onwards is call out people in your environment when they're using a phrase particularly in a security context and you're not sure what it means because if you're not sure, it could be that it may not mean exactly what the person who's using it wants in the context. And context is important with language. So challenge them. If you've got a vendor coming in, you know, a good look with that, but challenge them on the language in their marketing materials. When things say they align with or are guided towards ask what that means. Once, thank you. When people use the word critical or high in terms of severity or impact those words have meaning and they don't just mean something that all of the world means the same thing. They mean something specific to your context. So go back to your teams and write down the words on here. So informational through critical now, later and never and define them for your organisation and for your team because those terms are really important and you need to make sure you mean the same thing. You also need to make it okay for people to say I don't understand. I need more information can I have some help? We're really bad in the tech community at kind of making it hard to raise your hand and go yeah, I'm sorry, I need more information. So always give people permission and there is no consequence to it to say we don't have enough information. How many of you heard of the phrase of technical debt? Yeah, how many of you have technical debt? Yeah, don't we all. Now technical debt for those who aren't familiar with the concept is the idea that as you go around building things there are certain things that you want to put into your systems or you no need doing but you don't get around to. Now it could be because you just don't have time and you'll get to eventually and sometimes you realise over the course of your project you didn't need that feature to begin with. It's natural and it's kind of technology's way of pruning and keeping you focused. Unfortunately when we put security things in the same pile it all goes horribly wrong. Now I work with applications of all sizes and shapes developed by like four people in a basement three to four thousand people globally. And I consistently see security issues placed on the same one as usability functions and tweaks to the colour scheme. They are not all even. You need to make sure that wherever your debt is documented that you highlight which ones are security and you make sure you understand what the issues are and what the risk is if you don't solve it because that will help you prioritise those out of your debt queue. Technical debt is one of the reasons people get hacked. How many of you heard of Briserstack? How many of you know why I've mentioned in a security talk? Go at the back. Can you yell it? Don't worry, just yell. Of course. So, the very Cliff Notes version. Briserstack is a really sweet piece of software actually. It's an online service where it lets you test your application in hundreds of different browsers and on different operating systems. That's not helpful, Jaco. Really, really not helpful. It lets you test your application on tons of different browsers so you can see what they look like and they work the same. It saves you maintaining a whole army of VMs and things yourself. Now, they were compromised in the last year and an email was sent out to all their clients explaining quite how diabolical their security was. How did it happen? It happened because they had an old test box that was still deployed on their live internet-facing systems that they hadn't gone round fixing yet. They had to turn it off. That was technical debt. That was something they hadn't got round to and as a result it wasn't secure and as a result somebody compromised their database, took their client list and made a heaping mess of their reputation. The company will probably bounce back but it was an important lesson in managing your debt. Security is often the thing that we engage at the bottom of a cliff when it's all gone wrong. You can't even get phone calls because you've been hacked or because there's strange activity in a log or when the world is ending we get a call. The trick with agility and security is to engage as early as humanly possible. When you have that idea over your dinner in the evening or first thing in the morning when you get up and you're off on your run or whatever you do engage security in the process from idea onwards. It is very difficult to integrate security into an application after it's been built. That creates very fragile code. It creates unmaintainable code in some circumstances and it can be really really expensive to do that in terms of not just money but in time. In formalised agility we have an idea of definition of done and that's a formal way of saying our code is only done when we've done certain things and those are things like has been tested has some documentation. If you have a formalised idea of what it means to be done add security into it. Add secure code review. Add a design review and I'm not saying get a specialist in I'm saying use things like I can't believe I'm going to say this in a Linux conference Microsoft have some really really good guidance free of charge on the internet for how to do threat assessments of systems of any kind regardless of language call look up stride if you want to go and look it up. They have a lot of resources that you guys can go and actually use yourself. So make sure you've got it in your definition of done and get in there early because finding out after you've been hacked that you may have wanted to consider security is too late. And then prepare for the worst. Now the sad reality is that you are likely to get exploited that your application whether by an actual motivated individual or unfortunately by a pearl script left to go wild on the internet is going to get attacked and sometimes it will get through your defences. Everyone needs to prepare for what would happen with the case and preparing isn't just a case of monitoring your logs while that's really important it's things like who would you need to contact? Who do you need to tell? Do you need to involve your legal team if you have one? Do you need to disclose to any governing or compliance authority? Practising these things and getting a plan together beforehand makes it a lot less stressful in the case of an emergency. Now one of my previous jobs involved working in a basement doing very crazy things and we used to work in an operational style where if something kicked off and something bad happened we would have to react very very quickly. I learned very very quickly that when people are under stress particularly technical people they are not the same personalities and they are not the same personalities you guys have in the room today. So by testing our incident response plans and getting this stuff together in advance we rule out the effect of the strange personalities from the decisions we make and those decisions can be affected by things like I personally get slightly bossy when I'm stressed I'm called a field marshal in some circles that's fine but you need to know it. Some people, and this is no reflection on any particular group of people diversity or otherwise, actually get touchy feeling and I mean they like human contact they will tap your shoulder or put their hand on your back and that's not a reflection of anything else other than a very human instinct for connection in a time of stress. You need to know who in your team is going to panic who is the person who is going to hide in the bathroom for three hours and you really want to make a decision and this is far too scary you need to know who that person is not so you can blame them, blame is not part of this it's so you can prepare and help those people get through it. In terms of how you can prepare keeping logs goodness me I speak to people about logs and what they keep logs of and some people do scary things like I keep it till it rolls over and when does it roll over at a time of time and what's that, 20 megs so about 14 minutes right, fantastic other people are more savvy and they've got maybe a few weeks but the reality is many compromises aren't spotted for 18 months could your organisation go back that far through as logs are you keeping your logs in a place where they can't be tampered with by somebody who's attacking or are they actually sat on your main web server or your application cos that's probably not a great idea all of this comes into preparing and it's not about being defeatist it's about being ready for it and I see that more as a challenge to be ready and prepared as part of what we do rather than being scared of the world we live in and then you're going to build an army now security once upon a time used to be the realms of the security team if you were lucky to have infrastructure or operations now when I say build an army I mean that every single person in your organisation is now responsible for security so congratulations you all got a new job who knew you get things at this time in the afternoon now I mean everyone I mean your first line people who answers the phone if somebody rings up because your application is behaving badly have you ever spoken to them and given them the skills they need to answer questions of the security nature who does your customer support and your long-term management what are they saying about security of your products you probably should find that out your developers, your infrastructure people, your ops every single person has a role to play in security and everyone needs a different type of support gone are the days where you just send people on a CISA course or whatever the latest certificate of choices we have to tailor our engagement with every type of role so everyone can do security and we work together if you've got 1100 developers for example and you've only got three security people will those three security people be able to do everything they need to do to keep your application safe probably not there are a finite number of hours in the day and you know we've kind of got to get on with it so if they can't then we need everyone to help out and that's where building an army comes in automate your workflows the Linux community is awesome at this so I don't need to dwell on it every system you automate in script is one less system you're going to get wrong when you're having a bad day and human error is actually a massive cause of security vulnerability so automate all the things I'm a personal fan of a mutable architectures and chef there are hundreds of ways to do this and you don't need a lecture on it so go talk to the rest of your community and automate everything if you're not redundant by the end of the week then you've done it wrong security fails when it's a special event if you are the type of organisational team that only brings in security once a year they come in in a spiffy suits with a clipboard and you do we do security this week you do an audit and they leave again you've done it wrong it should be the type of thing you talk about in your monthly little pizza and beers meetup thing or whatever you do inside your organisation to spread news and share knowledge security should be always there it should be something that's okay to question it should be okay to break things in your organisation and if you ever want to learn about how to break things and have a lot of fun and do security come talk to me afterwards and then outsource smartly now I'm a security vendor in a way I have a consultancy I sell things we also write software that's why we do consultancy to kind of keep that funded and it's open source software so you know one of you guys sort of you are going to outsource or your organisation is going to at some point and it's whole true of whether you're hiring someone like me or anyone else or whether you're buying a product always hold them to the highest standard they are going to take a lot of your money ask them about what their research is ask how they're actually experienced in the type of environment you're in the days of generic security advice are gone you have choice and go and extend it go and find out who the people are if they're not pushing the industry forward then don't give them your money right common challenges we've not got long, don't worry you're almost free so compliance sadly is a priority how many of you work in an environment that has some form of compliance over it so legal or PCI DSS or yeah quite a few of you the sad fact of the world is whether we like it or not compliance regimes are there we have to adhere to them because that's what keeps us in business so we do that we do compliance but please do not be confused compliance and secure compliance is tightly scoped it says these three systems here meet audit criteria hackers really don't care about scope no no no we will find every person every operating system every host in your environment the ones you've forgotten about the ones the marketing team put up in a hurry for that call campaign that they thought of everything we will find everything is a scope for us so please don't treat compliance as secure treat it as something you need to do to do business but it's only a starting point there is a very predictable learning curve when it comes to integrating security into an agile environment now it goes a bit like this I'm going to do security this is awesome I know I can do it I feel empowered and your enthusiasm goes like this and then you start finding bugs which is awesome and the bug curve goes like this and then eventually the bug curve keeps going and your enthusiasm kind of starts to wane because you actually realise that bug curve is going up way way quicker than the number of bugs you've fixed suddenly you can get really really down with the whole thing the whole thing feels like an insurmountable challenge don't aim to get rid of all of your bugs don't aim for 100% security you need to maintain momentum you need to do it in little steps so every single day everything you do try and do one thing, just one slightly more secure than you would have previously done it that's as simple as change that password that you know is shared with six other things change that password that's on the wiki that A shouldn't be on the wiki and B probably should have been changed six years ago maybe look up what that library is that you're using make one thing every day and before you know it, actually that pile of bugs starts going down without your enthusiasm going down with it hire good people this could be a talk in itself and there would be a whole panel of us telling you the qualities that make good people good people are the people you can stick in a room and you ask them how they would rob a bank and they can give you honest to God answers of how they do it and why and that doesn't mean they're bad people it means that they are people who understand risk good people are the people who actually think about decisions they're making understand consequence and don't cover their tracks people who are honest people who admit that they don't know things they admit their own vulnerability so hire good people and if you need help hiring good people reach out to the security community reach out to your peers and let them help you find the good people there's no time in this industry in the security world for us to have people who are show boating or making things up or hiding behind their very impressive resume or LinkedIn profile there's no time for that hold them up to where you need them to be if they don't meet it, find more and by that also find some juniors come talk to me afterwards if any of you are looking to join a study group to learn about application security if you're a student or in a tiny wee start up come talk to me afterwards, free training hooray use your words yes is a scary word to people like me when a developer comes to me and says I want to use Heroku and I want to write it in Node.js including both side, server side and client side and my instant reaction is to say no no don't do that no is cheap to me no gets rid of risk if I say no and you don't do it I've won but you're engineers and if I say no to an engineer you build around me, under me through me you'll completely ignore me so security people if you're in the room, learn to say yes more but say yes with caveat say yep we can totally do that but let's have a look at this bit here let's have a look if we can get some guidance about doing this securely and those of you who are the developers who come to people like me and go I love this new technology let's do that slow down, just a little please don't scare us just come to us with a we would like to and here's where we think risk is and let's look at these things a bit before we jump in so we've gone through a few common misconceptions we've learnt that we all need to care about this and I've given you ten ways to do it the video will be up online as will the slides so you don't need to have taken notes what I'm hoping is that you will understand this is achievable perfect security isn't that's an absolute fallacy you're never going to get it let's give up on that idea let's aim for survival let's aim for little bit more secure every day let's aim for building security in the same way we build in scaling and performance okay if you have any questions I probably have like a minute and ten seconds or something anyone Ray hi if not I can repeat the question it will be easier so one of the things that we do with agile software development is that we build things in pieces and we don't build big chunks to start with you know it's partial functionality towards a total goal the thing with security is often you need a big picture view of that how do you think the best way forward of doing that you can't build a little bit of security on client side and a little bit later on sometimes you need to take that step back and look at the big picture how do you propose that fits into the agile model yep okay so to repeat the question slightly is how does security fit into the agile model when you're building incrementally and getting a picture of the aggregated risk is actually quite challenging now this is really topical the Ruby Yamelberg from the last couple of years it was a prime example of where this goes horribly wrong where you've got very intelligent developers making very intelligent decisions on independent components which when placed together introduce risk significant risk in that case now what I would say in that circumstance is you need to free up some people instead of just being on the two weekly cycle or whatever your iteration period is to actually spend some time at the architecture level looking at where the changes you're proposing integrate because security vulnerability often manifests around boundaries so boundaries between groups functionalities trust boundaries boundaries between components so freeing up somebody and training up some people with some architecture skills and letting them do an iteration or two where they are actually looking at the aggregated picture is a worthwhile investment sometimes you need to pull back on the velocity that we're used to so this concept of having a continuous speed for the rest of forever sometimes we do actually need to take a break and the one thing I would say is don't leave that to somebody who's outside your dev team to do on their own don't just leave a rogue architect all on their own to do it they don't have the contextual knowledge of what that code is doing to do it valuably so get across functional team get people from different areas of the code base different areas of functionality with a security person, with an architect and actually look at the piece together to a business it's very difficult to articulate to seniors as to why it has value but find a way to make that something you can communicate and show benefit from Anyone else? Well that was easy Oh one last guy, hi Run Jack, I run Hello, I ask this at pretty much every infosec talk How do you convince management or clients if you happen to be a contractor to actually care about security? Okay, so that's a hard problem so the question is how do you convince your management right, because they're the ones who are going to have to let you have the time and the money and the resource to do this Now sometimes the best way to do it and I found the best way to do it is to actually get your management in a room and make them plan breaking into your organisation Once you've got on the senior leadership team of a bank planning robbing their own bank or the senior leadership of someone like trade me as an example, writing their own phishing emails It's very different perspective wise from when they feel like these attacks are somehow foreign to them that they're not achievable by people like them So you need to give people the skills to actually understand where risk comes from and the realities of who is likely to be attacking and sometimes the best way to do that is to actually include them and make it practical The other way is to translate it into business benefit and to use case studies from around the industry Now in New Zealand we're very bad at that because we always assume New Zealand businesses are better than everywhere else or more secure because we're little and nobody cares about New Zealand but the reality is we trade globally now and we can't think like that So looking at the case studies around the world as they come in and don't just send them a news article send them a link to the article with a here's how this is similar to us and here's how we should be changing to avoid this being us because then it stops being something they need to process and digest and it's something that they can then do tangible action with and it's something they can distill and chat about at their level they have many other priorities and it's finding a way to inject that into their world without it crushing them Hi I think we agree here in this room that testing for security in your software is obviously important but it's also important to test the human component and see where people actually fail so my question is until Ada is released how do we test for that? Okay, so to give the audience and the viewers at home some context the question was how do we test the human element of security until tools like Ava are released now Ava for those who weren't at Kiwicon is a tool I'm releasing which does very bad things to very nice people I'm really sorry find out about that in another time that's not for now are there easy ways to test? play pretend if you need to plan a robbery go look at your house go figure out how you'd break in if you have to think about it for more than 10 minutes and it doesn't involve a blunt force instrument through your windows try again this is the kind of thing you need to do you need to look at the common denominators a simple ways to attack people and then make a safe way to mimic it in your environment and that's going to be specific to your environment it's not a global thing we can do I'll think we have time for one more question Okay, anyone else? Wow, hi I'll let you choose and I don't have to feel guilty those of you who don't get to ask please come find me at the end and I'll have to answer any questions Thank you Just a similar question to what we were saying before I work as a systems architect and one of the difficulties I often have is trying to convince developers that security and architecture is actually an important thing that they need to consider in a project So a similar question before how do I convince developers that security and architecture are an important part of a process? Okay, how do we convince developers that security and architecture are a part of the process and they're important? So it's a slow process Actually, the best way to do it the most successful thing is actually to become closer to your developers Your developers are probably set in small teams working together regularly The architects and security team are normally isolated from them and they only ever come in when there's trouble They come in, they say your baby is ugly you should feel bad and they leave again This does not make friends Go be with the teams I don't mean formally join them I mean if they have stand-ups go to them If they're having a retrospective and a review and they really want to show off what awesome code they've written go along, don't just be the angry voice in the room actually go to the positive things too You want security and architecture to be something in your organization they see as a beneficial thing they can call on at any time that your door is always open and that you are there not to judge them because they don't know there are gaps in their knowledge but you are a resource you are there to be to help them If they are seen as a barrier or as a blocker they'll just kind of avoid you So most of it the biggest change is in how you interact with the teams and it's going to be specific to your organization or situation but the guy at Etsy who came over for Kiwicon Rich Smith and their organization they have a policy and security team of being first up the bar with the credit card Now I'm not promoting drinking culture but the sentiment there is be involved and be part of it You are not separate from the dev team you are one with them and it's just like I as part of the security community I'm trying to come out into non-security world and actually become closer and learn more about what that world is like so I can help that's exactly what you need to do with your developers Okay, well thank you very much If you need to contact me my details are up on the slide please note the underscore in the Twitter handle if the lady nerd gets angry So yeah, it's been lovely please feel free to ask questions via email, Twitter or wherever Seriously, we would rather answer questions to anyone free of charge over coffee than we would the world to be a less secure place so you know we're here to help you, let us do that Thank you