Let Me Secure That for You

good afternoon my name is Kirk welcome to my talk thanks for coming so this talk it's called let me secure that for you because it has a really good acronym I thought and how much do I want to say now not much and what I want to just point out and this is because I did a dry run at work and they like people might think this is actually what we do at red shield so I just want to point out this is not what we do at Ridgefield we don't use mod security or nodejs although we do provide a service that provides like website shielding and virtual patching with a whole bunch of other services around the outside of it

so yeah let's talk it's not an ad for what I do at work and you shouldn't go away from this talk thinking man those guys run red shield on like a couple of docker instances that's not how we do it so today we're going to talk about how does virtual patching work and can you do it DIY style but first off let's start talking about building an app so you've got this great idea I don't know you want to river wash revolutionize the world of to-do lists or I don't know have a flappy app flying game thing or something like that and you're like I need to spin up a dev team to build this

and I'm going to have a software development lifecycle and we're going to like code the heck out of this and then we're going to chuck it on a web server and you stick the app on the web server and you're like man my friend said something about firewalls so I guess I probably need to like have a production environment and put firewalls in it because otherwise bad guys might get in and then you know like oh we need to take payment for it so lemon PCI so we need to install AV on all these servers that no human ever goes on anyway and we need to have a web application firewall and a proxy for outbound egress and

you're kind of like okay now we're secure right we've got all this stuff but then like well we need to have an intrusion detection system to find out someone hacks our environment we need to down loss protection we need to manage identity of our people admin in these servers and we need to make sure all our servers are the same so we need to run like an agent on all the servers make sure they're up to date and then we need to read those logs so we better pump them out to a seem to be ignored and then all right now we're secure because we've got this pipeline like the the stuff we're putting code in there and

it's in a secure hosting environment but what if the codes not actually secure to start with so maybe we need to go back to our sdlc and do some training for the developers and you know have security reviews of designs and you know part of the BA phases of our apps do some threat modeling maybe run some static analysis of our code or some dynamic analysis of our code or maybe some eye analysis of our code and then like get security testing done maybe part of the process make sure that we're not introducing bugs into our environment so you know good good quality software n it's a hardened environment we're reading the logs we're secure how to do it as a

secure Stewart in the world o rest I forgot to mention that because I don't really know what it is but then you like well we need to have processes to make sure that we do things properly right we can't just put the stuff here and walk away because you know the average like lifetime of an employee and an IT company is I don't know two years and the government departments like three weeks so you need to make sure that you know you have processes to ensure these things keep happening so you need to like an OS hardening system you need to manage patches going into the environment you need to make sure that you know files have changing randomly

and that you know you've got all these people using the environment but you need to make sure that you know when they quit after two weeks you remove their access and when they change roles you need to have like an overall configuration management strategy and you need to have like cloud protection workflow agents and stored on your servers we're kind of secured now yeah yeah I think we're secure ah got another one at police automation because you know we want to make sure that the app that's in production gets there as smoothly as possible and as close to actually what the developers intended as possible remember we need to monitor some stuff because you know the

seam is like outputting logs but you know we need to like feed stuff into it make sure things are up and then we need something to monitor the same in case the seam goes down we need policies just to keep John happy and we need standard operating procedures there's a little Richfield joke standard operating procedures and you know now we're secure and you go to talk to the board of your todoist application and you're like we've got the biggest most secure application ever and no way prove it so you run some vulnerability scans you have someone come in and do a third-party configuration review you pay like squillions of dollars for or information security do penetration testing and they

like just walk in with a swipe card no just kidding there was a callback to a previous talk and and then plus you actually have real attacks and now your management can be like confident we're totally secure you're doing all these things and you know you're falling industry best practices your app is secure I mean it's only a to-do list app but you're doing everything right now so we're building our app securely we're hosting it securely and we're verifying that it's secure now this is a pretty cheap process and hopefully you're all doing it and if not I'm pretty sure there's some vendors who are probably present or at least in the market that can help you

