Once an application is deployed, our focus shifts to managing it. Secure operations is the third metaphysics, the C s. A breakdown of the secure STL see
in this video will cover practices highlighted by C. S A four secure operations. Then we'll talk about the impacts of application design in the cloud world and finally will come back to see how those design differences can be leveraged. To improve your secure operations through the use of automated and even event driven security,
production and development environments should always be separated.
Access to the management plane for production environments should be tightly locked down compared to that of the development environment. Consider separate user accounts or privilege escalation. Procedures to provide access to production.
Take into consideration the identities that the cloud resource is themselves are using and how that impacts the way those resource is access other cloud resources and services. Sometimes these air called service principles. Sometimes they're called application identities. And just like any other user account,
the philosophy of least privileges needs to be applied to these special accounts
with an immutable infrastructure and server set up. There really shouldn't be any deviations of these elements from the approved baselines. At the same time, it may happen, so be sure to set up active monitoring depending on the particular cloud provider. This monitoring can and should be automated whenever possible.
You can also use a venture of insecurity which will talk about shortly to automatically roll back unauthorized changes to the production environment.
Application, testing and assessment should be considered an ongoing process, even if you're using an immutable infrastructure. Keep in mind new zero day vulnerabilities air being discovered in different software components every day. What is considered totally safe today may be highly vulnerable tomorrow. Just because we learned something new about problems with the software component
that was introduced earlier in the software supply chain
and thereby we inherited those vulnerabilities. Always remember that change management isn't just about application changes, any infrastructure and cloud management. Plane changes should also be approved in tract
application. Design in the cloud is different.
On the right is the fictitious city in the clouds from Star Wars. As you can see, the architecture for making this kind of building is quite different from traditional architecture.
A risk converse mindset will avoid anything new by default. This assumption is that new equals bad. But if you look at the cloud you'll find is different. And when you incorporate and embrace those differences into your design, you'll end up with something more secure.
We've touched on most of these points in earlier modules, but I'm gonna highlight key areas where the differences in cloud can be leveraged to create more secure applications.
Segregation by default
applications can be run in their own isolated environment. Depending on your provider, you can run applications in Stepford virtual networks or different accounts, although operational overhead will be incurred when using separate accounts for every application. Using separate accounts offers the benefit of enabling management plane segregation,
thus minimizing access to the application environment. Immutable infrastructure allows you to increase security by disabling remote Loggins to immutable servers and workloads. You can add file integrity monitoring to detect changes, which in this paradigm would be unexpected,
and your recovery plans can leverage the immutable assumption too quickly. Swap out problematic servers.
Micro services allow you to compartmentalize your software nodes. This is done primarily. Using container technology with smaller components is easier to create new instances or reduce the number of instances This is also referred to a scaling out and scaling in.
Each note is also hyper specialized, so you minimize the attack surface by stripping out all of the unnecessary parts and libraries associated with that note.
These benefits do bring more complexities when it comes to facilitating secure communication between notes providing ways for the notes to discover each other in other areas that require a container orchestration platform like kubernetes and or a service mess solution such as ist eo
has and serverless technologies can reduce the scope of your security responsibilities. The provider is responsible for securing the underlying services and operating systems. We'll talk further about serverless and future videos, but right now I want to dive a bit further into how that technology can help with software defined security and event driven security.
When I think of automated security enforcement,
the old movie Roble cop comes to my mind. I don't know why
software to find security involves automating security operations in automating cloud incident response that this includes activities like rolling back infrastructure configuration changes that were not approved.
Event driven security puts the concept of software defined security interaction. If sister monitoring that kicks off automatic responses whenever certain changes are discovered. For example, a security group has changed, but the change was not authorized. Say there is no approved change record. Then you kick off a serverless script to undo the change.
This interaction is usually performed through some form of notification messaging.
Cloud planes provide notification for many types of these events as an exam tip. If you're asked about the difference between software defined security and event driven security, remember that software defined security is a concept, whereas a venture of and security puts that concept into action.
In this video, we reviewed the important practices for secure operations in the cloud. We examine the impacts of application design in the cloud,
and then we finished off by reviewing how server Liss technology can be leveraged to have automated and event driven security.