in this video, we're going over key points regarding securing cloud applications. Users and related cloud technologies pulling from domain 10 12 and 14
Cloud deployments are often Greenfield in nature. That's provides you with an opportunity to re evaluate the processes you follow, develop software and ensure that security is baked into it. It starts with secure design and development. Of course. Training your developments draft training in the support staff to incorporate to secure design principles
such as threat modelling,
creating entitlement, matrixes when they're building the systems.
And from that point, you have secured employment. This is the pipeline taking your changes from development through Q A and into the eventually the production environments. This is a great opportunity to integrate human based code reviews, automated security checkers, static application, security analysis, duct about
dynamic application, security analysis, vulnerability assessments.
All of these methods should be configured toe work in the cloud environment, but also test concerns that you have specific to cloud platforms such as stored AP I credentials or hard coded passwords.
And finally we get to the secure operation. This is where you ensure you have good traceability. If you're using infrastructures, code change management can be realized not just at the application layer, but all the way through the infrastructure itself, which is being defied and clothed, making sure you've incorporated external perimeter defences such as Web application firewalls.
And you have ongoing monitoring and assessments taking place.
Application security changes in the cloud by starters. There's a higher baseline of security just by the beer nature of motivations that the providers have to make sure what they're delivering is secure.
You have a P eyes. In fact, you can be more easily create isolated environments by creating completely separate cloud accounts for your development environment versus your production environment. So if
one gets penetrated or compromised in some way, it doesn't have a ripple effect. And from within each subscription, you can further isolate. The cloud. Resource is leveraging micro segmentation.
You have great amounts of elasticity. You have the whole dev ops paradigm to incorporate into your application security.
Some of the challenges, though, where the limited visibility that you get you don't manage the full stack. The physical stack. You don't quite see some of the traditional models and methods for monitoring applications, monitoring network security and so forth. They don't apply in the cloud paradigm.
The threat models around you are constantly changing because you are in a shared responsibilities model.
So there's a variety of dependencies is the provider continues to upgrade things and alter things without your direct knowledge? Spend a good deal of time talking about identity management, making sure you have a formalized plan for how you're going to manage identities in a cloud. Environment Federation is a key technique to extend your identity management capabilities well outside your walls,
working within integrating with other cloud providers.
In doing so across the broad Internet networks identity broker, the hub and spoke model is definitely a preferred approach and cloud hosted services for identity access management can sink with your on premise. Authoritative services to support backwards compatibility with corporate systems you've used to manage identities in a pre cloud world,
a suite of responsibilities are shared between the provider and the customer. When we're dealing with access management in the cloud
provider needs to have basic capabilities in place. They need to make sure that their cloud plane at the least and management infrastructures are enforcing the authorization and access controls that you as a consumer are going to configure. And it's also very helpful and powerful if the provider
can not just support the concept of role based access control but include attribute based access control, allowing you to define and configure entitlements
and prerequisites that could be a little bit more situational e specific. For example, if somebody is logging in to perform administrative actions outside of your corporate network may require multi factor authentication, whereas if they're within the corporate network, you're gonna allow them to perform those different actions without requiring multi factor authentication
and finalize the summary of identity access management. We talked about
all the different kind of protocols that are out there, and there really are no magical protocols. You need to determine the protocols you support. You need to understand the protocols that the cloud provider supports and then examine your particular use cases in the constraints to define what is the right protocol to use to manage identities in a distributed cloud paradigm