We're going to talk about Trusting a Cloud Provider. Like anybody who runs up reputable business these days, the providers intend to provide secure services, and most failures from what the research has shown tend to be consumer errors or at least errors that can be blamed on bad system configuration or insufficient protection. No system is perfect, even though the provider tries to provide a perfect environment, there are always risks, subverted employee or an external disaster. How do we address these? Aside from the disaster issue, which tends to be addressed by having multiple sites and distributing your load across multiple sites, the subversion issues tend to be addressed through least privilege and separation of duty. There are a bunch of things that can happen with physical access to our information stored on the cloud. The thing that comes to mind for a lot of people, first, I no longer have physical control over my data. I've given my data to somebody in a remote location who has control of it instead of me. What kinds of things can happen as a result of that? Stealing the media, stealing the crypto keys, copying information, put malware in the system, and network connections, install untrusted computers. These all, are things that could happen. What kind of evidence do we have that we should trust this particular vendor? The SOC 2 Report is a good place to go to see what kinds of things the vendor does in order to protect their system. Remember, you've got the SOC 2 and The SOC 3 Reports. The SOC 3 is generally available as almost a marketing document. It provides information that also shows up in the SOC 2 Report but anything that's considered sensitive or proprietary is removed. The SOC 2 Report, most cloud vendors will provide to a serious potential customer. You can get that one and it will provide you as much detail as you're probably likely to get unless you're a really huge potential customer. SOC 2 is going to identify issues about how the employees are vetted, what kinds of separation of duty there might be, what kinds of cloud consumer restrictions there are, and also disaster planning. What happens if one of the server systems goes down, or one of the server sites has a flood, or other disaster. There should be separation of duty measures that are at least covered at some level. We always like to go back to trust but verify. Yes, your individuals can do things that could cause damage to the systems or could leak customer data. We want to put in monitoring so that we can determine if somebody has actually doing this or not, record their attack and then be able to address the problem after we found that it happened. Ideally, we try to protect things ahead of time but sometimes that's not possible, so we also have the monitors and the logs. One of the important things about the logs and the monitoring is that it's managed by a separate team of operators and logs are stored off site so that site employees can't modify them. There's that level of protection to the information as well at least if it's properly done by the cloud provider. Let's talk about example Staff Assignments in order to illustrate the separation of duty, division of labor, and those capabilities, and those security measures. We'll look at having four different teams one for physical security, one for operating and monitoring the systems, one for technicians who do physically things to components of the server systems, and networks, and such, and on-site administrators who don't operate monitor but they are responsible for establishing policy, installing new software, those sort of things. Physical security team, their main duty is to manage physical access to the system, keeping door secure, checking badges as people come in, access control, making sure doors are locked where they're supposed to, periodic security sweeps. The old guard arrange where the guard has to go and visit different parts of the building to visually observe the status of things. One of the restrictions is the physical security team really doesn't need administrative logins to the servers that manage consumer data. They really don't have access to that. They'll have access to their own computer systems to manage the access control to doors and things like that but they don't have access to the Cloud consumer assets. On-site technicians. They're the ones with the physical access to the systems. Well, the security team does, but they don't actually do anything with the systems. These are the people who actually go in, pull hardware out, put hardware in, attach wires, attach electricity, and those sorts of things. Again, like the physical security team, they don't have administrative access to Cloud consumer information. They have access to utilities and debugging tools that they need in order to verify that the equipment they put in is correct or for tracking down problems. But they don't need access to end-user data. System operators. Similarly, they don't really need access to end-user data. In fact, they don't really need physical access to system hardware except for whatever equipment they're using to monitor the rest of the site. So they'll be monitoring the video surveillance. Everybody has video surveillance now. They'll manage the network and server operations. If something goes down, they'll know how to bring it back up. They'll know how to log it and make sure that everybody knows about issues arising. They also have to monitor security logs and alerts so if there's some kind of attack it's detected by the security software. They're the ones who'll find out. System and network administrators. They are people who handle access control and software updates at the software level. They don't manage access control physically, but they manage it with respect to software. There you'll have a separation of duty with different people assigned to different systems. They won't have direct access to consumer data, although they'll have administrative access to the system hardware. The way that access to data is managed really depends on the configuration. But a typical approach would be for consumer data to be encrypted in storage and the administrators don't have access to the keys. Physical attacks. Here's one of the first ones we'll look at. Stealing data. We won't look at crypto keys until later. Probably, the next video. Countermeasures, drive encryption, video surveillance, security sweeps. Physical media could get stolen, but the crypto will keep it from actually being disclosed. Let's say that a subordinate employee tries to put malware on media or add network connections where they shouldn't be. Again, video surveillance, security sweeps. Also, an important way of managing the security is network segmentation. Breakdown the network into separate components that have different security properties at a physical level. Now, you can also do that at a logical level. But from this level, we're mostly concerned about physical networking and physical attacks. Then again, encryption. If you're doing logical network segmentation, usually you have different crypto disciplines, or at least different keys running on the different segments and that keeps everything separate. Another attack risk, somebody installs an untrusted computer. Computers are nice and tiny. Now, you can take one and you could essentially connect it with its Ethernet cord to one of the backbone computers inside the system somewhere and that could sniff data, interfere with traffic, etc. But it won't have administrative access to anything and with network segmentation and encryption, it'll limit how much it can actually do. Well, and how do you exfiltrate the data? The attacker will have to go in and take the module back out again, which increases the risk of being detected. [MUSIC].