out with that so we're built a secure web app so this is the end of the talk thanks for coming no I'm not quite what if there's bugs in our app so the normal process is yeah well the normal process is you don't know but pretending you do know there's a bug and that's a security issue you like ring the red bell and gather everyone around and say you know we need to we need to fix this if you're lucky your wife might block some simple attacks like sequel injection or cross-site scripting but but you know there might be more complicated bugs that the developers need to recompile and deploy a new version or a few are

like a dynamic language they need to write new code and cross their fingers you know like that sort of thing and so you really need a really fast release process so that the developers can make the change in yellow deploy it and you're sweet but this is really expensive so I've worked in companies that have you know priorities and objectives and annual plans and stuff like that and none of it see it drop everything and fix security issues in our app and you know you've got the overhead of branching and merging which developers will tell you is like the worst thing that could possibly happen you got you know like Change review board probably depending on where you

work you've got to actually release the software which means someone has to wake up in the middle of the night and you know this takes time and it can take a while from when the problems discovered to when you release it and the clock's ticking like if it's an externally reported vulnerability you know there's a blog post waiting or a tweet really for you to fix it and you know they're going to talk about how it takes you ages to do it and all you gave them was a lousy yahoo t-shirt which is probably a collector's item right now anyway because and I like often you don't even have the source code like it's you know

it's SharePoint that's got a security issue or it's you know like Jon's financial system sorry John not you different John John's financial system that you know was running in 1998 and you know the source code was in you know visual sourcesafe and you know that was on Bob's laptop and Bob left ages ago and you know you can't even fix this yourself and even if you do need to to do this like how are you going to release quickly you're going to circumvent all your regular processes so that you can get a change out in which case like what was the point in the regular processes and you know and blah blah blah DevOps or you know I

this sucks so what I was interested in and previous I guess when I was kind of responsible for getting security issues fixed through the pipeline is how can we patch the issues without touching the underlying website so you ring the alarm bell and you say dev team your stuff needs to be fixed as urgent while they're doing that can we fix it and the security team can we patch these issues without waiting like as fast as possible and so what we're doing here and this is kind of the foundation for Ridgefield as well but this is not an advertisement because this is actually a thing it's called virtual patching and what we're doing is replacing the waffe were

they're more capable layer and I've called this let me secure that for you because like you know we're securing it for other people and the acronym was good which was mainly the reason why I chose that so here's a table with some kind of vulnerabilities that you might need to fix and you know some of them you can do just with a regular proxy so you know like we had an application where there was a particular URL that was kind of insecure had an issue owner but have they anyone used it so we just block that on the proxy but some things you need a way for like detecting sequel injection attacks or cross-site scripting attacks you know that's kind

of specialized that where´s can do but West can't do everything like they can replace HTML but it's normally a pretty janky maybe they can't like modify the request due to performance reasons you don't have States so you can't fix business logic issues and they don't understand your users and their roles and the way that you might need to do so I guess what I'm advocating is another layer which is the code layer which is it's not the developers code as the the security teams code or whoever US code that you stick in front of your app where you can do those things that other layers can't do so that iOS definition virtual patching is preventing the

exploitation of an on vulnerability and it's actually it's not anything new firewall vendors have been talking about this for ages for sort of OS and network level attacks and things like there it's basically just you know having signatures and blocking attacks I would say it's an agile security approach because if you put agile people will like believe you but what I actually mean is it's a fast approach and that you don't have to recompile applications and deploy them and stuff like that and you know you can react quickly so this is our approach for doing virtual patching so the first thing you need to do is understand how to actually exploit the vulnerability because if you can't

exploit it then you can't fix it and you can't prove you fixed it then only patch things that are actually known don't just like oh man it's probably unsecure let's just turn everything on and patch everything because you're probably going to break stuff and I'll talk about that in a minute and avoid I actually I don't talk about it right now avoid over patching or doing things that will cause issues so the reason a lot of people I should have seen how many people hate wefts would that be fun how many people hate wefts oh man all you liars you've never used a with a lot of people hate West because when you try and turn the security on the application

