Back to Basics: Vulnerability Management with Virtual Machines and Containers
Back to Basics: Vulnerability Management with Virtual Machines and Containers
Over the last few years, common vulnerabilities and exposures (CVEs) in software have caused disruption in the IT industry. With evolving technologies and developer tools, managing vulnerabilities can be a complex task. Join Pratima as she breaks down this complexity and explores how to build a vulnerability management solution in a hybrid environment with servers, EC2 instances, and container images in an automated way.
Additional Resources:
Orchestrating multi-step, custom patch processes using AWS Systems Manager Patch Manager (AWS blog post): https://aws.amazon.com/blogs/mt/orche…
AWS Security Hub workshop: https://catalog.us-east-1.prod.worksh…
AWS Security Hub Automated Response and Remediation Solutions Implementation: https://aws.amazon.com/solutions/impl…
How to Setup a Recurring Security Hub Summary Email: https://github.com/aws-samples/aws-se…
Check out more resources for architecting in the #AWS cloud:
http://amzn.to/3qXIsWN
#AWS #AmazonWebServices #CloudComputing #BackToBasics #HybridCloud
Content
6.88 -> Welcome to another episode
of 'Back to Basics', everyone.
10.32 -> I'm Pratima Singh,
11.52 -> and I am here today to talk to you
about vulnerability management
15.92 -> but in an automated way.
17.8 -> Now, why, you might ask?
19.66 -> Well, in recent years, vulnerabilities
have taken the IT community by storm.
25.34 -> Every year there's a record-breaking number of vulnerabilities
28.92 -> that are recorded.
30.58 -> And with a number of application
development frameworks in play
34.06 -> and operating systems,
35.76 -> it can be a real struggle
to patch systems and applications.
40.56 -> But before we dive deeper,
let's form a collective understanding
44.24 -> of what vulnerabilities really are.
47.6 -> Vulnerabilities
don't just magically appear.
50.8 -> They have existed ever since software has.
54.22 -> As with most things,
we humans create them.
57.68 -> They are in the software we write
and in the configurations we build.
62.22 -> A large portion of vulnerabilities
64.18 -> is recorded
in the software that other humans write,
67.58 -> and such software
includes third party libraries
70.4 -> and operating systems
that help us run applications on servers.
74.86 -> And a major portion
of these vulnerabilities
77.22 -> is recorded in operating systems.
80.04 -> Now, earlier on in my career,
when I was a Systems Engineer,
83.64 -> I was responsible
for managing 100 plus servers
86.7 -> and deploying
applications on those servers.
89.7 -> Now, every so often I would
get informed about security updates
93.92 -> that I needed to install on those servers.
96.66 -> It used to take me hours, if not days,
99.46 -> to iterate over the inventory,
manually install updates on the servers,
104.02 -> build manual reports
and reach out to my leads for approval.
108.16 -> And even then, almost always,
I would have missed out a few servers.
113.52 -> Now as much as I could,
I automated the whole system
116.4 -> by building scripts that I would
manually run on those servers.
119.86 -> But then it took me time
to build the reports manually
122.86 -> and also testing because it added
members of the other team to test
127.04 -> and the security
teams for the final approval.
130.3 -> Now, involving other team
members added to the lead time.
134.82 -> As I started using AWS,
137.22 -> I came across
the AWS Systems Manager service.
141.76 -> AWS Systems Manager - That was a game changer for me.
144.42 -> I could manage on-premises servers
and Amazon Elastic Compute Cloud
148.7 -> or EC2 Instances alike
by installing a single agent.
153.56 -> Once the Amazon-SSM-agent was installed
156.62 -> servers and EC2 instances,
159.26 -> essentially the whole
inventory that I managed manually
162.04 -> was discovered
automatically as managed nodes.
166.16 -> With the inventory sorted,
167.76 -> I moved my attention to the Patch Manager.
170.92 -> I could ditch all my makeshift scripts
173.58 -> and use predefined patch baselines
175.92 -> for a range of Linux-based
and Windows operating systems,
179.74 -> including adding approval rules,
a task I used to manage manually.
185.48 -> Now, this reduced the time
I spent on managing patches on servers
189.8 -> to a matter of hours.
191.62 -> Now, as I explored
this service more and more,
194.68 -> I came across the feature
to schedule patching runs
197.92 -> using the maintenance Windows feature.
200.88 -> Now, I no longer had to sit
202.94 -> looking at installations
being done on server by server manually,
207.08 -> and the Patch Manager dashboard
208.98 -> gave me the compliance report automatically
211.66 -> that I used to spend hours
building to get my leads approvals.
216.6 -> As the development teams
started to work with containers,
220.14 -> it became an interesting challenge
221.86 -> to manage
vulnerabilities with Container Images.
225.16 -> Container Images
can be easily overwritten,
227.98 -> which can lead to loss of context
229.9 -> with changes along
with a layer development approach,
233.12 -> which can result
in vulnerabilities hiding in the layers
236.54 -> and only detectable
in the container run-time.
240.36 -> Interestingly, teams could
turn on the tag Immutability feature
244.34 -> in Amazon Elastic Container Registry
or Amazon ECR
248.3 -> to ensure that a container Image
cannot be overwritten by another image
253.46 -> using the same tag
but with different contents.
257.22 -> This ensured uniqueness
of each image pushed to the repository.
262.84 -> Now the teams could
also configure scanning of images
266.22 -> either on push or continually.
269.08 -> But the security team
wanted a single pane of glass view
272.42 -> of the security posture of the entire
IT environment in their organization.
277.44 -> Now, this is where Amazon Inspector
and AWS Security Hub, came in.
282.72 -> Now ECR forwards
all findings to Inspector,
286.68 -> which is an automated
vulnerability management service.
290.62 -> AWS Security Hub
natively integrates with AWS services
295.36 -> like Patch Manager and Amazon Inspector.
299.16 -> It supports cross-account
and cross-region aggregation.
303.06 -> Once all the findings
are consolidated in Security Hub,
306.86 -> the security team
could build insights, alerts,
310.24 -> and even trigger auto-remediation actions
313.14 -> using the custom actions
feature of Security Hub.
317.08 -> Now with Security Hub,
we have been able to tie
319.9 -> our vulnerability management solution
322.14 -> into a neat bow.
324.44 -> Now, in this episode,
325.96 -> we saw how we could build
a vulnerability management solution
329.12 -> in a hybrid environment with servers,
331.76 -> Amazon EC2 instances and Container Images.
335.44 -> We've used services
like AWS Systems Manager,
339.1 -> Amazon ECR,
Amazon Inspector, and AWS Security Hub.
344.6 -> Check out the links
below for more details.
347.3 -> See you next time.
Source: https://www.youtube.com/watch?v=Do6Yk9Dsvc4