Lion Cipher Lab
Write a patch management policy
- GRC / Compliance
- Beginner
- ~50 min
- Free · no account required
Why it matters
One of the most common ways attackers get into systems is embarrassingly simple: the software had a known flaw, the vendor had already released a fix, and nobody applied it in time. That fix is called a patch, the flaw is called a vulnerability, and the written rule that says how fast you must apply which fixes -- and who decides -- is a patch management policy. It is one of the highest-leverage documents in security because it closes doors that are already known to be open: the attacks it prevents are not exotic zero-days but old, published holes that were left unpatched for weeks or months.…
What you'll learn
- what a patch is and what a vulnerability is
- why unpatched software is one of the most common ways in for attackers
- the difference between a policy and a procedure
- what severity means (CVE / CVSS: critical, high, medium, low)
- what an SLA is and how a risk-based patch timeline works
- building a severity -> timeline SLA table
- defining asset scope -- what the policy actually covers
- testing a patch before you deploy it, and why
- emergency / out-of-band patching for actively exploited flaws
- writing exceptions that expire instead of becoming permanent
Steps in this lab
- What a patch is, what a vulnerability is, and why this policy exists
- Policy vs procedure, and severity: the two ideas you need first
- Open a document and lay out the policy skeleton
- Define the scope -- what this policy actually covers
- Build the SLA table -- severity in, deadline out
- Testing before deployment -- and the honest home exception
- Emergency / out-of-band patching
- Exceptions -- for the patch you genuinely cannot apply yet
- Verification -- confirm the patch actually landed
- What you built, and the mindset to keep