turns off and it's kind of like this there's a continuum and and people find it really hard to find that sweet spot where the application is protected so we're going to focus only on the individual thing that we know is broken so this works really well like if you've got a pin test that says you've got seven things wrong or you've got a like a vulnerability report come through hacker one or whatever that says you know the specific thing is wrong because you can fix exactly that thing and not be worried about breaking the wrist of your side yeah through the use of eff statements cool just a little yeah I've got to ask you as a developer I'm sure

there's a bunch of different things you can do affects security issues you could just block the user like we did with that URL you can redirect them to an error page you could transform the request or response to make it safe so maybe if there's some input your application can't handle you could strip those characters out or maybe there's something the apps displaying you don't want people to see strip them out you can do validation like insert error messages to say your passwords too weak or you know like insert that into the stream of HTML and then of course you need to alert so you actually know you're under attack because you know you just paid 4.2 million dollars for a

scene so you need to use it so here's the here's the architecture so I guess you could say this isn't this isn't like a software project that I'm presenting it's more like assembling a couple of different components with some config files and there's a web page you can go to which is let me secure that for you LM STFU com where you can like github these things and I wrote documentation and it's like this is the first time I've actually actually released source code when I said I was going to release source code and the trick is there's not actually that much source code but there's mostly documentation cool so what we do is we

stick a web modsecurity in front of a node app that's custom and and have that sitting in front of our web server so like seven people in the audience just frog freaked out and oh my god he used the word wife and here's some legitimate quotes that I made up from real people with their issues that they have with wife's and and it's kind of true like everyone finds it really stressful but just to recap to go back all the way back to the slide three slides ago we're only patching known vulnerabilities we're not just putting a wife in front of our app and turning it on so don't freak out so first let's demo a

vulnerable website so here's one I prepared earlier so this applications running on localhost due to a weird browser quirk that I discovered right before my laptop ran out of battery last night and then couldn't sleep very well because I thought my demo wasn't going to work today and then when I came back into the office and charged my laptop it was just a browser quirk anyway enough about my sleep patterns so this is a site called zero days it has a logo that a guy called Jeff made for us which is pretty cool you can use fonts and stuff and basically on this site you can go and buy zero days let's just ignore the fact

that yeah anyway let's pretend this is a real thing so it's a daily deal site for 0 days and basically what you can do is you can like register and log in you probably need to turn docker or on that's like a really good time to do that I thought I'd turn it all off so like everything is clean and back to pristine so you can register an account on the site people can go and look at products and make comments on them so just cool good password so this is on localhost so yeah just browse to this if you want to look at my site cool yeah so i registered i'm logged in I can add

products you know I can buy ten of them I can go ship them somewhere and here's some autocompletes I completed automatically cool give me a call anytime you want hey hey hey automatic credit card filling is to sit well thank God

that's a real 21 okay you know and then it authorizes your credit card and then you know here's your order in your place in order so this is called internet shopping so so and then you can go look at your order and you know you can search for things like you could search for all the vulnerabilities that are for sale for ghost script and you could put a comment on this is old or something like that and you know social can happen cool so that was the app technically how it's built doesn't really matter I'm not going to open up the code but but just because I like to brag that I can still write code as a dotnet core

app well it's for three apps running and docker on Linux with what so called sequel like there's a database cool so yeah enterprise-grade yep cool so so that's our app so so we've released this app and you know it was great and somewhere in the c-suite they said prove that it's great and so then they gave like three times more than we get paid to security consultants who send us this quality is a number one dream where yeah and you're like oh look at this table of contents good and it turns out that this app has some vulnerabilities in it hands up if you've ever had one of these reports land across your desk man

