Menu Close

Vulnerability Management

Want to improve your Vulnerability Management process?

Are you :
  • Struggling to prioritise vulnerabilities to reflect the real risk to you in your environment?
  • Emailing spreadsheets of issues around?
  • Manually creating tickets to get things done?
  • Fighting to reconcile what has been remediated vs what is outstanding
  • Manually verifying remediation / tickets getting closed when remediation not complated

What is your level of Vulnerability Management maturity?

Would you like to automate the process from scan orchestration, through prioritisation, ticket creation and ticket closure?

Would you like to focus on the exceptions, rather than running the process?

Would you like to improve the maturity of your VM process?

How can the tools we provide help?

vulnerability management animation

How does Brinqa do this?

Leverage your existing scanning technology, (Tenable, Rapid7, Qualys, IBM, HP, CA, PortSwigger etc.) and bring in all of scan data that you can find.

Augment asset data with information about the server. This typically comes from CMDBs, AD, Excel or other sources so that Brinqa knows what is part of your PCI-DSS estate, where your SAP servers are, what is business critical, what is internet facing etc.

If you have a threat intel. feed that knows about exploits under development, then add that to the mix.

If you have a threat intel. feed that knows about exploits under development, then add that to the mix.

Now that we have business context we can prioritise each vulnerability based on the risk to you. This is a big formula that has been developed over the years and looks at 10+ metrics to build the priority. This means that the same vulnerability on 2 different servers will have 2 different risk scores.

In an ideal world we would fix every vulnerability; in the real world we fix the ones with the highest impact in your environment, i.e. the ones with the highest risk score. Now we have a reliable score, we use it.Tickets of different types can go to different ticketing systems; “patch” type tickets could go to Service Now, while “application issue” type tickets could go to Jira, because different groups use different tools.

You already have at least one ticketing system, so we create tickets in it to accomplish the remediation.  We could create 1 ticket per vulnerability per server, most people create 1 ticket per fix, or group even further.  You can have different rules for different things, this is all configurable via the GUI.

Some customers want their infrastructure issues in Service Now, and their application issues in Jira, again no problem.

You could ask staff to close tickets when work has been remediated.  Most companies trigger a re-scan and use that to validate remediation.

Many scanners don’t report that something has been fixed, they are simply quiet on the matter, this is not an issue, Brinqa keeps track of these items.

What's Next

See Brinqa in action with a recorded demo
Talk to us to see how Brinqa could help improve your process