 Okay, we'll get started again now. One quick announcement. Someone left a laptop power supply behind somewhere in the middle, near the back. If you're missing your power supply and you can tell us what it's like, come down and see us and we can return it, otherwise it's going to lose property. We have a winner. Okay, we'll get started. This is Mark Suter speaking about lazy management of a secure gateway. Okay, so, is this Mark good? Yeah, have you guys been just looking at me blankly? No. As for the slide, Mark Suter, I look after a fairly sizeable gateway from one of the members of the team. I like questions as we go, but that's me. That's the thing you would have seen in the mini-com thing. I put it here so I remember it myself. Obviously, I'm lazy, so I just took the default. So laziness, if you heard my talk last year, same definition of lazy. It's a very practical definition, minimizing work, but with a slightly larger view than just today. We try to do this. Sometimes expediency gets in the way and we end up doing more work for ourselves, but this is an ideal secure gateway. That piece of paper there is actually the current one. If anyone has last year's slides, you can actually get that out of the presentation and it's readable. It takes a fair bit of work to get that piece of paper and it has fairly big contractual obligations for us. If we don't get it, we basically lose our contract. The network we have is still modeled on the soft chewy center model. So we have soft chewy center with nice vulnerable hosts run by people who use the root password of blank, but we have a gateway between them and everything else. So we are obviously slowly having to realize that that's no longer the case, but it's still because government gets to be slow. It still is a gateway. It still is the big bad firewall between you and the internet. Those last two acronyms down the bottom, or the IRAP-1 is actually the process by which you get that piece of paper. PSM and ISM are lovely acronyms if you're in government. If you're not, they're basically just a waste of time. PCIS is similar if you don't deal with credit cards. It's a nice waste of time. They are useful to read to see what the other people think you need to do. It's often interesting to compare the credit card standard with the DSDs, the ISM, and to see that, hey, the credit card guys don't let us use that, but the DSD does. It pretty much means the DSD will stop letting us use that very shortly. That's the two-second picture of our gateway, or one of them anyway. There are actually four gateways we have to look after, so it does get a bit of fun. Instead of having one firewall, we have almost, well, almost 200 real pieces of kit, and if you add up all the little bits, it's well over 200 pieces of kit that effectively, if it all works well, becomes the same as a Ethernet fiber. Just a single Ethernet cable would do the same job if everything worked well. We do have, as it says there, lots of single point stuff we have to try and do in that. It looks very complicated, but we try and make it look like a single point. That does create a fair bit of work for us, but ultimately, that's what we're going to pay for. Pretty much a grab bag. Most people shouldn't have any real shocks on that list. The drop box there is actually a fair bit of fun. It ends up being a huge sink of time. Web browser is pretty much easy. I'll get into that next email DNS. They're all pretty easy. We spend most of our time on those last three. The top three we've been very lazy with, and in the sense of this talk's definition of lazy, we don't spend much time doing with DNS or web or email. Email may be because users are involved more than in email than any other system, but they actually consume far less time than the far more specific things down the bottom that we haven't been able to be that lazy on yet, if that makes any sense. In order to provide those common services and everything else, huge grab bag of skills, which makes it quite hard to be lazy, we have a team that's now around 10, depending on how you count it, which day of the week. You can consider people in it or not. We have a big team looking after our client of which we're only a small part, so you can easily count more people in the team doing what I have to do than you would otherwise if it was just 10 people. So you could easily say it's 30 people, but it does give us quite a large range of things to do. We have to be quite usefully across most things, so you end up being lazy in the way of kiss. I won't expand that acronym, but simplicity is involved. It is a very big deal. You can sometimes find solutions that look attractive, that have these really cool advantages, but they end up being more work than they're worth for the benefit you get. So our laziness does come into, no, that's not worth the effort here. And sometimes it's, no, that's the simple solution, isn't good enough because it has other side effects. It's always a juggling act. It never changes in that respect. The last one is actually a huge amount of work, as I mentioned earlier. We have a piece of paper, actually we have a page in the wiki. We have a page in the wiki which says that when someone leaves, we will change passwords because they've left. Now, this isn't a mind-blowingly complex process. The person who knew all the passwords, because they worked here, has left, so we have to change them. Part of what makes certification so much fun is you need a piece of paper that says that. So yes, I tie my shoelaces. Can you prove it? We'll look at my shoelaces. No, no, no. We need a piece of paper that tells us that you indeed follow the process that will ensure that your shoelaces are tied. A lot of certification is that. There's a lot of value in checklists. Have I done A, B, C, D, E, F, G down to Z and Z 55. As quite a few people have mentioned today, some of the most spectacular security issues come from misconfigurations. People forgot to do the last step that if you ask them to rattle off the top of their head, what do you do when you finish installing such a server? They say, oh, by the way, you have to set the default password. Change it. But they forgot. So certification is often about following big checklists. And so when we say secure gateway, if you try to have that, nothing's secure. I mean, we can have the entire story. I could spend another 50 minutes talking about the definition of security and how no one is. It's all about a level of assurance, trying to get to a point where you're comfortable with what you're doing and that comfort isn't misplaced. It's all too easy to be complacent. It's all too easy to be arrogant. I've certainly done both at various times. But we hope that by following a lot of these checklists, by making sure that we continually ask for opinion, we try not to get away from that. And the certification is a nice piece of paper that gives us money. So anyone not understand that lame attempt in Inkscape, I can skip it. Everyone understands what I'm trying to say in that little animation, no, not animation thing. We love documentation. And hopefully the more I can avoid the people asking me questions, the better. This is probably one of the best things we've done where I am to do with avoiding work. Our client has access to our monitor. We've got Nagios. Our client, particular trusted members of our client, not the entire population, but they have access to the same Nagios we use. They have access to the same Cacti we use. They have access to the read-only admin interfaces on a lot of our appliances. So they don't ask us the stupid questions. We're not trying to stand between them and the environment. It does come with some big risks, the obvious one being you can't hide too many problems. But so far we haven't had too many of those that the client has blamed us for. And that really does help because if you pretend that everything's perfect when it's not, you'll get away with it. I mean, you can probably insert the name of large companies that try to do that. I won't name any, but it's easier to simply own up. Like the absolute worst situation you can be in is having to come to someone and say, you know, a month ago when you asked us whether there was something off, it actually was off, but we didn't tell you that. We don't have that problem. We actually have one scenario I can give you an example of. We had a particular device in our environment that for various reasons couldn't support a particular type of ankle. We wanted to just throw a couple hundred IPs on it and say, block those. The devices in question couldn't do it. We actually got the client to agree to go halves with us to replace them with different equipment. And that would have cost us a lot of money. The client agreed to pay halves. We end up with a much better result, and the client trusts us when we come and say, hey, this needs to be done. And they don't go looking for a blame game. They don't go looking for, wasn't that your fault? Shouldn't you have fixed it? The link documents I put up there, each partner that our client talks to, we have a single page that says all the firewall rules that are engaged, all the services that are happening, all the contacts, everything to do with that link. Some of them for other government agencies, bigger than us, those documents are available to the client. We've had the client come to us and say, we used your link document to have a series of meetings with the other agency. We've now got to the point where we want to do blah. Can you come in on the design stage? They've already spent three months covering off who's going to pay for watts and when's this project going to work and it's going to fit in with you. All of that because we are open both ways. We trust them to do their side of the show and they trust us that they'll get our input early without having to have us deal with, you know, into government stuff. We are a commercial provider. We don't really care about how governments have to talk to other government departments. Likewise, they don't particularly care about the design, the technical details. They want us to talk to them. In some cases, it's literally the two government bodies talk to each other and then they eventually agree to let the two outsourcers talk to each other. We had the situation where by the time we got involved, it was pure technical, you know, the objectives had been set, we'd been told what they were, they were reasonable and by the time we got involved, the other outsourcer had already spent three months just mucking around trying to deal with all the intergovernment nonsense that we didn't care about. We simply got caught into the last bit incredibly lazy. From our point of view, we saved a huge amount of effort by putting the openness effort in up front. It really does help. And that last point, the one about unneeded secrecy, secrecy is basically half of our game. Keeping things confidential isn't news to us, but we do try often to go around, to not go around, that's the wrong word, I should never say that, but we do try to make sure that when we do have something confidential, secret, whatever, they're both formal classification labels. But when we try to keep something not known, we try to make sure we're doing it for the right reason. We try to avoid the culture of you can't know that because you're not us. It does save a lot of time in the long run. Firewall rulesets, strangely enough, gateways, secure gateways, firewalls seem to be the vogue have been for quite some time. We have three levels, if you will, of documents. We have the live rules, by which I mean the firewall rules on the actual firewall. So you bring up the management console of the GUI or the command line, whatever it may be. You do a show, run on a Cisco, whatever. They're the actual rules that are running right now. We then have various exports which are checked in a subversion and are reviewed by our web portal. We give our client access to that subversion portal so they can see the live rules and they can look at diffs and so forth. And then finally the B2B documents and quite a few other documents, the official what's meant to be there and the last two should always match but if they don't, our client gets to rob us of it and we have a very open, friendly environment where they'll say, you haven't updated your docker yet. It's quite a huge time saver. I probably won't need to go into this too much except to elaborate on the last point. We have way too much NAT. This is one of those cases where we haven't been able to be lazy. We've had quite a few things foisted onto us where we NAT between 10 subnets to 10 subnets to 10 subnets. We have one MQ channel, basically a TCP connection where there are five IP addresses involved in a single TCP connection. There are, and it makes tech support a huge amount of fun because someone tells you an IP address and you go, that's not my IP address. But it is. It's somewhere deep inside their network. Documenting that is probably the only way we can save time. We've tried quite a few times and this is one of those things where we end up being lazy by simply accepting it as it is. As much as we want to clean things up, as much as we'd like to have a nice, clean, logical, open, no NAT-involved network, we've got enough public address space. I could give public address space out and have no NAT but I can't because the various agencies it's not worth the fight and that's again a part of our laziness. We know when, well, we think we know and so far we haven't screwed up too much when to fight and when not to fight. So that's, as with everything. I mentioned the Blue Coats, or the web browser at least. We pretty much have, this is one of those things, we use a lot of free software. We have a lot like Cacti and Agios. They're pretty much bread and butter. But Blue Coats, they're, if you go to bluecoat.com, they're one of the massive companies that makes appliances that do web proxying. Our policy is very, very dumb from the point of view of the client. We have a rule which says if the Blue Coat thing says it's in the pornography category, it's blocked. If the Blue Coat thing says it's in the business category, it's not blocked. We just use the gross categories and don't do anything else. Every so often the client comes to us and says, oh, but this particular site is blocked, it's not blocked, and they complain. We've so far managed to never have to with only a couple of exceptions. The second most senior public servant likes footy tipping. So footy tipping sites are white listed. But apart from that, we've had very few exceptions and laziness in the sense that you have these very powerful appliances that can do a huge amount of stuff. We've used only a small portion of what they're capable of because we're lazy. In email, we almost do exactly the same thing. One of the reasons why we use these particular appliances is because they do give us a very lazy gooey. We have a big cluster of them spread across multiple sites. Users log into their anti-spam thing. The end users have quite a bit of access to the stuff. We haven't had to do anything, and it makes email a thing we just tick. The most we ever have to do with email is investigate when someone particularly important thinks something went wrong, which almost invariably ends up being explaining to someone how the internet works or more to the point doesn't. It's much easier to say, well, if an individual email arrives, count that as a place of great occasion and rejoicing because it did arrive. We can tell you everything could go wrong. Most of us in the room could do that. Pretty little graph. See the red line and the green line? The red stuff's what we reject. We don't even bother talking to you. Anyone who's running any sort of mail server with blocking based on IP addresses, however you do it, we use a commercial reputation service, but they're all quite functionally similar. We block a hell of a lot more than we ever talked to. It's scary how much malware and ill intent is writing around on the internet, like the SIP thing. You could probably have half your bandwidth, I imagine. In a tax if you were small enough. One scary one is passwords. We have a huge number of different types of devices. At one point we've started becoming a bit more lazy and rationalizing, but at one point if there was a vendor that you were allowed to use in a government gateway for a firewall, we had it. So we literally had, give us one of everything. It wasn't so much deliberately by choice. It was more that things had been added and different firewalls had different capabilities in their official lists that we're allowed to use. We've done a bit of rationalization, but we do have the problem of passwords and our solution so far has been a keep us file. Nothing particularly interesting there except we have the nice trust zone problem. So we have different firewalls. You can't have the same password on them. It does make things a fair bit complex. And this is one of those cases where we're not allowed to be as lazy as I'd like. I don't think I need to explain Nagios and Cacti. Anyone not you familiar with NetFlow? It's probably just a buzzword to think about. NetFlow is really cool. Most of your network devices can send effectively summaries. So they'll say, I just saw 10,000 packets, but hey, it's a TCP connection between here and here, so many bytes. That sort of information is incredibly useful. Three quick product names. Sourcefire. We do have one of those fancy IPSs. It's a rule you're supposed to have them. But Sourcefire is actually pretty cool. It is based on Snort, the free software, Beast, and effective what you're paying for as a management GUI, plus a lot of pattern updates. SyslogNG is awesome, in particular when you write your logs to where they're going to stay forever. It actually solves quite a few problems in the sense that you can get Syslog to do your checksumming, but you can also get it to say, that's where the file was originally written. We haven't changed it. And I could probably do an entire day on ArcSight. It's a massive product. We're not using it enough because we're perhaps lazy in the wrong way. The last thing I'll leave you with, if anyone recalls Lyme from last year, it basically just had the thing in the top left. Lyme is a little tool we have at work that allows us to look up users. In the year since I gave the presentation a five minute, it now has quite a bit more added. The thing on that side shows every time you've rung and spoken to the service desk and every time they've opened an incident for you and what hardware you've got. This is a very good example of laziness. I've spent quite a bit of time maintaining this tool. It has saved us weeks of time every month in looking up tickets and like literally you type in, say for example someone's phone number and you've automatically got that screen. You type in their job number, you type in their surname, you type in the group they're in. You very quickly get to that and in terms of software, making it work properly has been a very good investment in laziness if that makes any sense. Or zero or one.