opposite guys don't put your hands up yeah so so we've got some vulnerabilities so let's look at some of them so I'm not sharing the source for this app because it did it on company time but you know hopefully these things ring a bell so vulnerability number one turns out there's an admin section to the site where you can go and look at you know everyone's shopping carts and eat at products and stuff like that and so ideally that wouldn't be exposed to random people from test comm another nice little vulnerability which is kind of like a real-world one is that you can like buy a negative quantities of stuff so how many do I need nine I think

that's heaps cheaper cool what else oh yeah there's a shopping cart thing that you go through I'll just clear it because that makes the demo work wasn't that clear and buggy code um there's a shopping cart you can go through and you know how I we just did it that you could type some stuff and to pay wow this was way faster in my head payment details screen where it's authorizing your credit card you can't see the URL because the resolution but that's slash step three let's just skip that step oh yeah payment by credit card empty okay place order cool that orders now shipped what else oh yeah anytime you see a search box what do you do single quote

Oh is an error what a surprise it's almost like it's contrived so you know if I search for ghosts I see one item but I can Union with random other tables in the database this is called sequel injection and doesn't work but when it works you can get stuff from other tables in the database oh yeah I forgot a quote Thanks thank you to the professionals in the audience it's like it's cool don't you love it that you just paid to attend a talk by an amateur although I think it was it $70 for the conference 50 and there's like 40 talk oh this is a dollar you paid a dollar to be here don't complain I was cross-site

scripting you've probably seen this little baby before it's really common and every application somewhere around and so you know I guess I can't explain what cross-site scripting does but it's normally a bad sign and when I'm looking at my orders I noticed hey there's a number on the URL what if I changed that number oh I see Joe Bloggs his order cool okay so our web app is screwed and this has nothing to do with all those fancy things we put in our environment okay like the seams not going to fix this the wefts might fix some of it but like some of these are business logic issues you know like who can see whose order or do

you really need to go to the credit card screen before you go to the place order screen so how we're going to fix these let's go back to slides because they will tell me what to say next yes so we saw all those things I think I might have missed out a couple of them but needless to say the website is hosed so the first layer we're going to stick in as modsecurity so contrary to popular belief modsecurity is not a dead project it's just a dying then resurrected project so modsecurity is a open source web application firewall that you can install on your web server what really makes it good is the OS core

ruleset so hey look there's a picture um the bit that I like about this picture is that I'm running like three different versions of Linux in a vm thing on my macbook in order to like serve 50 lines of code it's crazy so uh yeah docker so that's talker so mud security is it's originally built for Apache and sort of released bridge to get it working an IAS and nginx but it didn't really work that well and those web servers so they're rewriting it in version 3 and it's going to be much better but unfortunately a lot of the features are supported and the version 3 yet because they've been finished up um the nice thing about mod security is it

doesn't really do much out of the box you can just like and they will the module nothing changes on your web server until you like configure it bad betters you have to configure it the reason I went over and got this book is because there's a modern book with examples that are actually correct unlike most of the stuff on the internet about mod security which applies to old versions so I've got some links to stuff that I think is relevant and that's actually quite a good book cool so how you configure mod security is you go to this eleven hundred and seventy-six line file that you get in the default install and you start uncommenting lines until

it works and the mod security core rule set as this project it's kind of an OS project I'm not sure what its history is and how it got to be a part of OS but it's a bunch of rules for common web security issues and the idea is that these rules are tuned to avoid false positives so your app almost shouldn't almost always shouldn't break by turning these rules on and the kind of default setting like they they block like really blatantly bad stuff as sort of a baseline and how the core rule sets it up is there's basically a whole bunch of conf configuration files and they're grouped into different types of attacks and they look at the requests they look

at the responses coming back from your web server and then they evaluate you know after looking at all there was this really an attack I'll just quickly show you how mod security works if you're thinking of using mod security to do virtual patching it's probably best if you cover your eyes and block your ears or you might change your mind no it's not that bad once you get the hang of it but the thing that's quick about mod security is that it uses a patchi's configuration syntax which is basically like action variable variable kind of thing so it's quite Foglia so so you have a security rule the first parameter is the thing that you want to test so

