So the solution behind this particular challenge was kind of a strict question,
but it's definitely
something that needs to be thought about as we start moving forward in our
security planning
for the different types of cloud environments, especially dealing with the
Cisco infrastructure.
Because once we get this thought process down and understood, dealing with the
Cisco infrastructure
for cloud security is going to be easy, I promise you. And we're going to be
able to implement
a lot of controls through API and all this other stuff, hints for stuff coming
up in the future. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But taking a look at our scenario, was it this way? I believe so, this way. Yep
, they're right there.
Our conditions were that we had an exchange server that was running inside of
the application
container for our roles and responsibilities for platform as a service. And we
also have a
vulnerability that's popped up that not only affects the actual exchange server
, but also windows.
Now you may be wondering, does such a vulnerability exist? And guess what? It
does. I put it on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
does. I put it on the
screen right there, CVE for us that notification, 2022, 41, 0, 4 is 0. I want
to put a link for it.
I'll below this video as well. And this was a vulnerability that not only
affected
the exchange server, but also messed with some of the system files for
correction inside of the
actual Windows server itself. So who's responsible? Well, this is a shared
responsibility and also a shared
risk as well. So it's going to be the customer's responsibility to be able to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
risk as well. So it's going to be the customer's responsibility to be able to
patch on the actual
exchange server side, but it's going to be the provider's responsibility to go
through and patch
on the Windows server side. Well, we have to be able to make sure that both the
exchange server and
the Windows server platform are patched and everything is good to go. So the
agreement has to be
made between the customer and the actual provider to not only do the actual
security patching,
but also the follow-up vulnerability assessments to make sure that CVE does not
exist anymore. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
exist anymore.
Or that other remediations have been
had to make sure that the vulnerability is no longer affecting the actual
clients. Because some
patches may not affect what we needed to and we put in ACLs or do other access
control lists,
like app blocker and things like that through policy. Many different things you
could do, but the
preferred method is that there's a vulnerability patch for it or a security
patch that you apply
that. And this is where we're going to have to definitely work together as a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that. And this is where we're going to have to definitely work together as a
team to make sure
that we understand this. And this kind of methodology applies to software as a
service and also
infrastructure as a service as well. And that's because if anything inside of
those other containers
that we're not in charge of are affected by a vulnerability that directly
affects us,
we're definitely only have to have that little come come together talk and make
sure that everything is
all cushy at the end of the day. Now, that being said, I want to close this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
all cushy at the end of the day. Now, that being said, I want to close this
skill out with a little
bit more of a perplexing question at the end of this particular skill. Other
than that, I hope this
been informative for you and I'd like to thank you for viewing.