1. Basics 2. Services 3.Compliance 4. Planning Cloud Security
Infrastructure-level cloud security
Infrastructure-level cloud security – [Instructor] Okay, let’s talk about cloud security infrastructure services. And we’ll start with the primitive services. So, typically, public cloud providers have regions, in other words, where they actually house their servers and you can pick a region. So you can pick the Northern Virginia region, the California region, a European region, Asia-based region, or other zones that are out there. You can deal with things that are at the edge, so in other words, you can deal with edge-based devices which are going to be part of your infrastructure. And they typically can be IoT-based devices that my be bound into a cloud through some sort of IoT-based systems but we’re starting to see more of these as time goes on. So not only is it central or regional, but the ability to kind of push things out there beyond the clouds, to the edge of the systems, the edge-based devices, which are typically gonna be internet of things. Moving up the stack, we have infrastructure as a service foundation services. We have compute such as Amazon’s EC2, the ability to, in essence, leverage compute services from cloud providers, storage so you can leverage storage services from cloud providers such as object-based storage such as Amazon’s S3, database services such as Amazon’s DynamoDB, or Microsoft Azure’s SQL server, or networking based-systems such as network management, the ability to, in essence, run things through the cloud and have ingress, in other words, push things into the cloud, or egress, pulling things out of the cloud. Additionally, considering security, you have client-side data encryption. So, in other words, we can encrypt things on our side of the system and before we transmit them up to the cloud, we also have server-side data encryption, in other words, we can encrypt things within the cloud to make them secure. And also, network traffic protection. This is also known as encryption in-flight and we’ll learn more about that in a later presentation where we’re able to encrypt information that’s flowing from one point to another. So moving up stack, we have client content, in other words, the content that you provide, that you’re either going to use on premise or move into the cloud. We have platforms, applications, identity, and access management systems, the ability to, in essence, leverage identity as a way to tag things as to what kind of security parameters and patterns need to be applied to those things and those can be pieces of information, a device, a human being, things that we, in essence, need to secure. And then operating system level secure, network level secure, and then firewall configuration. So the idea is that we have layers here and different ways in which we look at the components, regions, we can do security within zones, we can do security at the edge, we can certainly secure our compute instances, our storage instances, our database instances, our networking instances, and we can do encryption at rest, either on the client or the server side or encryption in-flight as we move it from one source to one target and then ensuring that people can’t see inside those packets and look at our information as it moves down the network. And then we can do operating system, network and firewall based security, as well as platform applications and identity access management. So all this means is that security is really kind of a complex thing, so ultimately, we need to break apart the different components, and these are the components of the infrastructure that you need to consider.
Application-level cloud security
Application-level cloud security– [Instructor] Let’s talk about application level security in the cloud which is extremely important, the ability for your applications to deal with security systemically and have mechanisms around it to protect themselves is an absolute necessity in today’s world. We have infrastructure logs that we deal with so we can look proactively at information that’s being dispatched and consumed by the application. We can look at disc writes, we can look at network reads and writes, we can look at other things which really will show us that some sort of attack is occurring. For instance if disc IO goes up for no particular reason and network traffic goes up for no particular reason we may have a breach in progress and we can take steps to stop that breach just by looking at the logs and identifying when something is occurring that’s out of balance. Application stack logs, OS application servers, database and programming languages are important as well. When you design applications you design them with security in mind so you build in mechanisms to ensure that security is being adhered to and if there’s something that’s out of balance such as information going to an IP address that you don’t recognize or disc IO that you don’t recognize then someone should be alerted to a possible attack. Again this happens at the application level, not at the infrastructure level. API logs are also important as people use application programming interfaces to access applications and data in applications you need to be able to log those as they occur. Governance systems such as service governance systems are very important here so your ability to log in and protect the APIs and services allows you to authenticate who’s leveraging them as well as record the actions that are occurring as they leverage them. In addition, application logs, the ability to figure out when things are launched, when data is read, and basically anything that’s occurring within the application that will provide you information that really determines if there is some sort of attack going on. Data export and import logs are also important. Data that’s being taken out of the system is very important to protect. Obviously if someone is offloading the database and you don’t know that someone if offloading the database then something is occurring that you need to stop and you need to be alerted to the fact that that’s occurring. Security and access logs of course the ability to spot when people have made more than 10, 15 attempts to log into a system using random security password generators, the ability to look for information attacks, information logins that are coming from different IP addresses or IP addresses that are outside of the country. The ability to monitor these logs is absolutely imperative in protecting your systems and all they are is basically calling through text files that are being built by the second so we’re able to determine in real time based on what we see in those logs as to what is occurring within the system and when there’s a breach or an attack that’s underway. Event notifications and alerts, so the ability to not only look at the information but set boundaries in terms of what’s not proper in the logs that are being laid down so the ability to find things that are out of balance such as IP addresses that are outside the countries, such as disc IO levels going up, such as an inordinate amount of logon failures, all these sorts of things should be captured and you don’t necessarily have to notify somebody of every event that’s out of balance but if there’s patterns that are occurring and analytics can determine this then it’s a matter of just notifying the administrators so you’re able to take corrective action and protect the system. Changes, configuration, management and deployment also important make sure that if you’re gonna change the system that we can figure that into security as well because if we’re adding a disc and deleting a disc adding network bandwidth and that’s gonna change security policies and configuration of the system and you have to be wary of that as well. Make sure you understand your patching history and machine images so as we’re patching software we need to take into account and make sure that those patches are protected. Remember people can insert malware at times of patches and if they do that they can take control of the system as is the case in Target that we saw in the previous video. Also activity logs, session logs, and attacks and DDOS logs, denial of service attack, if someone is basically taking over the system or using excessive amount of resources they should be automatically kicked off, we need to understand the session logs that the people who are leveraging the system including the users ’cause if they’re malicious users we need to stop their activity. We need to understand exactly what’s going on and as they’re behaving and communicating with the system within the activity logs. If things are occurring that are out of bounds, they need to be locked down.
Data-level cloud security
Data-level cloud security – [Instructor] Okay let’s talk about data security. So, there’s a few levels that you need to pay attention to. Number one, table object level and that’s basically the collection of data. So if you look at what a table and what an object database does, it’s basically a collection of information. A table in a relational database is going to be exactly that, it could be as many as billion records in a particular database. Typically it has a structure attributes, in other words, you’d have to adhere to the way in which it stores and maintains data. The data semantics, things like that. And the reason it’s important to understand that in terms of data security is because we may lock things down at that level, we can lock things down at the record level. In other words, the instance of data, such as an address, or we can lock things down at the table level which could be all addresses. So the database level, that is the entire database. And so you think about an Oracle, Dynamo DP, there’s thousands of databases out there and they all basically do the same thing, they manage the storage and retention of information. They’re able to produce it for you in an orderly manner, they’re able to store it for you in an orderly manner. You can search through it, you can leverage it from applications and the reason this is important because sometimes not only are we just locking things down at the table or object level, but we’re locking things down at the database level. In other words, we’re denying access to the entire database. Either it could be minor, either we give people access to everything or access to nothing. Or we give people access to a certain number of tables, certain tables in the database or access to no tables. Or one table, or ten tables and it’s the ability to kind of configure your data security to set this level of access which is really important as we’re looking at Cloud security. And then the record level, so in other words, the instance of data. Like I said, an address in a customer database would be a record level security paradigm. So in other words, we’re able to approach security by locking things down a record level, so someone’s unauthorized to see my address in the database at the database level or in the object level. Storage level’s kind of interesting because what we’re doing, where database systems have to have access to some sort of storage system, you know, S3 for example, on Amazon web services, the ability to lock storage down completely. So in other words, a storage instance, in other words an instance of S3 is going to be secured. It’s going to be either encrypted or it’s going to be password protected and we’re not allowing access to a storage based system. So, we have a couple of levels to consider here. In other words, storage, which is the actual virtual storage, which we consider as physical storage in the world of Cloud computing. The ability to lock down the database, the ability to lock down the table, our object level and the ability to lock down the record. And the ability to do that means that we’re able to secure things in a more fine grain level. So in other words, I’m able to configure my security around the exact needs of the business and I’m able to provide security either holistically at the storage level, holistically at the database level, at the table level if I’m trying to deny access to certain types of information or at the record level if I’m looking to deny access to certain instances of information. Now the platform level, obviously that’s locking everything down. So in other words, if I can’t get into my AWS account, I’m locked out of the platform level. I’m unable to get to the compute system, the storage system, therefore the database and the records and I’m denying access to everything. And sometimes this is perfectly fine. So in other words, in many instances I wanna configure very fine grained granular access to information and I can do so at the record level or at the database level or at the table object level. However, sometimes I just don’t want people to get into the platform at all and I’m gonna lock them out of the platform and if they’re able to access the platform, then they may have access to everything within that platform, including storage and record and databases and everything we mentioned so far on the slide. And then finally, in flight, which is basically encrypting information as it flows down a network wire. So, the idea that we can encrypt information that may exist in a physical or virtual database storage that sits on a cloud and we need to move that information back and forth between our client-based applications. Obviously that makes the information vulnerable if it’s not encrypted, so we do things such as encryption in place, or encryption in flight, where the ability to lock information down that’s flowing down a network so it’ll deny people from accessing the information if they have a network sniffer or other sorts of hackery that’s going on and equipment that’s going on in terms of how they’re reading information that may be on the network wire. So, keep this in mind the different ways in which we do data security. Table object, database level, record level, storage level, platform level, and then the network level where it’s in flight. Or it could be data at rest.
User-level cloud security
Users = create individual users
Groups – manage permissions with groups
Permissions – grant least privilege
Managed policies – custom and AWS policies
Rotate – rotate security credentials regularly
Conditions – restrict privileged access further with conditions
Root – reduce or remove use of root
Audit logging – enable CloudTrail and Config
User-interface-level cloud security – [Lecturer] Let’s talk about user interface-level cloud security, or user cloud security. We have to give logons to users, people who leverage the applications and leverage the databases that we created and migrated to the cloud. So what we’re doing is basically setting up best practices, where we’re setting up groups, as well as users, and applying the meaningful protections to ensure that they’re able to leverage the system, but do so in the context of very valid security. Permissions allow you to grant privileges within the system, so who can access what piece of information, what file, what object, what database, things like that. And we can allow people to access any number of things and disallow them to access any number of things. So the idea is, in essence, to manage permissions with policies that we set up, where we’re able to allow them access to things they need to do their jobs and disallow them access to things they don’t need to do their jobs. This is a lot of work for security administrators. However, it does protect the system, and if someone was able to access the system and hack into the system, they don’t have the necessary permissions, and they’re not going to be able to effect any kind of damage. The ability to manage policies, basically custom and AWS policies, allows us to put in written things that allow and disallow access to certain resources that exist within the system. This means that instead of permissions that are really at the user level, the user ID level, we’re managing policies as a whole. So in other words, accessing resources such as storage/compute systems, services, things like that, are going to go against the governing system, which is in essence going to look up the policy and make sure that people are allowed to access it, that the access is logged, they have the proper authentication, things like that. Best practices, password, configure a strong password policy. We all know this by using the web. Some systems will not allow us to have abcdefg, or our dog’s name, or counting 12345 because those are weak passwords. The ability to configure a strong password policy, meaning that the users are going to leverage passwords that are difficult to guess, is going to be a huge protection of the system. If you have random password generators, things like that, they can break into older obscure systems pretty quickly that do not enforce strong password policies in the existing stuff, but this means that we’re gonna have an initial fence that disallows people from trying to guess their way into the system. Enable MFA for privileged users. So, make sure we’re managing keys, multi-factor authentication within those systems so that if we’re allowing people in there, that we have an extra layer of authentication that occurs as they try to access the information. Roles, use identity access management roles for EC2 instances. Identity access management is absolutely imperative for leveraging cloud-based systems, because it allows you to assign privileges and access policies to particular identities that exist within the system. It could be humans, it could be machines, it could be resources such as disk storage, things like that. And we allow us to do sharing, or using identity access management roles to share access. So we’re able to assign roles, assign identities, assign access rights, and we’re able to configure and reconfigure them however we need to support our security policies or security structure. Rotate security credentials regularly. Can’t state this enough. So we have to change passwords, change keys, change multi-factor authentication approaches, things like that. We can’t do the same thing all the time and expect to have security that is unpenetrable. So, changing security credentials is absolutely imperative. Restrict privileged access further with conditions. So what are the conditions under that people can access the system? Root, reduce, remove use of root. The ability to get access to everything in the system is extremely dangerous for anybody to have. Accidental deletions can occur, and you’ll be in big trouble if someone does that. Audit logging, enable CloudTrail and Config within AWS and make sure that we turn on audit logging and we understand exactly what’s going on within the system. We talked about that in a previous video. The ability to monitor and proactively look at what’s occurring in the environment, both at the application level, the data level, and in the infrastructure level, is determined through logs. We’re basically recording everything that we’re doing and we can see patterns of attack that are emerging in the audit logs and the information that we’re logging.
Rise of identity and access management
– Identity and access management, or AIM is absolutely imperative to Cloud security. It allows you to sign identities to users, to devices, to components, to resources, and then configure who can access what device, what resource from what identity, what user identity, what resource identity, what device identity, and whatever. And so the IAM user is an entity that you create in a system such as AWS that provides a way to interact with the Cloud system, Amazon web services, either EC2, S3, elastic block storage, or any other resources that they have. So the primary use of Identity Access Management is to give people you work with identities that they can sign into the management console, and request services. So I can configure, for instance, Brad can have access to certain types of services, and Jim can have access to certain types of services, and if somebody else comes along and tries to access those systems, and they’re not authorized, be it my identity access management system, they’ll be disallowed from accessing the system. And again, it not only protects you from yourself, it protects your users from harming the system or basically using resources they’re unauthorized to leverage, but also if the system is attacked, there’s another layer of security that hackers have to go through to get access to your information. So to do this you create an AWS account, and you’re the only person who works in the account. Other people in your group need to work in your account and your group is using no other identity mechanisms. So you want to use the command-line interface CLI, to work with AWS. Users in your company are authenticated to your corporate network and you want to be able to use AWS without having to sign in again, that is you want to allow users to federate with AWS. So the idea here is that we’re going to leverage Identity Access Management to make it easier for us in essence to manage security because when people come unlogged to the system and they authenticate AWS, we know who they are. We know their identity and they’re able to use their identity to get access to various system resources out there. So ultimately, these things can be set up in AWS but by the way there’s an IAM system that works with Google, and there’s an IWS system that works with Microsoft as well so this is native databases we are talking about in this particular video. However, there’s analogs of this particular system the other Clouds. They work a little differently, but they’re basically the same. So within IAM, a group is a collection of users. Lets you specify permissions for a collection of users that can make it easier to manage permissions of those users. So we talked about this before. So we leverage groups that’ll allow us to have access to particular databases, storage resources, things like that, and so we may have a group which is our HR group, which has access to our HR records, such as employee data. However, we do not want the developers to have access to the same data. So therefore we will specify restrictions that are based on groups of users that are identified in our IAM system. And group can contain as many users, and a user can belong to multiple groups. So someone can belong to the HR group, but they can also belong to the executive group. They can’t be nested, you can’t take them down to multiple layers, and not default groups that automatically includes all your users in AWS account are setup. So there’s typically a limit that occurs in an AWS. It’s 100, and there’s always a limit within whatever identity access management system that you use and it limits 10 groups per user.
Focus on compliance
– [Instructor] Okay let’s focus on compliance as related to database security. It’s a very important topic these days. So compliance is about dealing with standards or regulatory laws and issues such as HIPAA, which is the one that’s related to health care. It basically defines how we deal with personal identifiable information in the medical world. But it can deal with insurance in other industries as well, and anytime you’re dealing with medical information, the HIPAA standard applies. Sarbanes Oxley, or what we call SOX, and there’s SOX one and SOX two, different instances of that, and that really goes to corporate reporting as it exists in a corporation. So in other words, if you’re a publicly traded company, you have to adhere to this standard, and therefore how you handle data, and how you handle processes that handle data need to be audited, need to be complied with. GDPR, which is relatively new, is a European based standard, and what it means is that we need certain processes, roles and responsibilities that are around the protection of information. And so this will go into play in 2018, and going forward we need to comply with it. So in other words, anybody doing business with European companies, European data, European citizens, those sorts of things, need to make sure that the information is going to be managed correctly and processed correctly as to the GDPR standards as it flows in out of those countries, or even if you’re dealing with European citizen data that may exist outside the countries. PCI is related to retail. The ability to handle credit cards correctly. And then there’s virtually hundreds of standards we’re dealing with today. There’s privacy regulations out of Australia. There’s privacy regulations out of China. There’s virtually hundreds of laws and rules and technologies and policies that you have to be in compliance with as you deal with data that exists inside the country or outside the country. So, and it’s your responsibility to understand where that data exists, and the rules and regulations that apply to the information, and making sure that you’re going to be compliant with the rules and regulations, or they can audit you, they can fine you, they can even push you out of the country if you’re found in violation of the rules and regulations, depending on the regulatory body you’re dealing with. So the best practices and metrics for success, some of the examples are security systems, availability responsiveness, cycle-time improvements to business processes, degree of compliance with deployed technical standards. Degree of compliance with deployed business policies, cycle-time for resolving business policy non-conformance, effectiveness of deployed security-related communications, number of application groups/developers trained on security tools, percent of systems/applications utilizing security services, and the completeness of the system documentation, as well as improvement in the ability to enforce security and privacy policies. So going forward, we need to understand that regulations are all about data security because they’re typically around handling information in such a way where you’re not externalizing the information to people they’d rather not see it. And certainly, if you look at kind of the common patterns of all the regulations we just looked at in the first slide, that’s really it, the ability to understand where you are, what data you’re protecting, how you need to protect the data, and how regulations apply to the protection of the data. So the approach should be to put compliance domain configurations in place. In other words, instead of programming new systems to be compliant with everything that’s out there, we basically put volatility, which regulations and laws and legal issues are, into a domain. And we’re able to reconfigure and configure that domain as the laws change, laws are added, laws are taken away, laws adjusted, which they will all the time. Things that are going to change over time are going to be the regulations you’re dealing with. So what you need to do as an objective as you’re dealing with data security is understand that regulations are always gonna be a pressure on the information, a pressure on the data. And what you need to do is make sure that the volatility in terms of you’re ability to remain compliant with those regulations is put into a state of security in a data governance system that’s configurable, so we’re not reprogramming, or redoing, or redeveloping our databases each and every time the regulations change. Ultimately, we’re able to configure our data governance, configure our data security around the emerging or changing regulations.
Question 1 of 4
What is the best practice for user interface level security?
Part Two Cloud Service
Cloud Services 2. Microsoft
- Managed code access security
Part Three Cloud Compliance Service
Retail – [Instructor] You’re a retail organization moving to the cloud. What are the compliance issues you have to deal with? Well, to understand compliance in the retail industry, you need to understand how we deal with financial transactions and how we protect financial transaction information. This is really about PCI at the end of the day. The definition of Payment credit Card Industry, Data Security Standard, or PCI-DSS. Where did it come from? Well, it was set up in 2004 by Visa, MasterCard, American Express, Discover, and JCB to reduce the risk of credit card theft and transfer liability to the merchants. There are 12 core requirements, there are 280 audit procedures, and there are six control objectives. It requires a mandatory adoption by all businesses that store, process, or transmit credit card or debit card information. As we’re moving into the cloud and we put retail systems on the cloud, we need to understand that these retail systems that store credit card information need to be PCI-DSS compliant, therefore you need to understand the six control objectives, the 12 core requirements, and the 280 audit procedures that are involved. The effects of credit card breach on retail business are profound. We saw that in the target case we talked about in a previous video. $80,000 is the average direct cost of a data breach. One in six small businesses will suffer a credit card breach in the next 24 months. 210 average days between intrusion and detection. 70% of breached businesses are out of business within one year of the attack. 98% of breaches originate from organized criminal groups. This is big business and with big business comes big risk. With big risk comes compliance because the government’s gonna state rules or regulations in terms of how we live up to compliance and how we’re able to, in essence, drive financial transactions in a secure and meaningful way. What happens if you’re noncompliant with PCI? Well, credit card transactions, acquirers may ask merchants to cease. Forensic audit, QSA team on-site to determine the cause of a breach. Implement remediation actions. It can 90 to 100 days to complete. Fines and fees, merchant is responsible for all costs, $80,000 to $100,000 on average. Brand equity, breaches are public knowledge, brand images are tarnished. What advice to we have? Well, first you need to build controls into clouds to manage risk in terms of compliance. PCI is another regulation, it’s another standard, and it’s another set of mechanisms that you need to adhere to to ensure your data is protected and you’re compliant with the laws, regulations, and standards. Make sure clouds are PCI certified to support the compliance needs and mitigate the impact of breaches. This means working with your cloud provider. What mechanisms do they have to support PCI? How do they comply with audits? How do they support your data encryption standards? How do they support information that moves in and between the various systems?