here it is in the file name of the request coming through the proxy and you can test those other things as well cookies whatever then you have an expression that you're testing it against they call an operator so this is a regular expression test against that string with slash inert to see if the phone name matches that path then you have the third parameter which is going to span over several lines because it's just where everything else gets chucked in montt security and you're put things like the ID so each rule has a different ID that shows up in your logs what phase of request processing what action to take so to deny the request to block it

to pass it and that sort of thing any transformations you want to do on the input which I'm going to skip / and then a message to put in your logs and modsecurity supports ending rules so using the chain keyword so you can say if they're on this page and this parameter has sequel injection then do this if they're on that page and that parameter has freed it and that do that and you can also do ours using this really ugly programming kind of style where you you put markers in your code and then kind of go to statements to jump to them but yeah like I said if you think you've using modsecurity try and

look past that and think of the price oh cool so so just to demo modsecurity so so what I'm doing in this demo is the exact same web application running in the same docker container but with modsecurity in front of it and the way you can tell the difference is the original app has a logo with fonts and the new app has a logo without fonts because I don't know how to do the art so that's basically as the request goes through I'm just rewriting the logo to make it obvious we're on the site cool so the first vulnerability which one should we do yes simple one so accessing admin users basically we just want to

block requests with a certain URL so the way there I've brought up my mod security configuration is for every vulnerability I've made a separate file with the number of the vulnerability and then you know that gets tracked and source control and or rolled out or you know have a cowboy thing you do and so all the issues like our sort of fixed and individual files so I think issue 9 was the admin URL thing and basically what we're doing in here as as chick if the URL begins with slash admin and then if the user if the user has logged in and they're not admin a tradeshow co-op's advertisement sorry the if they're not the admin user then you

block access to that URL so going back to our app log back in there's that test user doesn't even remember the password no lucky I do yes so now if I go to slash admin for Merlin okay cool so I mean you know you can just copy paste something like that it's pretty easy and your logs you end up with you know like an access denied error and somewhere in there is the error message that I put and if you had a seam you'd probably pluck butts out of that log file and have a dashboard and then no one would look at it cool so similarly with negative quantities so we block that issue so now if I go to update

quantities it's for bidding and that's basically just a regular expression wrong editor so it's saying look at all the incoming request parameters F and with a wild card in the middle and if any of them don't match the regular expression of all digits then raise an error so how many more should I demo of these cross-site scripting here I'll show you this because this one's hideous so we don't want people to enter XSS dammit they already have oh it's good a different product we don't want people to enter Exorcist so we want to block it when they do just excuse me while I do my elite hacker so what we want to do is like have kind

of a set of strings or common cross-site scripting that we want to block and to block that unfortunately the core rule see it which is this a wasp project that has a whole lot of XSS and sequel injection signatures doesn't have a nice way of just blocking XSS on one part of your site so you have to do this and this see told you what's head yes didn't want to spend too much time on that oh and I've running that up on lmst if EUCOM Adam so you can have a look cool and the same with sequel injections so that gets blocked so I mean you could do it a little bit more gracefully than

just forbidden but you know basically the idea as modsecurity lets you do this so let's find the slides here's some slides that kind of show what we're doing so we've decided that we need to check the URL and then reject that efforts wrong we've decided for validating a parameter we test if it's a positive number so we use a regular expression if there's XSS and the input we're rejecting the Empire so this is if you want to test for Exorcist this is one way to do it and this is why I advocate using our f-22 for XSS rather than building it yourself because the people that came up with us don't actually know what it does and and

it's hard to block XSS so these are the 26 regular expressions and that coral set project and the reason they don't know what it does is because they used a pull regular expression compiler to compile regular expressions and to new regular expressions and so then they put the regular expression of the regular expression and to the regular expression and then but yeah I mean that's what they did but it's actually been formally proven that for any regular expression you can invade it with input and so damn remember his name handsome pettersen nor didn't put it on there the lib injection project has been done by someone very smart which is instead of using regular expressions it tokenize --is the input

