 I'm here to touch about PCI DSS in a way that's hopefully not going to bore the crap out of you. So, get on with it. Find me on Twitter, I'm sad here talking about PCI because in my last job I had the wonderful honour of getting us compliant as a PCI level one service provider and all the bells and whistles and hoops and compliance nightmare that that involved and hard work. So, hopefully I'll explain something that's relevant to what most of the people here will probably be doing without going to overboard into detail. I ramble a lot so stop me at any time if you've got questions and I'll try and keep to the time. PCI DSS is a security standard for looking after card data like card numbers, folks' names, addresses, all of that stuff that Visa, Emacs, Mastercard, Diners Club and JCB came up with together to make sure that people weren't running off with your card information and running up a lot of bills. They've decided that everybody needs to comply with this massive document and it's very, very complicated but if you plan at it, know what you're needing to achieve and isolate your areas. You can defeat it with a bit of common sense and some good planning. If you're doing something complicated it can get quite expensive because you need to hire auditors and everything else to come in and work on your stuff and they're not cheap and you can't ignore it so there's no escaping from what you need to do at least something. So, I'll talk about the minimum that hopefully will apply to a lot of people here and the worst it will get for most of the people here. So, I'm specifically going to talk about the self-assessment kind of compliance where you fill out a questionnaire and then sign it to say you're PCI compliant and it's almost as straightforward as it sounds which is good. I'll tell you the things you need to worry about, where it gets a bit annoying, some quick wins you can have and where the bear traps are because there's quite a few and I'll talk a bit about login and that gets a section to its own because it's horrendous. So, yeah, self-assessment, what happened there? The self-assessment compliance is for small traders who are taking payments usually online in this case and are not putting through a certain volume or value transaction so that you're able to just tick a few boxes to make sure you're meeting a lot of criteria. You don't need an auditor on site to self-assess your PCI compliance in this case, you just need to fill it out and file it with your employer or your bank or sage paper, whoever's asking you to do it. The two I'm going to talk about are A, the basic one and C, the not so basic one. There are others but these two specifically relate to doing things online so they're probably most relevant to folk here. Hi, SQA, I don't have much to say about because it's the most straightforward. If you outsource everything you do to do with cars so take payments by PayPal, you email someone a PayPal link and they pay you or you redirect someone straight to PayPal and they're entering all their information there. You really don't need to do anything more than that, you just need to download the form, answer 13 questions where you tick yes and then sign the bottom. What you're attaching to there is that PayPal have all the risk and you're happy for them to have it and that's really all there is to it for that case, it's really straightforward, there's not much to do. For C, if you're using something like Active Merchant where you're having card information submitted to your site, your servers or whatever, you're doing some processing at your end and then sending it off from your machine. You're not storing it, but you're handling it and then passing it on to your payment gateway, whoever they are, then you need to be compliant with SEQC and there's 80 questions rather than 13 and they cover most of the PCI spec. So it's quite in depth, not as in depth as a whole thing, but there's a lot of work to do, so there's a lot of documentation, there's a lot of technical work and there's a lot of policy documentation you need to write and make sure people are following, which is the killer. It's for most of the people here as bad as it will get, so if you're able to sort this out you're probably going to be on to a good thing. So for as a developer, what you really need to worry about for the assessment questionnaire A is nothing at all because you don't need to do anything. For C, it's a lot more difficult. You have to have policy around how you're doing your development practices. You need to have the best guidelines to hand for data security, for application security. You have to have a good knowledge of that and you have to have an organisational level written documentation so this is what you're adhering to and you need to then prove that you're following that for going on. Things like if you're doing web applications, O-Wash, the open web application security project, their guidelines are top 10 risks and all that, you need to know that. It's good to know and if you build with that in mind you'll make sure you've got everything secure as you can, so if you need to do more compliance work further down the line it saves you work. I'll be coming back to some of this stuff later, but for a developer it's like you're going to be writing more code, you're going to be testing your code more vigorously and you're going to have to do a lot more documentation for what you're writing. That's the things you need to worry about. Is this admin? You've got nothing to worry about for A. For C, you've got a lot more footearing around with the services on your machines to do. You've got to do a lot more nonsense with your network so demilitarise zones, firewalls at various levels, going through killing any service you don't need, hardening the thing more than you think, you need to avoid doing things like automatically updating packages because you need to hold them back and test them now and things that's in some places a lot of enthrange behaviour that you just get used to doing you need to not do anymore. So there's some unlearning to do and a lot of graphic evolving and getting that working, but once you're set up and you've got your card date environment all nice, set up and configured and working, it's not too bad and it'll come back to the networking stuff briefly as well. As a business, as a whole, it's fairly cut and dry. If you're not compliant then at the very worst it can be decided that you're not allowed to have people pay you by card anymore which, if that's your only way of getting money in, is quite a big deal as a nine-year speaker. There's a lot of procedural and policy documentation that you need to write and as a business you need to make sure that your staff are following for all the people and make sure that you've got the appropriate roles and responsibilities involved clearly defined so that everybody knows what you're doing and you need and must be PCI compliant. So if you're doing anything that involves paying by card you need to do this. And if you don't, well you might not get paid by card, you could be fined as well depending on what you're doing, who your bank is, how grouchy they are. It's really, really not all that cut and dry and the whole thing is left deliberately vague to have an industry QSAs to tell you what to do for £3,000 a day. I'm gorgeous so far. There's some quick questions. Go for A if you don't have to, fairly no brainer. If you don't need to have all that much control over how people give you money and you just are happy for them to do it, go down the A route, A route, we direct them to a SAHP portal to PayPal to whatever it is you've got, let them have all the trouble and bounce you back because then you don't really need to do all that much more work. If you're putting through a lot more volume than most people do or you're needing to control the entire billing experience for your customers, your clients or whatever, you're going to need to go down the C route. And at that point you need to do a bit more of a trade-off between the extra work involved and the benefit to your business with regards to the extra effort you're going to need to put in. If you can outsource everything so that you don't need to worry about it, so at the end of the day your own product or service is core to what you're doing. The PCI is something you need to do but it's not necessarily something that you need to do yourself and there's plenty of folk out there that do it. So if the cost that you're doing it, taking people off is prohibitive or whatever, get somebody else to do it. The bear traps are largely around the logging in that and I'll come to it later. The rules around logging to make sure you've got a good audit trail from not just people using your application and paying for things specifically around the SCQC but access to the system. Some things are happening on your system between people deploying your application, everything around that has to be logged, your logs have to be logged and it gets kind of circular in its reasoning and it's really hairy to unpick. If you've got a tiny team and you need to do the SCQC, you still need to separate roles and responsibilities and if you've got two people and you've got four roles it's not necessarily going to be all that good to split things up. There's exceptions you can raise but when you're, I'll talk more about that later actually, you need to pay every quarter for your network to be scanned for vulnerabilities by a PCI certified or made scanned vendor. That needs to happen and depending on what you're doing, every time you make a change to your network you also have to arrange for an internal and external penetration test to be happened. To be carried out by a qualified person, which is surprising when you think about it but mandated in the spec which is, yeah, and anything above it. Sorry, when I went on from A, nothing to worry about, this is all C and beyond that. Likewise you need to then have documented change control procedures and management procedures for everything you're doing. So if you're doing any bit of work that changes your, how you're dealing with card information or anything that interacts with it, you need to have a documented and enforced change management policy that does a risk assessment of the work you're carrying out, a back-up strategy and post and pre-deployment plans for testing and for rolling back. So if it all goes wrong you can get back to where you were. If you're already doing that, great. If you're already certified as ISO 9000 or whatever, you've probably already got something that's overkill in place for that so you don't need to change anything. But that's about it. The big deal around that is it does generate and I found a lot of extra paperwork I had. Once we were PCI compliant in a month I had about 100 change requests for tiny little things that fell into scope of what we were doing. So it gets very, very noisy and it's something to consider if you can eventually become a burden to changing things and not all that handy going forward but you need to keep it in mind that you need to do it. Your card data area also needs to be protected against intrusion and unauthorised access, modification to your files, your application itself. So you need to have as well as firewalls everywhere. Something like a file integrity monitoring tool sitting on your system. I've highlighted us at there because it's currently my pet love project which does intrusion detection for you. It monitors files for changes and the lecture through Cislog through email and a bunch of other nifty things that you can easily aggregate when something goes wrong so that you've got a good audible list of what's going on so that you can then go and act on it. For intrusion detection you might get away with your file if it's a decent one. So the big Cisco ones that Raxquakes have, they're usually good enough. The logging is very, very, very complicated and I'm really sucking at explaining this but essentially any change that happens on your card data environment needs to be logged. You need to have in a file somewhere what's happened, who did it and where. To the point where when logs are created you need to have a log that tracks the creation and deletion of movement of your logs, which is where it gets a bit of a situation to log that and then back. You need to aggregate them centrally. You need to protect them against modification. You need to preferably have them off site as well. I'm skimming through a lot of stuff here. One of the things I should have said at the start is what the Security Council say is even though you're filling out the SAQs you still need to read the entire spec, which is their get out of jail free thing for you ticking the 20 points and then going through it. So you need to keep six months on hand off your logs so you can access them and if I'm remembering rightly two or more years worth of logs in an archive so that you can bring them back to find out what's going on. They have to be audited regularly for unexpected behaviour and changes. The person who's got access to the logs has to be, no he doesn't, logs need to be audited every so often. You need to be able to have full back up in the store off your logs. You need to rotate them quite often. We managed to get this working with RSS logs and some horrible configuration we do to pull everything down, going through all the firewalls, coming down, backing it up and going back up. So you can do this with free software or you can go to one of the hundreds of vendors that will give you a black box you can plug in to do it for you. For the networking side of things it's all about isolating your risk area where all the card data is. In an ideal world you want to have a big black box where all the card stuff happens that you don't want to touch. And you want firewall surrounding it so that nothing can get in. You're only allowing specific traffic in and out from specific places. It's all good, the server security stuff anyway that hopefully folk are already doing, but your box can't have access to the internet apart from thing that needs to for updates. You can only talk to specific points on your network that you need for audit and remote log in access. You have to push up, you can't get a shell up until files down from it. It's quite good if you've got a firewall which you will have to have every quarter you need to audit your firewall rules to make sure it's not being changed, document them and file them away somewhere safe. Every time you make a network change you need to have said before a penetration test done internally and externally to make sure you've not left the barn door open. This is kind of the last bit and I've really rushed through this. VMS virtual machines on servers are fine for PCI compliance now. They used to be a bit swiffy about it and the spec read as if you needed to have a physical bit of hardware for each individual function that you wanted to perform within your card data environment. Now you don't, you're okay to use virtual machines for it. You're okay to share services on the same machine so the spec says you need to have one primary function per server and if you're reading that you can take that to mean that you can only have a time server, a DNS server and a web server. But primary function is more to do with the application server so that could be doing your application so running four different services to provide that application. So it's wooly but not all that bad if you apply some common sense rather than looking at the letter of it and being really, really literal because that's how you end up spending thousands and thousands of pounds rather than what you need to get going. Before you start up you want to audit exactly where your card data is coming from so how you're getting paid, where you're getting paid, all the places that comes in, write it all down and then figure out a way to cut it entirely with what you're doing and put it somewhere else and then plug it in later. So if you do that cut out and then build around a consolidate in one place it's easier to make that one tiny bit compliant than to just fix something that's got fingers going everywhere. In doubt about anything there's loads of resources online, the PCI website is actually pretty good. They've got a lot of explanatory documentation up there and they'll list the QSAs that you can hire for a day for a pound of flesh to help you with what you're doing. Fragement of hiring, any questions? Yes, Ollie. If you're storing the details you need to comply with D which is pretty much all of PCI DSS. It's one of those weird things that your agreement for processing card payments especially if you've got a proper merchant account is between you and your bank. My understanding of it is you've under your contract with the bank you've got a responsibility to make sure you're keeping everything safe and secure. They'll do their bit, you have to do yours and if you're not doing yours which means if you're not being PCI compliant because they get that in there then they have the ability to raise penalties. Usually what they do is they'll just suspend your card processing which is a lot more hurtful. The fines are kind of squiffy here. They're mentioned in the spec and they're mentioned all over the PCI website because they get that in America. Like TG Max, they got fined. A bunch of other people with really serious breaches and the fines worked out to be a slap and a risk for these multinational sort of like 10 million for a company making billions. It's not all that big a deal. That's a really good question. It depends, it doesn't depend, from a PCI point of view it doesn't matter where you are, you need to comply. It's a worldwide thing. So all the payment card brands are worldwide and all of them everywhere say you need to be PCI compliant. I don't ask me to elaborate so I can't remember off the top of my head but I know there are other countries that have got rules above and beyond PCI for dealing with certain information. And depending on what you've taken payment for in the UK or in Europe, there's other regulations and laws that you need to comply with here too. Like for dealing with government data or that sort of thing. That's exactly it. It's purely there to shift responsibility from banks to you as a company and they've got enough vagaries in there to string it by the balls if they want to. It's down to the QSA that they want you to hire to decide if you're following best practices or not. If you're doing the self-assessment thing, you as a business should know what your best practices are and you should know if your staff are following them. So it's more about an organisational thing rather than specific nebulous, happy, crappy best but that could be anything. What regulators decide who will act on that? First thing, all of them need to comply with PCI DSS and there's no regulators as such but they're acquiring banks and the people who are doing the payment processing for them are supposed to be chasing after people about it. And you'll see it more with companies like SagePay and a couple others are charging you extra to make sure that you are PCI compliant when you're filling out the account. Just opening up a new account with them and making it easier for you to do it but generally it's the banks that are enforcing it. Maybe they'll offer us that in the US and then you have you. That comes down to the different kinds of self-assessment. If you are outsourcing all the payment stuff, so if you've got a form on your webpage, you key in your card number and you hit submit and that's going to chargeify or it's going to authorize.net or whatever and not touching your servers at all, then you need to be certified in the SEQA which means ticking 13 boxes and signing the bottom essentially. But if you're keeping that on your machine and then sending it on through Active Merchant or something like it, then you need to do see it's there's a selection matrix on the PCI website that helps make that decision a bit easier. But generally if you're outsourcing all the payment processing stuff and you are able to take that slight hit on not making things pretty for your customers, punt them on to them to take the payment off them and then you only need to worry about SEQA and you don't need to worry about PCI from that point because once you've done it you just need to keep checking your doing it. So is this really something that all the things that can be going wrong with your business, where does this sit? Do you like being hit by? I think that depends where you are more than anything else and to be honest I don't know if any small business has been gone after for not being PCI compliant yet. Most acquirers are happy for you to be working towards it and they'll get more and more shirty with you as time goes on to make sure you are getting compliant because you need to be because they want to eliminate the risk. But when you're not compliant you're a risk to them so from that point of view you'll be getting more and more harassed about it if you're not but it's fully not necessarily something to lose sleep over but at the same time something you need to consider. It's part of the annoying vagaries of the spec in that no two QSAs, no two people are going to interpret in the same way. Your bank will have you jump all through however many hoops it thinks you need to do it and it's unavoidable when you're dealing with something that is that nebulous in the first place. If you're going through it now, they went after big companies first because that's where lots of money is going through so that's where they can stand to lose money. Now they're bringing it further down the end as well and probably in the next year or so it's going to be you will be PCI compliant or you won't be able to take cards. It depends what the application is. Your card processing application, yes that needs to be penetration tested, that talks to it not necessarily. It depends on what you're doing and if you're working with a QSA to sign off on your self certification then they might ask you to do that or they might not. It's something you'll need to get an opinion on, but generally no. So I don't think I understand your question. There's PCI DSS? Oh yeah, you do, yeah. That's a bit out of the scope of what we're talking about today, but yeah, you need to do that. It should be fairly simple. You download the form, you print it out, you tick the boxes and you sign it. You'll need to find out based on who you're working with, you need to send it to, but it's usually just a case of then scanning the signed form in an email into someone. It depends entirely on what you're doing and how you go about building it. The way we did was a level one service provider, which is bigger, so we had to work with a QSA full time, which added significantly to the cost. There was a harder need to buy and an entire network to build, so the overall cost of that is not really a reliable indicator of how much doing the level c thing will. Most of it's in time and from a development point of view, I stick in, people might have to actually mention, I don't know why. I'd mention a thing on a book somewhere and configuring firewalls properly and going through it is maybe a couple of months' work, but it depends what you want to do with it if you're going. Anybody else? Are there any positive benefits from informing your bank that you're now applying, so can you get a discount, for example, on processing courses purely for the types of releases? You probably need to ask your bank. Some will charge you for not being compliant, so from that point of view, there's a benefit. A lot of people are, certainly from one experience, asking you if you're PCI compliant before they do business with you, and if you tell them no, then you might lose business out of it, but it does seem to be more of a defensive thing just now. It depends on your bank. They might give you favourable rates if you're PCI compliant now. They might not sweet them. There are also probably good people who speak to in general about your specific compliance needs too. Yes, there's loads. Some of them are freely available online. Others you need to pay for. Some people sell compliance packs that you just need to fill in the blanks. A lot of it really is just writing down what you're doing already. It's not saying to change what you do, but just that you need to document it so that somebody could at any time come in and verify your work in the way you sit here. So it just depends if you've got the time to write it all out fine, if not, or if you're starting from scratch, it might be better to get a pack in to do it. But yeah, you can pull templates off the internet fairly straightforward. I'll stick a bunch of resources up on my blog time when I get home, so a bunch of things sitting on my computer home that I can stick up that probably should have stuck on the slides. I've not thought about it, but that seems brilliant. The requirement is you need to document your change. They don't tell you how they're really vague about hows in the spec, so if you've got a way to do it automatically, that just shows this has changed, this is why it's changed. And if your guests, you're disciplined enough with what you're sticking into your git commits and everything else, and yeah, you could probably get around it that way, yeah. You could build a change request mechanism around, say, get-ups full requests. Yeah, that could work. Actually, it really could work. It's a very good idea. That's what I did, yeah. Again, they're fairly loose about how they define logging, except that you need to do it wherever you can, and what you're logging you need to log hits. If I wasn't really, really nervous and terrified as I'm from, but if people could probably talk about it for hours because it's these really hairy things, and if you want to talk about it more, grab me after, because it's a really long, rambly thing that's kind of thorny and hairy. Sorry to pop out there. Any other questions? I can't imagine it not having an impact, but at the same time, I'd probably say it was negligible. That's just my opinion. Yeah, it's like 3D Secure's chip and pin for your internet purchases, and PCI DSS's chip and pin for your company. That's a good way to think about it. It's just arsecovering and really moving around. Anything else? Cool. Well, thanks for listening to me, Randall.