Here we visit laws and industry standards that impacts cybersecurity. But this time we look at them in the context of privacy. We'll also review requirements of PCI-DSS. Now, the earlier videos we talked briefly about Gramm-Leach-Bliley and the payment card industry standards for data security. In a future video, we'll talk about FERPA, COPPA and HIPAA, which we also talked about before. Now, the US Privacy tradition starts with the Bill of Rights, but there is not actually an enumerated right of privacy. There are hints of it in the various things that are forbidden in the Bill of Rights, the particular rights that are reserved. But it's really not until the Supreme Court started pulling together certain rulings that we reached the point of actually talking about a serious right of privacy. Now, in the context of privacy, we now talk about things in terms of Personally Identifiable Information or PII. Now, Gramm-Leach-Bliley, essentially had this requirement that financing companies have to indicate how they share customer data. In a sense, that was a privacy rule in that, simply because a company had possession of your personal data, did not give them automatic permission to share with anybody else. They actually had to either have your permission or they had to warn you ahead of time that this was something they were going to do with your information. Here's the industry standard from the earlier video, of course, PCI-DSS. The important thing about this from a privacy perspective is that it protects personal account information. Also there are specific protection requirements which makes it interesting to look at. Payment Card Ecosystem, a lot of you may be familiar with that, depending upon who you talk to, you have issuing banks or sponsor banks, or they may be, I forget what the other terms are now. But essentially you've got one side that's handling, accepting payments through merchants. Then you have another side that is approving credit cards for end consumers. Now, in our discussions here, we're going to focus on point of sale, because that's where lots and lots and lots of different participants show up and want to produce systems that will support payment card handling. I mean, that's the basis of the internet now. Now PCI-DSS consists of 12 major requirements. I'm not going to make you squint and try to memorize this from the screen. I've also posted in this lesson, a document that provides an overview of the DSS requirements and sub requirements underneath them. Now, an important thing in the Cloud, is you have shared responsibilities. You've got the Cloud Service Provider and you've got the Cloud consumer. Now, for the most part in this class, I'm taking the point of view that we're the Cloud consumer, we're not the end users, we're not the Cloud provider. We're the end user. Essentially our responsibilities are shared with the Cloud provider. The provider gives us some things. They do the physical security and then depending upon the service model, maybe they do more, maybe less on software as a Service. Of course, most everything lands on the provider. Cloud service consumer, we have to provide the operating data, and identify our customers and colleagues who we're all going to be working with and now it's up to us to make sure everything is properly stored and setup in there. Infrastructure as a service pushes you even farther along. Now, we have to worry about the lower level things including malware scanning and encrypted transmissions. All the technical details start to fall on us if we're doing PCI-DSS and work at IAAS level. Now, key requirements in PCI DSS, is there are some essential technical measures you're required to do. There's physical and network security that they specify, you have to monitor for network attacks, malware, those sorts of things. There are also requirements for ongoing security testing, which is really a nice thing, and then employee security requirements. Now, the technical measurements, fire-walling, network encryption, user authentication, least privilege, secure software. Now we start getting a little bit more to the meat in that you have to have this environment called the cardholder data environment. If your organization actually handles the crown jewels; the primary account number, and the other components that come off of a payment card, you have to have a special software operating environment called the CDE, the cardholder data environment. That's the area that gets the most scrutiny when going through PCI DSS approval and ongoing certification. All the systems that handle rock-hard data have to be within the CDE. Now, one of the questions is, do we want to go to that trouble? We want to have this special environment that we handle all of our primary account numbers, keep them on storage in our facility, do we want to go through all of that? Some organizations do, some don't. If you're doing repeat business with somebody, you probably want to save their card somehow. But if all you're doing is verifying a payment, you might for say, one-time purchases or something else there are probably alternatives to actually doing your own PCI DSS implementation. Though, for example, you can use a third party processor like PayPal, Shopify, one of those. Or you can bite the bullet and comply with PCI DSS. Now, one of the problems there is that the detail requirements vary a little bit from one card issuer to another. So you're not only fulfilling those requirements, but say you have those two sets of requirements that overlap a lot, but not necessarily entirely. You've got PCI and then card issuer requirements, and then there's third-party review and assessment to make sure that you are actually complying. Now, if you want to use third party processors, there are a bunch of different ways to use that software as a service, you can essentially take some code from a third party processor like PayPal and embed it in your website and provide payment service that way. Or you can say that you're selling something, you can link off to PayPal, and then PayPal will come back to you and tell you whether or not it succeeded in the transaction. Another approach with SAS is to integrate with a storefront provider like Shopify or Amazon, so they're essentially are working entirely with your information, your descriptions of products and media to describe and illustrate. You don't necessarily have to write any software at all. Now, if you have a software development capability and you want as much flexibility as you can get, then you probably want Platform as a Service. Some people just say, well that's software as a service without as much support, but it does provide you with a lot more flexibility in how you can put together a shopping site. So if you don't want to have to say click through an extra couple of windows in order to complete a sale, use something like PaaS so you can put together your own process for actually handling and checking out a shopping basket. Okay, Let's say you are doing PCI DSS in-house. Let's start talking about that a little bit in the context of financial data classifications. Here we'll have an example of say, four types of data classification, we're going to use for financial data. Accounts receivable, accounts payable. We have those of you who are not familiar with accounting. There is a long tradition of keeping those two operations separate as a separation of duty strategy. Then company performance data, which we've talked about quite a bit already. Then finally, cardholder data environment. We could think of each of these as being a classification we apply to certain types of financial data within the organization. Okay, the classifications say this information types are distinct and should be handled separately. How do we keep them separate? We segment our networks. We use separate databases, separate servers, separate administrators. That's the best way to do it, make as much separation as possible so that you don't have, say, one administrator who's administering both accounts receivable and accounts payable because then you're in this situation where you don't quite have as much separation of duty as you might have thought you did. Similarly if you have one database with all your accounting data in it, both receivables, payables, and everything else. Then it's going to be a lot harder to keep the information separate or keep the information protected from people who shouldn't be looking at it. Application segmentation. Okay. Now, when you're running an application that handles payment cards, you need to separate the cardholder data environment, from the non cardholder data environment. Part of this is to simplify the process of getting certified through your own reviews and such as meeting all the requirements because they're larger of a community of computing devices that you have in your CDE, the harder it's going to be to review and certify. The ideal thing is to have a separate network segments, separate database, separate server focused on providing the cardholder data environment. When a system outside the CDE needs CDE data, they use Data Masking, which we'll talk about later as a strategy for being able to reach into the CDE and say, I want to work with this particular credit card number. I don't want to know what it is. I'm not allowed to know what it is. You can provide me with that funny masked version with just four digits at the end so that I can pretend I know what it is. But the actual transactions will take place within the CDE. All I get back is reports on whether it's succeeded or failed. Okay. Here's data Masking. If we're keeping the primary account number at our site, it has to be encrypted and it has to be stored in the CDE. If we want to refer to it outside the CDE, we need to essentially set up an index identifier for it, which then links us back to the actual account number were using. But it's stored in the CDE area and all we get back is those last four digits and a mask, and that's safe to share. Here's what that looks like in relational database. For example, you'll have an order, let's say comes from Kim smithy. The order is using her credit card that ends with the numbers 2391. You can see the order there as the index for the primary account number stored in the pan table. But we don't actually have that primary account number in the order table. We're keeping those two separate because one of them has to be inside the system and one of them has to be outside the system.