to block to figure out if something looks like JavaScript and then block oh they do the same with seat connection you can block cross-site request forgery using mod security but it's it's kind of horrible because you have to create cookies and then encrypt them then compare them but you know it's possible and I've got a sample that I've loaded you can add hitters if they're missing this is normally like vulnerability number one and your pen test report you forgot to set your cookie to secure so why do we use mod security well because the core rule set gives us like a low false positive set of rules most security is reasonably efficient at least you do simple things

relatively easy where relatively is about that thick and it can be extended to do complicated things but it gets complicated really quickly the limitations are it doesn't understand your application so it can't fix those things where you need to know about the user and what they're trying to do it's not very good at like changing content of pages they're daunting syntax its extendable lower but no one knows how to do that and if they do they haven't posted on the internet so business logic this is the interesting bit this is where you write code because you need to fix issues but how do you keep track of like what users are doing and what this

state is and stuff where they're your web app does it by putting stuff on the URL or using cookies or storing stuff on disk or in a database to keep track of which user is an admin at the moment and you know what orders are they allowed to see so we need to invent our own state storage just set in front and so that's where I just checked Renison because it's a really easy and memory cache to like store data so this this next layer is a node proxy so node has libraries you might have heard about them there's lots of them this only uses 160 libraries from node but the reason it's such a small number is because it

doesn't do a lot so basically I'm using red bird which reps the HTTP proxy and then Haman which I'll let you manipulate HTML so this is how a proxy works we should have done this earlier oh well you probably know anyway instead of your browser talking directly to the web server it connects to a proxy the proxy like copies the request and then sends it on to the real web server gets the response back copies it and sends it back to the user what we want to do is like intercept these the request and the response and do our own custom logic in there so we've got an on request Handler and a non response handler so before

sending the request to the web server we run it through our handler it can change stuff then we forward it on to the server and when we get the response back we run it through our handler it can change stuff and then we've seen the response back to the user so in this way we can pretty much do anything that the real web app could do we could write our entire application this way if we were insane so did I show you more complicated vulnerabilities yeah I did I showed how you could see other people's orders so what we need to do here is keep track of which orders people have and so in order

to do this I'm gonna use a hacker tool called telnet no I'm not because it's not there does anyone know the default port for Reedus ok you guys not helping here it's like docker or something whereas I'm docker do this for me which has been a docker or it uh someone told me ok no somewhere in here it's gonna say the port ok I'm not going to show you the port but basically what I was going to show you was rid us hey rid us you put data and you take it out ok so let's look at our app so what we want to do is when the user looks at their order screen the web server is sending back a

link of HTML with the orders that users allowed to see to see order 607 in an order 8 and so we store that in Redis and then when the user tries to view an order with chicken read us and see are they allowed to view that I mean that's kind of what your app would do is that we're doing it in the proxy layer oh yeah should be in my docker compose okay cool

let's come my kingdom for a port cool so I don't know how you're supposed to use Redis but this is how I use it so so when I go to their view all orders page you can see that it's sending to read us like this user is allowed to see or order seven and eight and then when I actually go to an order it's looking that back up again and checking that there that I'm allowed to see it and now if I change the order number to six it's blocking me and there's a little like security violation thing in the URL that you know you'd make that nice um how does it actually look in code I

don't know how many of your developers but hey I'm going to show you anyway so JavaScript I don't really understand that this is probably not idiomatic everything's asynchronous and you have handlers and handlers and like functions all the way to the bottom but pretty much what I'm doing is on their response to the order page when it's displaying a list of orders I go through the HTML by using a selector thingy and look at the URLs and grab the IDS out and then shove Ehrman Rudess and that Redis code I don't know how to do it properly but it's got like all these functions and you just Chuck stuff and rid us and then when someone comes back

