 So I'm doing this for my third year now. I'm coming and trying to talk to you about security, because it's what I'm interested in. And I try to sort of vary my talks between attack and defense. So last year's talk was all about mess, ploy, and attacking stuff, and I'm afraid I'm back on defense stuff this year, which is the slightly less interesting side of security, maybe. Well, I don't think so. But anyway. So practical security, practical strategies for securing your web applications. I thought I'd start off with the very inevitable introduction slide, who am I? I've been in security for the last 15 years. I'm currently the director of a company called Seven Elements, based in Scotland. And I'm the Scottish chapter leader for OWASP. I do this every talk I do. Sorry. Who's heard of OWASP? Okay. Anyone use of their stuff apart from the OWASP top 10? Okay. Yeah. OWASP is a project which is designed to create materials for securing web applications. And they've actually got quite a lot of good stuff. They have a securing Ruby on Rails guide, which is also on Ruby guides. So that's worth looking at. I'll get past this. And onto this. You will never be secure. No system, no company will ever be secure. And there's kind of a good reason for that. The security industry has sold for many years this idea that you can do X and you'll be secure. By firewall and you'll be secure. By anti-virus and you'll be secure. By something, our new widget that goes in a box that goes in a rack and a server rack. And you will be secure. But basically if anyone ever tells you do X and you'll be secure, they're either very badly mistaken or they're just abbreviating because they don't think you'll understand. When someone says the system is secure, you know that they're not correct. They're maybe not lying, but they're not correct. And there's two reasons for that. They're missing out two parts of that statement. Who am I secure from? Who am I secure from? Because no system is secure against everything. You can have a brilliantly secured web application. I have two guys with guns walking through the front door and say, I'll be having that server. You're probably going to give it to them. So you're not secure against that. And the other thing, when someone says your system, my system is secure, my company is secure, my service is secure. Well, what do they mean by that? Do they mean the server it runs on? Do they mean that and the database server? Do they mean that and the underlying infrastructure services? Do they mean that and the admins' laptop? Do they mean that and the admins' home machine that he comes into to do administration at night? Do they mean the outsourced code suppliers security? What do they mean by that? So if anyone ever says my system is secure, then say no, you're not. And you can ask some more questions. So what I wanted to do with this talk to start with was go through a couple of ideas and techniques. When you're thinking about your security and you're thinking about what you're going to do and what you're going to spend your time on, because the other reason I wanted to give this talk is security people will try and say you have to do all this stuff, otherwise you won't be secure. And everyone knows you don't have enough time to do all this stuff. You know, no one in the world has that much time to do everything perfectly. So what do you focus on? It's actually quite a hard question and in a lot of cases security people don't address that very well. They'll just say it's all this stuff or nothing. Either you're secure or you're not. I respectfully disagree with that point. So the first part of the equation, as I said, is secure from who? Secure from who matters. If no one ever attacks your system, it doesn't actually matter if you don't spend anything on security. Literally. You just do nothing. If no one attacks it, who cares? Nothing's going to be exploited. So a brief digression. Safes. Safes are secure, aren't they? Big, huge steel boxes that you put all your money into. Has anyone heard of the Underwriters Lab? Okay. So the Underwriters Lab certifies safes. But they do not certify safes as saying this safe is secure. That safe is not secure. They certify safes by saying, how long will this safe resist attack by different types of tool? And how long, what areas of the safe can you attack? So can you attack just the front? Can you attack all six sides of the safe? And what type of tools can you use to do the attack? Now, you compare that. So that results in a rating compared to people saying their systems, they just say it's secure. They don't say it can resist attack from this type of attacker for this many minutes before he's lightly decayed. They just say it's secure. So that, to me, is perhaps a more realistic way of describing your security. Describe it as saying who people you're expecting to be attacked by and how long you expect to be able to resist the attack. So who is going to attack you? You know, as I said, if no one attacks you, all this stuff doesn't really matter. I was thinking about this. I was trying to think how to present it because security people spend a lot of different times wondering how to describe attackers. So I thought I'd go with this as a model and people can say whether it works or not. Okay, first off, we have automated opportunistic attacks. So an opportunistic attacker is someone who, they don't care whether they'd get your server, your system. They just want a system. They don't mind whose it is. They just want resources. Something of value, actually, not even necessarily resources, something of value. And if you've got something of value, then they'll go after it. So an automated, an example of this would be, I don't know how the Lisa Moon worm has been doing the rounds the last couple of months. So about 6,000 sites got taken out by an automated SQL injection attack. This guy wasn't targeting someone's service. He just wanted to put malware. And essentially what he did was he put an iframe onto the site that redirected anyone who went to visit it to some Windows spyware stuff. So all he was doing was looking to make money and he went out with an automated attack and he got 6,000 servers, not a bad return. And he's probably made a decent amount of cash out of that. And that's an automated attack. Basically, if you're on the internet, if your service is live on the internet, you will get automated opportunistic attackers just by the virtue of being there. If you're accessible, they'll attack you. So that's inevitable. So who attacks me? Those guys, every single time. Opportunistic manual attackers. This is, I suppose, how does it use the term? Script carry is perhaps the term I would use. So this is people who want to just get a website to something to face it, usually something to face it. And they'll do something like cross-set scripting or SQL injection. And what they're looking for is they're doing it for fame, profit, fun, whatever. But they're not, again, they're not really looking for you. They just want a site. And again, they might be doing it for resources. So they might want to do it for somewhere to store games, somewhere to store data for a period of time. You've got a nice, fat internet connection. They don't want to use their bandwidth. Great. I'll compromise your server. Directed automated attacks. And I'll kind of put directed. Directed attacks are a different game. So directed attacks is where you have something specifically that's sufficiently valuable that someone's going to take the time to target you. You just want you. And these guys, this kind of attack becomes a bit more interesting to defend against because they won't just come in through the front door. I'll talk a bit more about this. But essentially, these guys are more likely to be more versatile and they're likely to be harder to avoid. The kind of example is if you process credit card numbers. It's a great example. You're probably going to, if you do an lift volume anyway, you're going to get attacked. But other opportunities for being directed attack, if you control something of value to someone else. So if you control DNS infrastructure, if you control certificate infrastructure, so your certificate authority guaranteed you're going to get directed attacks these days. Because the ability to issue certificates is really valuable. Because if I can get this certificate for Google.com, then fantastic, I'm Google. Because most browsers don't know. There are 60 different certificate authorities in every browser which are trusted. Anyone who gets a Google certificate from those browsers will say, yep, you're Google. I'm happy that you're Google. And I'm just going to let you, I'll display the nice green bar. You're obviously Google. Fantastic. And skill levels. So in all this, the skill levels are variable. And this is what sometimes makes it hard. You get everything from someone who will put, or 1A equals 1 into every single field you've got on your site, all the way up to people who will code a zero day. And they'll use that zero day to attack you. Now, zero days are becoming more and more used in real life. And if you are up against really high level directed manual attacks, you pretty much have to guarantee they're going to try and do that. So this is a process where they'll do research and they'll find a previously unknown, or previously undisclosed security vulnerability. And then they'll use that to compromise you. And that's actually pretty hard to defend against. But it can be done. So, know your enemy. So opportunistic attackers, what we've said is they'll attack indiscriminately. They'll attack anybody. So you guarantee you're going to get attacked. They're just looking for resources. They don't really care whose. And sometimes they're looking for specific info. Yeah, so if you leave credit card information lying around, then they'll definitely look for that. And they're increasing complexity. So before it would just be a single attack. They might just do basic stuff that look at the version number of your web server and see if it's vulnerable to something and try and crack it. Now, SQL injection, they'll go much more up the application levels. And it could be curious users of your application. So sometimes users will try for either good reasons or bad to attack your app. It might be that they're just thinking, hey, I bet you any money if I put a single quote into that field something interesting will happen. Or it could be that they're annoyed with you. So one of the things I've seen on government sites is that people think, hey, my money's being wasted on this terrible government site. I'm going to prove how badly done it's been. And I'll go and find cross-excripting vulnerability. So no, your enemy. Two, directed attackers. So they're looking for something specific. Cardholder data, sensitive information, publicity for defacement. And I'll kind of draw this one as being, if you look at these three good examples, actually very handily for me, these three good examples in recent press. HB Gary got attacked. So HB Gary are a security company. And they made the perhaps dubious mistake of suggesting that they knew who the leaders of anonymous were and that they were going to disclose this at a conference. And anonymous took this rather badly and decided to attack first the best defense being a good offense. And they used two different means of leveraging this attack. One, they found a SQL injection and they got control of a server that way. So really classic web app attack. It's been around for 12 years now and is still one of the most used ways of compromising servers, which is a bit embarrassing really. And the other way they did it was social engineering. So they didn't bother with a technical attack. What they did was they faked some emails to come from the CEO. And they said, hi, I'm at this meeting with a client and I really need you to stop an SSH server on this port. And could you set the root password to be this? And the admin said, oh, my boss says I better do this. Right, okay, here you go. And they compromised their servers, they compromised their email archives, they compromised, and then they published it all. And when they published all this information, a lot of interesting things about what they'd been up to came to light. Like they were doing black ops against American journalists. Or they were proposing to the government that they would do black ops. There's no actual evidence that the government took them up on that offer. But they were proposing to do various dubious things. So they weren't attacked because they didn't think of value. They were attacked because someone didn't like what they were doing. So if you're doing anything which could be controversial or which there are groups who don't like what that site might do, then you have to expect that these people will at various levels of skill decide to attack you. The second example is RSA. Have you ever used a two-factor authentication token from RSA? These little key fobs. They're very common for using two-factor auth. RSA got broken into last month. And they still haven't said what the attackers got away with. They got away with something relevant to the RSA algorithm. And they've recommended that you boost up your pin token if you're using pin codes with your art. First, they said use pin tokens. And they said make them longer. Which implies they've got something of significance to how RSA tokens are secured. How did they break in? They didn't touch the external systems of RSA. They didn't touch their servers. They didn't touch their websites. They sent an email. They sent an email with an Excel spreadsheet to some low-level employees. Inside the email was a flash attachment. In the flash attachment was a zero-day attack. So they had an unprecedented disclose vulnerability in flash, which isn't that hard to find these days it would appear. And when someone opened it, it led to their systems being compromised. Once the attacker was inside, he seemed to have little difficulty in finding the information he wanted to get. So again, RSA were targeted because they had something of value. They had the algorithm which protects RSA tokens. Most people rely on RSA tokens for two-factor. Away they go. And the last one was, it's a little too very high. So they will attack other people, partners and staff. And the last one, which is a good one, was Komodo. Komodo are an issuer of SSL certificates. And they recently also got, actually they didn't get hacked. A partner got hacked. So it wasn't Komodo themselves. Their security wasn't compromised as far as I'm aware. But one of the people who does work with them, who was able to issue certificates on their behalf, was attacked again by a phishing email. So they phished the guy. They opened an attachment, compromised machine, you see where this is going. And they were able to issue themselves certificates from Google, from Microsoft and a couple other places. And the only reason this came to light was because a researcher was looking at Firefox's commits and said, hang on, why are you committing that these certificates are explicitly bad? Why are these certificates bad all of a sudden? And they said, ah, well, that's kind of because someone stole them. So in terms of, if you get directed attackers, it's worth thinking about that. Are you going to come under, and if you are, then it's worth thinking, hang on, I need to think about other stuff, rather than just my website security. It's not just about my security, my website, my web server. It's more about, who do I do business with? What about my staff? How do people get access to my systems? Because the bad guys have kind of worked out the directed attacks aren't always the best way to go. In fact, it's much easier to go and attack a workstation. You know, there's a lot more code there to be attacked. So people have flash installed, people have Java installed, people have a variety of pieces of code that have known vulnerabilities. So, they'll attack that. So what can they get to? This is the kind of, this goes with threat, threat model is kind of a fancy name, we're just saying, who's going to attack you? An attack surface is a fancy name for saying, what are they going to attack? What can they attack? The more they can attack, the more opportunities they've got. So, they can attack your network hardware. And this is the other part of the question. When I said, I'm secure, he said, well who's going to secure from who? And what do I mean by I? What do I mean by I'm secure? Is it your network hardware? Is it the operating system you run on? Web server? Yeah, it's probably in a scope. It's still relevant. Framework code? So people use Rails. If you use Rails, essentially you're relying on the security of Rails for the security application. If there's a vulnerability in Rails, then your app's vulnerable. By default, you're running on Rails. Is it the plugin code of the gems? So do you clone a GitHub repository and use that as part of your production code? Probably. So that's another place that, if someone finds a vulnerability, and they're especially the code's public, they may be able to find a vulnerability. If there's a commonly used gem, why wouldn't they attack that? The web app itself, that's the kind of obvious one. Support systems. So, everyone has systems which support their main services. They have admin systems. They have build servers. They've got various other bits and pieces that go with it. And each one of those is a valid target. And administrators' workstations. Like I said, the easiest way these days, compromise a workstation. You look at the client. If everyone is going to look at Metasploit as a project, so Metasploit's a hacking framework written in Ruby. They claim it's the biggest Ruby project in the world. I'm not sure if that's actually true. That's definitely their claim. And Metasploit, most of the exploits getting checked in at the moment are client-side. So they're taking client-side code, Java, Flash, whatever. So I had this idea, okay, so that's the general concepts. And I think if you're looking at your systems and your services and you want to think, how am I going to secure myself? It's worth thinking about who is going to attack me. And it's worth thinking about what can they attack? So, if it's just opportunistic attackers, there's some things here, which 10 minutes we'll see. But there's some things that you can maybe do quickly that will actually cut down the risk of you getting attacked. If you're getting attacked by direct attackers, to be honest, nothing that you're ever going to do in 10 minutes is going to help, but it isn't going to be the end of the game. Okay, so we're going to go through this lot. And I'll just crack on. Does everyone need to see your site? Well, yeah, we want everyone to see our cool site. We want everyone to use our service. But, okay, what if you're writing an app for a business-to-business application? So you're not writing it for customers, you're writing it for a specific company. Does everyone actually need to see that site? Does everyone need to be able to access it at an IP level, a web server level? Well, maybe not. So not everything needs to be universally accessible. B2B sites, sites accessed by a single company, sites with a specific geographic market. Maybe you're selling something that can only be consumed by a given country. So, GUIP, I mean, you'll see this from things like marketing. So you can market based on geographic identity because IP addresses are tend to be assigned on a region-by-region basis. So, what about restricting at a firewall level? What regions can see you? Or what companies? Ideally, what companies? I mean, if you can see, I'm selling to Acme Enterprises. Acme Enterprises have a public address range of this to this. A firewall rule, only people can get to the server or this to this. You just cut 99.99% of people to be able to attack your service directly. Maybe we'll have to get in some other way, but you've cut it down. And if you can't do it by company, do it by country. Again, if your service is UK only, for example, you might want to say only UK IP addresses. That's what I've done. We've got an administration server that's coming around. I just put that in as a... It took a little bit of time, Matt, about half a day maybe, even just to create a list, put it into the firewall. And because 99.99% of the time, we only ever come from the UK. So, great. And now, it isn't going to stop a directed attacker. So this will not stop directed. But it will stop opportunistic. And this is what I'm saying is, some security people will say, well, don't do that because it won't stop this class. Well, yeah, but it might stop these guys. And you might get away with it as a result. Reduce the number of opportunistic... And the other thing about reducing attack numbers, does anyone run like an IDS, or like OSSEC or anything like that on their servers? Okay, if you run OSSEC and you run it on a public server, you will see the attacks come through every single day. And you'll see lots of them. And to be honest with you, if you see enough alerts, you'll stop looking at them. If you can cut down the number of alerts you get, then the ones you do see, you can say, hang on, this is real. I actually need to do something about this. Whereas right now, if you're on the internet and you're just listening to the noise, then yeah. Okay, don't tell attackers things that can help them. So yeah, using security... Right, okay, so security through obscurity gets a really bad rap. People say, oh, that's just security through obscurity. You can't ever do that. That's a terrible idea. And so it's not bad. Just don't rely on it. Don't tell attackers things you can help them. So if I take it back to like lock and safe, kind of physical analogy, if you see it on keys, if you ever look in an office, you got all these locks on like the drawers that come under people's desks. They have a pattern number on them. And they'll say on them something like 7F3E. And if you know what type of lock it is and what pattern, you can go to the lock manufacturer and say, can I have pattern 7F for this lock? And they'll give you one. So leaving, for example, banners on web servers, it's kind of like leaving the pattern on your lock. You're telling everyone what version you're running. And if they know what version you're running... I'm sorry, I'm a pen tester. I do ethical hacking for a living. And the very first thing I'll do when I get a web server is I will get the headers. And I'll look at the headers and I'll say, right, you're running Apache version of this with these modules, version this, this, and this. Great, I'm going to go away to my vulnerability database. I'm going to look up that version and I'm going to see if there's an exploit. Then I'm going to look at my exploit database. And if there's an exploit, I'm going to use it. Great, excellent job done that I get to go home early. Don't tell people that. Because if you tell them... So if you hide it, yeah, remove banners, remove default pages, the other one. If it's really easy to work out what you're using, then it's really easy to attack it. If you take this stuff away, so there's two different things. One opportunistic attackers will just move on. So they don't care about you, they just want a server. So say, for example, I've got a zero-day and Apache version X. And I'm scanning around the Internet looking for this. If I don't get your version number at the very first attempt, I'll move on and I'll go to the next server. I won't come back to yours. So at the very least, it could be buying you some time for Apache to get a patch out. Or for IS to get a patch out, or for any other server to get a patch out. But if you don't tell them this stuff, then they can't use it. And the other thing is if it's a directed attacker, so today they really want you and you've hidden your banners. They may still be able to work out what you're using, but they'll have to be more noisy. They'll have to make more noise. They'll have to do more requests. So they might do timing. They might look for default pages. But they do the sort of thing that you could detect and react to. It makes them work harder. I think, yeah. So you might avoid all together being a target but not a opportunistic attack. Don't expose so... Yeah. So the most popular form of hacking is using stolen credentials. If I can get someone's username and password, I don't have to break into the system. I don't have to use a zero-day. I don't have to use an exploit. Keystroke logging malware is pretty common. If you've used machines that you don't know the provenance of, so you've logged in from somewhere, there's a reasonable chance they could have a keystroke logger on them and they'll have all your usernames and passwords. Common usernames and passwords are disappointingly still very common. You still see network chip with admin-admin. And the very first thing I do, again, you're doing a scan round. You find a web service for an administration interface. The very first thing you do is go look at the big long list there is a default usernames and passwords for that service. You try them. If you get one, great. Excellent. They get an easy day. And harvested from other site compromises. Does everyone use completely unique passwords on every single site they go to? Fantastic. Do you use a password safe to achieve that? Wow. So there's some really good memories in there. But if that's not the case, password safes. So one password, password safe itself, key pass, it's worth having different passwords for everything. Because if you're tall, can. Because if you've got the same password, say for example, there's been several big website compromises. So forums and various other places have been compromised. Gawker got compromised in their password database. So if you're an accountant Gawker, and you use the same username and password in other places, you can bet that someone went scanning around every single site for those usernames and passwords and tried to use them to break in. So if you use that for administration interface, happy days. You don't have to do anything fancy at all. So exposed down for admin interfaces are a great way to get access. Again, I don't have to attack the website if I can attack the admin interface. So if I can break into C-Panel or I can break into some other thing that you used to administer it, I don't actually have to attack the website at all. And I'll still get my goal, whatever that might be. So running on a non-standard port, another piece of obscurity that gets roundly slagged off, which I actually think is quite a good idea. If you're running SSH, don't run on 22. If you run on 22, all you will get is a huge amount of noise of people trying usernames and passwords trying to break in. And again, if you're doing intrusion detection, if you're trying to detect an attack and you're running on 22, then you will quickly turn that off because you will just have your logs filling up and your alerts filling up with all the things that attack. You put it on a different port, any port, much higher up. Then if someone starts hitting that port, you've got a fair bet it's a real attack and you can actually do something about it. It's a fair bet it's actually happening to you. It's not just some random noise on the internet. Again, source IP restrictions. Do you need to administer it from every country in the world? Do you need to administer it from China? Do you need to administer it from Australia? Do you need to administer it from Brazil? Probably not. Lock it down. And certificates. Yeah, certificate-based VPN, if you want to go really heavy, that's probably the way to go. Actually using something like Two Factor. Because admin interface is the key to the kingdom. If I'm getting an admin interface, I can get a hyper, there's a counter and admin interface. It's game over. Maybe you probably wanted to put a bit of effort into locking that down. Password management. Yeah, so use a password safe. Password safe, and this is another one where it's kind of a double-edged sword. So use a password safe and that's great. But if your password safe gets compromised, you're in trouble. So it's all about who you expect to attack you. If it's opportunistic guys, they're not going to come into your house and steal your password safe off your PC. If it's directed, they might do that. So it's who do you think is going to attack you as to which, what's the trade-off? Do I go with that or do I sexually hang on? I'm so paranoid because I'm going to get directed attack that I have a completely separate system which is not connected to the internet and I put my passwords there. Which, if you get directed attacks, might actually not be a bad idea. Limiting functionality. Yeah, every function is a point of attack. Everything you put up there is part of the attack surface. So some things are more dangerous than others. File upload is really dangerous. Doing file upload well is hard. There's a couple of reasons for that. If you allow file upload, how do you stop people uploading illegal stuff? Stuff that's going to get you in trouble with the law? That's quite difficult. How many money has YouTube spent stopping people? Obviously, that's their business model, so they're going to do it. If you don't have to, maybe don't do it. What's the stop some uploading malware? Great attack. I upload malware, then you look at it because for whatever reason the other person looks at it. Bingo executes and it looks like the site is coming from. Rich text entry is just hard for stopping cross-out scripting. If you allow HTML tags in your site, it makes stopping cross-out scripting really difficult. Really, really difficult. There's a couple of good cheat sheets out there on the internet which goes to the incredible depth with HTML5. You can go into vectors that you would never, ever think of in a million years or actually run executable code. So those two things are hard. We're thinking very carefully before you include them on your site. Yeah, certain type of data invites problems. Credit card data invites problems. If you want to Ryan's talk yesterday, you will know credit card data is poisonous. Do not allow it anywhere in your site because if you do, you'll have a whole lot of world of pain, both from regulators and from the bad guys because credit card data is worth money. It's not worth as much money as it used to be, but only because so much of it's been stolen. The price in the marketplace went down. And user personal information. If you're running a site in Europe, you nominally speaking have an obligation under the Data Protection Act or whatever European equivalent thereof to make sure it is handled in a secure way. And that's literally all they'll say. So what does that mean? I'll be honest and say no one knows. However, if you've got it and you store it, you must have seen the site. They go to a site, you try to register for the site and it asks everything about you. It wants your home address, it wants your date of birth and you just want to view the content. Why are they collecting it? I do probably make up fake data, but why are they collecting that? Because if they're collecting that and it gets compromised, they're in a world of pain from a regulator, from the legal standpoint. Think about it yourself. Another two-edged sword one, but I think relevant. Yeah, consider whether it's better to let someone else do this stuff for you. If it's not your core business, if it's not integral to what you're doing, then it's worth outsourcing. It's worth getting someone, you know, using a third-party module, using a third-party service provider, getting someone else to do it for you because then it's potentially not your problem. However, if you're going for a high-security level, you're running something where security is really kind of important to you, then the problem with outsourcing is how do you make sure they're doing the right thing? You just acquired yourself a new problem because it's really hard to certify security on systems. You'll see things I've never seen ever had anything to do with SaaS 70s. SaaS 70s is a data center. It's an American auditing standard, but basically all the data centers you use will say, oh yeah, we're SaaS 70 certified. It's completely meaningless. SaaS 70s are a company that comes up with a bunch of stuff where they say, this is what I say makes me secure. And the auditor says, yes, you're doing those things. Whether that actually is right or not is pretty arbitrary. So proving someone else's security is really hard. So if you're doing something high-security, outsourcing can be a bit of a hit-and-miss concept. So what can you outsource? You can outsource your platform. You're in the cloud. You're already doing it. You're essentially saying, Amazon, Google, whoever else, you take care of that piece for me. And I'm relying on you to do that thing for me. And if you're doing it right, if you're doing it fantastic, if you're doing it wrong, well, I'll find out the hard way. Authentication, you get gems to do it for you. Writing authentication can be hard. Writing crypto is even harder. The one thing I'll say almost always outsource, every single time is crypto code. Do not write your own crypto code. It's very, very, very hard to do correctly, and it's very easy to get wrong. So I would say almost always, unless you've got some really specialist requirement, don't write your own crypto code. Get a library. There are lots of them out there. And credit card processing, again, yeah. Credit card data is poison. Do not have it on your site. Yeah, and let frameworks do stuff for you. And this is the great thing about Rails. So Rails will do certain things for you, by default. It will do cross-out scripting, unless you turn it off. It'll do SQL injection as long as you don't write raw SQL. And it will do cross-out crest forgery as well, as long as you don't turn them off. But be aware of the stuff it doesn't do. So it doesn't do business logic. So say, for example, someone wants to go in and you've let them buy a product with a minus price. Rails isn't going to help you. Rails isn't going to help you with authorization problems. It's going to do certain stuff for you. So it's a question of knowing, these are the things that Rails does for me. This is the stuff I have to think about myself. Scan yourself. So, yeah, this won't replicate a manual attack. So as we've said before, you're thinking about who can attack you and what can be done to you. Simulating manual attacks is kind of hard without employing pentesters, because that's kind of what they're meant to do for you, although it's worth making sure they do the right stuff. Simulating authored attacks. Different attacks for different layers. And this is the other thing to realize about security scanners is it's not one-size-fits-all. So infrastructure. So I've got my servers and I've got my web servers and my database servers and everything else. There are free scanners. So you can use, I think, OpenVas, which is a free scanner. You can use NexPo's Community Edition, which is a free version of a commercial scanner. And what these will do for you is they will tend to say things like, I have a piece of software. You're running stuff with no issues. And that's the kind of information it'll give you. Also, if you let it log in, you can give it creds. They'll log into your servers and it'll say, these are the patches you're missing. These are common security errors you're making. The other thing that's really useful for it is if you do have compliance problems, so you're going to get audited, run these in advance if the guy's turning up, because A, it'll just make your life so much easier. The report will be a lot thinner. This is a good thing. It's the same thing. It's about $1,200 a license. So it's not free, but it's a year's license. And it's pretty good. You can use it to go around and actually scan all your servers. It will do something for web apps, but not as much as they might like to say, I personally wouldn't use it for web app scanning. So web app scanning. This is the other thing. As I've said, there are people going around and they will scan your site for SQL injection. They will scan your site for cross-out scripting. Yeah, there are free options. So Arachne is a Ruby project. And W3AF is a Python one. The same sort of idea. They'll scan your sites for looking for application-level issues. The thing I would say very strongly about these if you're planning to use them is, don't use them on your production system. Because the thing about, and we for a kind of funny reason, they'll go around and they'll fill every single form in. They're dumb. They'll spider your site like every URL, and then they'll go in and they'll fill in all the forms. And if you do it on a live system, they'll fill in the forms about 50 times, looking for different issues. So your site sends an email the time someone fills in a form, unless you want a really large number of emails on a production system and hold it up to people going, what have you done? Don't get a copy of the app. Run it there. Paid, Burp Suite. Burp Suite is a bit more of a pen testers tool, but it has a scanner with it, which is useful. And NetSparker is another paid-for commercial scanner, which is pretty good. NetSparker's party trick, actually, is if it finds SQL injection, it'll get a shell. So you just point at it. You go press button and you get a shell out of it, which is kind of nice. It also is quite nice for demos. You want to prove to someone, hey, look, this is bad. Look, I've got shell. Invest in detection. So this is not a 10-minute fix, but I wanted to talk about it. If you go back to my safe analogy, so I was talking before about safes, and I said that the certification of safe gets is I will resist attack for a certain period of time, say 15, 20, 30 minutes an hour. The idea about that is the fact that within the time that I'm going to take for you to break in, someone will respond and will actually do something about the attack. If you never find your main attack, bad guys can take weeks. Think spend months doing this stuff. In fact, there have been attacks where people do. There's a thing called the Verizon data breach report, which goes into stats from real incidents, genuine incidents. And they said in about, I think it was something like 90% of cases, there was data in the logs which would have disclosed that there was an attack ongoing. And yet, in about 60% of instances, the party was responsible for telling the company they'd been compromised. In a lot of cases, that was credit card information, credit card processor going, hey, you've been cracked, because we're seeing all your cards getting used. So the information is there, but it doesn't tend to get looked at. And this is why logging is kind of good. But yeah, back to the safe analogy. So an application level, so if you're writing an application, it's worth thinking, can I get my application to notice when something bad happens? Because something bad in a lot of cases can be kind of obvious. Someone starts trying to log in with random user IDs to your application from a single IP address. It's a fair bet they're trying to attack you. If someone's feeling likely known attack strings in two parameters on your app, so someone starts putting all one equals one into the fields in your app, or single quotes in every single field, or cross-excripting HTML tags, it's a fair bet you're under attack. At an application level, it's reasonably straightforward to actually say, hang on, if I see this repeatedly, this person's attacking me, do something like at the very least you could terminate their session. Kick him off. You'll annoy your pen testers no end if you do that, because that means they can't automate anything after that. They have to do it all manually. It's a real pain. But it's really useful. It's slowing attacker down, no end. Because if he's trying to do an automated attack, so it's one of these low-end automated attacks, you kick him out of their session all the time, or you blacklist their IP address, or for five, ten minutes, so not all the time, because you might get down on service that way, but blacklist them for a while. If you react to the tag, again, you've got a chance of stopping them, or at least detecting they're doing it. Feeding arbitrary, yeah, dated select fields. So if someone puts data into a field that's like an enumerated value, so you've got a field for country. Does someone start putting random strings in there? Guarantee you're being attacked. So great. It's easy to notice and easy to respond to. The other one with Rails apps, it's really kind of easy to notice. If someone starts looking for... Rails has got predictable structures, it's kind of easy because you know how everything's going to look. You know that there's all the controllers, and if I put one, that's the first ID, and if I put edit, that's editing that user. If someone starts hitting those URLs in that fashion, then you've not exposed them deliberately. It's a fair bet you're under attack. And if you notice that sort of stuff and react to it, you can make the attackers life more difficult, because none of this is about do this and you're safe. Do this and you're safe, do that and you're safe, do anything and you're safe. It's all about putting little barriers in the way of attackers to make their life more difficult and down to give you time to stop them, or to give you time to notice and do something else. If you don't... If someone just attacks your app and can sit there for six months trying to work out how to break in, if there's anything, they're going to find it. So, and one more thing I want to talk about for questions, which is compliance. If you have compliance, then kind of disregard everything I just said, because basically do what the compliance says, because compliance isn't reasonable and compliance isn't risk-based. It tends just to be do this stuff. And I was in Ryan's talk yesterday about PCI and the weird part in the security industry if you were in that talk, is PCI is considered the most exacting and most precise and detailed standard in the security industry. Most of them tend to go as far as saying, do good stuff. And if you don't do good stuff, a regulator or a government will come and slap you for it at later date. But they won't tell you anything more, so PCI is as good as it gets. So if anyone's got any other ones like HIPAA or SOX or any of these other things, they're worse than PCI. If you don't get anything that says, this is a SOX project, run away really quickly. Because auditors got to define, basically the big four audit firms got to define what good meant in that world. What that meant was they got to do lots of auditing work for very large amounts of money. Questions? Yeah. So hopefully not. So the Pentage company should never disclose anything about the customers they do work for under any circumstances. So no from that perspective. What I'm expecting for me is if you get someone in to do it, don't just say do a pentest. Do the thinking I was talking about about who's attacking me, and what do I think is going to get attacked before you get the pentester in. Because one of the problems I have when I do the work is people say do a pentest. What does that mean? You'll give them like four days, five days. So you want to get them on to the type of attack you're expecting to experience and the type of scope that you're expecting to look at. They should find level 11 stuff and if they're good guys and you give them enough time and enough scope, they'll find better stuff as well. So Rails, in a way, Rails really helps because Rails takes a lot of the weight off your mind in terms of things like cross-out scripting. The fault is it's good. The only thing I would say about Rails is the predictable aspect. Rails values convention over configuration so the conventions can be used by an attacker. He can say I know where, because there's a lot of apps. Have you ever seen some of the old Java apps? They've got URL strings as long as this. It's an impossible task, definitely in a short space of time. With Rails, I know exactly where all the other actions are. I could, for example, easily probe for common controller names. I could probe for common... any common patterns that I expect to find. So, for example, using gems for authentication, you might know where those are going to be. It makes the attacker's life even in terms of discovering and it also means that with a Rails app you have to be very good at authentication because you can't rely on someone not finding it because they probably are going to find it. I think it's challenging about Rails apps because we can move so fast that as soon as you have a test done you can deploy a feature which needs to be tested and then two days later or two hours later you can deploy another feature which needs to be tested. Is there anything that helps to deal with that? I don't... There's some tools that will do software as a service scanning. So there's people like Qualis who will do... but the question then comes back to how good are they going to be at finding the kind of issues in a specific to a Rails app. They have to be in the same way as automated scanners. They're looking for certain patterns and if they're not used to the patterns in your app they may not find what you're looking for but they'll do a good job of saying this is what other people with scanners are going to find. So essentially you can think of them saying this will take you as far as other scanners. I've often thought that there's something to do and I haven't really looked into it with the idea of testing and Rails and then using TDD for things like cross-out scripting and SQL injection. So you could describe what a cross-out scripting is and respond to it. That'll get you somewhere anyway. It would count some of the cases. So software as a service stuff I don't think there's anything else or running scanners back over it. You start seeing stuff and I don't know if it will work for Rails but there's tools like Fortify which come from the Java world where they are code scanners so they're source code analysis tools and they take it from the white box perspective so they look at the code and look for badness there and that's the process. So every build this runs and then the person's build either gets rejected if you want to or gets flagged to say hey, you had problems in this build so every time you commit code essentially it'll do some checks. And I've seen some people say that the best way to do it is just do something, build up a list of things which are bad and check for that on every commit and say so using this library is bad so certain known libraries are bad or if you're doing things like opening files that's dangerous. That's the way to approach it. On that, the one thing that turns out to be quite difficult is where apps start making more heavy use of JavaScript things like spiders start falling down so the common technique for all scanners is they will spider your site to find resources and then they will test those resources. If you're starting using things like well if you look at Twitter or Facebook as an example and they're using the hash band syntax a spider's going to look at that and say that's a comment. So everything after the hash is a comment that's standard URL syntax which we obviously would just completely fail. I'm actually not sure, I've not seen any scanners actually deal with that concept well yet. It's probably not widespread enough to make it relevant but in time it obviously will be. Anyone else? Cool, thanks very much.