Security Orchestration, Automation and Response (SOAR) is a set of functionalities used by the SOC team to automate security activites, improve workflow management and share threat intelligence data. Security Operation Centres (SOCs) can leverage SOAR to gain in-depth knowledge of the threats they face, trigger automatic responses to security issues and achieve better efficiency. In this series of blog posts we’ll delve deeper into the topic, understanding how both the Würth Phoenix SOC team and customers can benefit from it. The first topic I’d like to cover is the Vulnerability Management process. 🚀
For a Vulnerability Management process to take place we must start from a Vulnerability Assessment (VA), a systematic review of security vulnerabilities and weaknesses present in an information system.
We perform a monthly VA on the public perimeter of our SOC customers, leveraging the widely used Greenbone Vulnerability Management tool. We then export the results to a .csv and a .pdf file and share them with the customer through a dedicated Confluence space.
It’s nice, isn’t it? But the best thing is that this is only the beginning.
We use the Atlassian Jira ticket platform to communicate with customers. Tickets related to security issues, generated both by our SOC and our CTI platform SATAYO, are opened there. Thus we also added tickets from VA results there. How? Read below 😉
Starting from the VA .csv, Jira tickets are automatically created for vulnerabilities with a CVSS score >= 5. These are issues classified as medium-high severity. Customers can use them to keep track of their mitigations, with one of the several status types available. The ticket contains information about the detected vulnerability and the list of vulnerable targets.
Every opened ticket starts in the Vulnerable status. There are no restrictions between status types, and clients can can switch them several times. Blue status types are considered in progress, while green status types are considered closed. If, during a re-scan, the same vulnerability is still present in the infrastructure, we directly update the corresponding ticket by adding a new comment, even if it’s in one of the closed status types.
Beautiful, isn’t it? And we also have something else.
Elastic is our SIEM (Security Information and Event Management), the place where all the collected logs are searchable. We can perform queries on data there, and create awesome dashboards and cool reports.
After the Jira ticket has been created, we also upload the VA results to Elastic. The initial .csv is ingested by the SIEM in a dedicated index. In this way, all VA results are organized in the same place. We have created a comprehensive and dynamic dashboard to facilitate interaction with the end user:
From the top line, the customer can filter the vulnerabilities and see the results broken down by IP, network, VA report, status, severity and so on. Furthermore, there’s a link that redirects to the Jira platform to see the tickets there.
The process I just explained is completely automatic, you have just witnessed one of our SOAR functionalities. To achieve this, several scripts work together… but what happens if something goes wrong? We rely on a monitoring platform that alerts us when our automated processes encounter errors. It’s called NetEye, maybe you’ve already heard of it. 😜
That was all for today, see you next time 😀
Did you learn from this article? Perhaps you’re already familiar with some of the techniques above? If you find cybersecurity issues interesting, maybe you could start in a cybersecurity or similar position here at Würth Phoenix.