Before
An engineer manually read Fortinet and Palo Alto advisories, interpreted affected version ranges, and compared them with device inventory and approved firmware baselines. The engineer then checked for existing incidents, assembled affected-device details, and proposed replacement versions when a baseline was exposed.
How it works
- Collect requested or recent firewall advisories together with observed device firmware, approved baselines, existing incidents, and the network security group.
- Match affected versions to deployed devices and baselines, applying CVSS thresholds, branch-aware remediation rules, and explicit checks for missing evidence or unavailable sources.
- Create one incident per qualifying advisory when no active duplicate exists, save proposed baseline changes for manager review, and return a consolidated summary.
Workflow details
- Collect advisories and evidence: The flow starts from a secure webhook and is documented for daily execution at 07:15 Europe/Paris. It collects relevant Fortinet and Palo Alto advisories, observed firmware versions, approved firmware baselines, existing active incidents, and the responsible network security group.
- Select and normalize findings: Requested advisories are reviewed even when they are absent from the normal feed; otherwise, recent advisories affecting the supported product lines are selected. Fortinet affected-version lists and remediation guidance are combined with Palo Alto branch-specific fixed-version bounds, including cumulative fixes.
- Apply exposure rules: Each advisory is compared with deployed devices and approved baselines. Advisories with CVSS 7 or higher and affected equipment qualify for an incident, while an affected approved baseline with CVSS 5 or higher creates a proposed replacement version for review.
- Create the handoff: The flow checks for an existing active incident before requesting one incident per advisory, including affected configuration items, versions, remediation details, and due-date information. Proposed baselines are recorded as new versions, and the final summary reports advisories, tickets, proposals, unavailable sources, or missing firmware evidence.
What changed
Exposure analysis, duplicate checking, incident preparation, and baseline proposal recording now happen in one review. Security staff receive scoped incidents automatically, while proposed firmware changes remain subject to NetSec manager validation rather than being applied automatically.
Work removed
Manually selecting advisories, reading affected-version documents, comparing firmware ranges with device records, checking for duplicate incidents, compiling affected-device lists, and retyping proposed baseline changes.
Expected outcome
Conservatively, each run removes at least four recurring manual review actions—advisory selection, version comparison, duplicate-incident checking, and affected-device list retyping—while producing a traceable security handoff.
