Vertical Vulnerability Managment

Vertical vulnerability managment is really, hopefully a term that we can come to understand as a reminder that essentially, there is more to vulnerability managment than what most employees may think, and they may quite rightly think of vulnerability managment as a relative concern, such as what does vulnerability managment mean to me as a service desk engineer, as a cloud engineer, as a developer, as security, as a site reliability engineer, so on and so fourth, and to a degree it means different things and parentally it means the same thing - confused ? It means different things to different departments but the goal is the same, vulnerabilities exist on all planes thats the parental principle of vertical vulnerability managment, but on each of these individual planes how and commonly where those vulnerabilitues are triaged and remediated is the nuance, let's break that down ...

Traditional Vulnerability Managment

We have end user compute, scanners on subnets, agents on supported endpoints, feeding into a dashboard collection is rendered output is actioned

Cloud Vulnerability Managment

This is actually more about the posture of the cloud configurations than anything else, config drift and relaxed settings, unhardened, this is an important space with less technical fixes and more processes and guidelines adheared too

Internet Landscape Vulnerability Managment

You've heard of attack surface reduction, this is that area, things facign the internet that have a much higher likelyhood of exploitation, usually a top priority in ransomware defence groups - it's an exciting space that often mirrors bleeding edge technology with bleeding edge defects in software

Engineering Vulnerability Managment

However your engineers and developers are operating they will probably have stacks that are often in need of updating, such as k8 clusters or other virtual / container images and infrastructures, that config and patching status all needs visibility and context to compliment the architecture enabling them the freedoms they need but the security confidence required to let them about their business, static image scanners, run time image scanners, source code scanners, vulnerability scanners for systems and application scanners for web and API, it all needs visibility, it all needs capturing.

Visibility Managment

Ensuring visibility is critical to confidence, for example; having a DNS Record stuard to ensure the right people know about creations, modifications and deletions will certainly help the attack surface reduction and allow security visibility over what entries are associated to what programs within the buisness, similarly, there needs to be security inclusion on visibility and immutability of assets that exist within the business, physical, digital or 3rd party services with trusts

Qualifying and Quantifying

You need strong players in each area covered, to work through the logic of how to react to concerns that present themselves, dont get too hung up on this year goal that year goal, if a concern is quantifiably bothering the majority of your council, the answer is to calm the collective. makesure there are well defined processees and proceedures cut out that tie in to any SLA that exists with internals and ideally externals, altho you may have some pre-existing contracts that negate that, there you will have to be able to articulate clear risk to your business as a result of thier inaction.

Doing lines

For each actionable concern you should be able to draw a line to a process that needs improving, this might not be as easy as 'do this better' but maybe more important to understand is it failing because what we have commited to is lipservice? is the failure cause or an effect ?

Very highlevel thoughts, but a rant worth sharing. the details ommited are heavily context driven, but the principle is here right ?