Management Plane and Business Continuity

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

9 hours 59 minutes
Video Transcription
domain. Six focuses on management plane in business continuity
With this domain, we will be transitioning the focus away from those more business oriented aspects the just governance, compliance policies, procedures and the overall way you define and operate,
and we'll start focusing on more technical areas of cloud computing.
All of those business oriented items establish a vital foundation for making the best technical decisions. But personally, the technology is where my career and interests really lie. So I'm very excited about this transition in the material topics
For the remainder of this video, we're going to focus on the management plain. We will define the management plane and its vital role will talk about methods of accessing the management plain and controlling access to the management plain, and finally will examine additional security considerations. From the providers perspective and the customer's perspective,
the management plane is the most significant difference between traditional infrastructure and cloud. In an I asked model, you use the management plane to define the software defined networks provisioned virtual machines, create virtual hard drives and defining the virtualized infrastructure.
The management plane also plays a key role in configuring past services,
and it's the using air quotes here, the admin tab on your SAS based applications
for I asked in past. It's like having physical access to your data center. But it's all centralized across many difference data centers bearing in mind that the SAS model the level of detail of which particular data centers in the specific regions that machines and computers happening in is usually abstracted from you.
The management plane plays a key role in the self provisioning attributes of cloud. As we discussed in this definition, it is the glue that holds the cloud components together and allows orchestration.
You may recall we talked about the different layers, and the management plane itself is part of the meta structure layer. At the same time, it provides the mechanisms that allow you to define the meta structure for your own cloud based resource is applications and systems.
Let's dive into this a little bit further, since it plays such an important role, you need to secure your management plane tightly. If somebody gets control of your management plane, it's like you gave them keys to your data center. Even without the roost passwords to all your devices,
they can still create copies of your data discs and export trade. All that information,
so you access the management plane using Web interfaces. AP Eyes Rest Based AP Eyes suffer development kits and command line interfaces.
The management plane for East Cloud vendor looks a little bit different, but I have included a screenshot of the management plane for a W S on the right just to give you a better feel for this term as it plays out in the real world. If you haven't worked with Cloud previously, you'll quickly notice the user interface allows you to create and manage virtual machines.
Configure past services like the A W S I O. T.
And a whole lot more.
As a final point, the management plain extends the shared responsibility model. So let's look at the specifics of responsibilities between the provider and the cloud customer.
Cloud provider needs to make sure to ensure the services hosting management plane functionality are secure. It starts with a strong perimeter and security focused on those servers that themselves are hosting the management plane application. The cloud provider needs to provide methods for the customer to authenticate against the management plane.
The cloud provider also needs to implement an identity management solution so that as the different parts of the management plain talk to each other, the identity of the entity that initiated the actions is carried through. For example, I log in to the management plane. It's a Web interface. I click the right buttons and say, Provisional Virtual Machine.
The management playing that Web interface itself is not gonna create the virtual machine.
Rather, it's going to spawn off and call to different services, running in particular data centers in regions and say, create a virtual machine.
But my identity is an individual needs to be carried along with that request is well so that when it comes time to create that virtual machine in that particular region or data center, it knows who's doing it and it convey. Verify that I am authorized to perform those actions in that area
authorizations and entitlements or another capability the cloud provider needs to build into their management plane. This allows the cloud customer to create different accounts and follow the least privilege. Practice
management plane is a key tool for separating enforcing multi tenant isolation. So if you could log into your management plane But imagine invoking commands that control cloud resource is for another tenant. That would be a very bad thing.
It really is the responsibility of the cloud provider to prevent this kind of cross 10 and exposure from happening.
Last but not least, the cloud provider needs to have their own logging, monitoring and alerting in place to detect any compromise of the management plane.
What about the responsibilities of the cloud customer?
You want to make sure you minimize use of the master account and keep it secure. This account should be associated with a group email, not an individual. This is the first account you create to establish your cloud account in presence. And once you have that account, store the password off in a safe place that could be accessed by select individuals within the organization.
But you really want to be sparing with that account as well as other super admin accounts.
You're gonna want to create accounts for individuals and apply the principle of lease privilege for service, add mons and service accounts,
so be sparing with the super admin accounts, so this can include the master account and then other accounts you've assigned to individual, but maybe you were quite lacking and gave them very broad privileges and capabilities.
Apply that principle of lease privileges for admin accounts and service accounts and what I mean by service accounts that there are those special types of accounts that exists within a system, but they're not bound to a particular human being. These is frequently used in automation, for example, to perform deployment operations and promote
software application versions from
lower tiered environments. Your development in Q environments up to production environments. These accounts can also do automated provisioning of services and even creating the production environments. So it's very important that these special service accounts also apply the principle of least privilege because you've given individual minimal rights.
But then they have the rights
to perform actions and initiate automation that the service account does.
Then they could potentially start having that service count do ah, bunch of things that they, as an individual, should not be using. Even worse, the audit trail will be all muddied up because the fingerprints for all the activities that the service account does will say the service account, not the individual
that initiated or told the service account to do these different things.
So say things went really wrong. Now you have to do a bunch of detective work to figure out OK, the automation account deleted a bunch of your production servers. But who initiated the automation account itself and who gave it the commands in the script to perform those activities? It's just another layer you have to go through.
And that's why it's so important to keep tight controls around these service accounts and really do apply the principle of Lee's privilege.
All authentication should be over secure channels like TLS.
Single sign on integration is extremely valuable. Many cloud providers allow for integrations with your company's identity management system.
For example, a tzar active directory. This way, your cloud admissions don't have to manage distinct accounts when accessing the management plane. Multi factor authentication is key for securing the management plane. MF A should be used for individual accounts.
You can use things like time based one time password or even universal second factor multi factor authentication. And last but not least, we were talking about those service accounts. You're gonna want to rotate the authentication tokens for those service accounts on a regular basis. In fact, there are other technologies out there, such as hashtag Orpik evil, which allow you to
continually rotate the accounts themselves.
As we were going through some of the previous examples of service accounts, we talked about some of the bad things that could happen if an individual is able to control what these powerful service accounts conduce you. And so by constantly changing the tokens that the service accounts are authenticating with against the plow provider and, of course,
changing the accounts themselves, you can really mitigate a lot of that risk.
So to really bring
to really bring home the importance of securing that cloud management plane, let's look at a scenario that happened in real life in 2014. The root account of a company called Code Spaces was compromised and held for ransom, the hacker said. If you're not gonna pay me a lot of money, I'm going to destroy your system.
Well, the company code spaces did not pay the money,
and Hacker ended up deleting all the virtual machines, all their data backups all their storage accounts to quote threat post dot com Within 12 hours, code spaces went from a viable business to complete devastation.
So in this video we talked about the importance of the management plane. It plays a critical role in your cloud. It's access than used through Web and a P I methods. Individuals and services interact with this management plane to initiate automation. Provisioned cloud resource is, and they do so using different methods of authentication.
You always want to secure the root account for your cloud enforced, least privileged by using role based access control structures for the different accounts. Also use multi factor authentication for cloud accounts that access the management plane whenever is possible.
Up Next