to look at an order we check if the allowed order ID matches the one that they are supposed to be allowed to see yeah I'm skipping the payment step I'll skip through how this works but you can look it up pretty much we do the same thing so we're like which steps of the payment process has the user been to don't let them go to step forward till they finish step 3 hey well good animation on an arrow there mmm okay cool didn't see that and we can do other things as well that I had to do and and modsecurity and laughs like we can just use a CSS style selector across the HTML stream and as the HTML pipes

through node we can run a function on it and you know turn off the autocomplete flag of HTML or PCI compliance here I'm getting the credit card number div tag and replacing the value with a bunch of asterisks as asterisk because stars and you can do other kind of business logic things like you know check how strong people's passwords are like the app might allow weak passwords but you know your your code could check against have I been poned for the youth email address and this is something in a yes to check if the password strong enough that was jeans talk you know encrypt values that are in hidden fields that shouldn't be in fine text or put tamper protection to

stop people modifying stuff I mean basically the world is your oyster because you're writing code now write anything you can write in code you can write and your proxy layer why should you use node because javascript is the language of the Internet TM I haven't tested whether it's fast scale scalable but people use this node proxy library to front their node EPS so it must be pretty fast and because it's manipulating HTML in a streaming fashion you don't have to like buffer up the response edit the HTML as a giant string and then send the response through bad things how programming is so hard but I mean this is this I guess is a proof of

concept example of how you could do it but you could rep the stuff up into libraries to make it easier so you could be basically saying you know replace this with this store this with that and not have to write their readers code every time etc and we still need mod security because I don't want to write regular expressions in JavaScript to test for sequel injection and so like which tool is the right one for this as it is like a question so some of the vulnerabilities are thing did in both tools and then pick the nicest virtual patch out of the two so virtual patching is a thing people now know about it in this room you can

fix applications without having access to the source code or without waiting for a release and you can do basic things like blocking your rolls or you can do more complex things like basically writing application logic in a different layer now this gives you another tool to add to your tool belt and you know as security professionals the more tools we have the better or something and if you prepare this infrastructure in advance you can be ready to respond to an attack so putting modsecurity in front of your application as as simple as changing your Apache config if you're using Apache already and it's not going to add any performance impact until you start turning stuff on so you know it's really

easy to be ready to have that module installed so that you can use it or you could have this as a separate layer in front of your app that cool diagram of the animation that took me way too long most procrastinating content we're doing animation now we can react quickly and that's what all those things didn't give us the ability to do so you know that's kind of I guess that take away just to recap we're only patching like actual vulnerabilities we're not just turning modsecurity on for a whole site we're not doing anything crazy so there should be very low risk all this talk is not an advertisement advertisement and before I finish I have one second left I'd like

to tell you about a wast de New Zealand so Kim myself and a couple of other people who might be here organize this free conference the next one is in February it's an Auckland did I say that was free and it's a web security conference and it would be really great for you all to come did I mention it was free but I guess $50 is in a barrier anyway so we should just charge 50 bucks but then we have to do paperwork so yeah it's free we're really looking for people to speak share their stories now because this conference is about web developers learning about security as well as security professionals honing their skills they have two streams so if

you're a developer and you have a story this year about how you've done security and your organization things you have learned how you do your JavaScript or dotnet or Java or Ruby or whatever we'd love to have talks like that submitted or if you're a security Pro and you want to like talk about hardcore hacking stuff you know we have a room for you as well cool yeah that was supposed to be positive the other thing I would like to point out is that if you are a Wellingtonians there's an eyewash chapter if you're a Christchurch own Ian there's a there's a OS chapter and if you're an Auckland oh there's a chapter that doesn't have any meetings but we'll

soon we say that hopefully but there's also other meetups that go on on Wellington so if you've got interested in this security thing from this conference I bought a URL because the meetup URL was too long to put on my slide so just go to security meetups comment a list the Wellington meetup so you can go to some of them are closed most of them are open access and they have different focuses so go there and have a look cool sorry for going three minutes overtime oh no one minute and fifty three how do you use clocks um thank you very much for attending this session I hope you had a great conference thank you

[Applause]