Yep, it's been a while since the last update. But I'm still working on Zbrunk and think this project is very important. It stuck a bit, but I hope to make small commits every evening. I also changed the priorities. Now I think it would be better not to integrate with Grafana, but to create own dashboards and GUI. And to begin with, I created a simple interface for Searching (and Deleting) events. #flask #vuejs #zbrunk
It's becoming a good tradition to share my impressions about the Forrester Wave "Vulnerability Risk Management" report (here is one for Q1 2018). 😉 You can download a free reprint for Q4 2019 from Tenable website. This time I even edited the illustration a bit. I tried to show how the positions of vendors changed, which were added or removed. Please note that this is not official, it's just an extra layer that I added for fun.
What I liked:
The report has become much more adequate than last year. Traditional VM Big Three (Qualys, Tenable and Rapid7) are leaders. 👍🏻 Stagnant VM vendors have been pessimized or completely removed from the report. This is probably due to new and more adequate inclusion criteria: "product improvements over the last two years", "annual product revenue greater than $10 million", "VRM product was responsible for over 50% of their total revenue", "at least 100 enterprise customers", etc.
What I did NOT like (and this hasn't changed much since last year):
1. The main slogan of this report is "Prioritization And Reporting Are Key Differentiators". According to Forrester, Risk Prioritization is based on measuring vulnerabilities, assets and network segments. Well, I agree that Risk Prioritization is important. BUT (!) only when your Vulnerability Detection is perfect. This is clearly not the case at the moment! For proper Risk Prioritization it's necessary to understand the limitations of Vulnerability Scanners and how to obtain data for Asset and Network classification. Unfortunately, this report doesn't pay much attention to core functionality of VM products, it focuses on GUI, reports and high-level marketing features. The "vulnerability enumeration" is only 15% of overall weighting. It's really sad. 😔
2. Profile descriptions are based on marketing materials from vendors (BTW, such extract might be quite useful), and on some user quotes. These users also write about the reports and prioritization, like "custom reporting on individual business units was cumbersome" and "customers appreciate the new UI and strong reporting capabilities". It seems these users don't have (don't see/don't want to discuss) other problems.
3. Forrester mixes products that actually scan the network hosts with the products that only analyze imported data, perimeter-only services (why noto add over9000 ASV scanners than?) and scan services with "dedicated security specialist". The authors even write several times that some products "cannot be treated as a proper vulnerability management tool", so why do you include them in the report? 🤨
In any case, the report was better than last year. 🙂 I hope Forrester will make separate reports for the tools that actually detect vulnerabilities and tools that only aggregate&prioritize the vulnerabilities. It will also be great to change inclusion criteria and add smaller and more local VM vendors.
#Forrester #Brinqa #DigitalDefense #Expanse #KennaSecurity #NopSec #Outpost24 #Qualys #Rapid7 #RedSeal #RiskIQ #RiskSense #SkyboxSecurity #Tenable #BeyondSecurity #Tripwire #Symantec #BeyondTrust #IBM
What I liked:
The report has become much more adequate than last year. Traditional VM Big Three (Qualys, Tenable and Rapid7) are leaders. 👍🏻 Stagnant VM vendors have been pessimized or completely removed from the report. This is probably due to new and more adequate inclusion criteria: "product improvements over the last two years", "annual product revenue greater than $10 million", "VRM product was responsible for over 50% of their total revenue", "at least 100 enterprise customers", etc.
What I did NOT like (and this hasn't changed much since last year):
1. The main slogan of this report is "Prioritization And Reporting Are Key Differentiators". According to Forrester, Risk Prioritization is based on measuring vulnerabilities, assets and network segments. Well, I agree that Risk Prioritization is important. BUT (!) only when your Vulnerability Detection is perfect. This is clearly not the case at the moment! For proper Risk Prioritization it's necessary to understand the limitations of Vulnerability Scanners and how to obtain data for Asset and Network classification. Unfortunately, this report doesn't pay much attention to core functionality of VM products, it focuses on GUI, reports and high-level marketing features. The "vulnerability enumeration" is only 15% of overall weighting. It's really sad. 😔
2. Profile descriptions are based on marketing materials from vendors (BTW, such extract might be quite useful), and on some user quotes. These users also write about the reports and prioritization, like "custom reporting on individual business units was cumbersome" and "customers appreciate the new UI and strong reporting capabilities". It seems these users don't have (don't see/don't want to discuss) other problems.
3. Forrester mixes products that actually scan the network hosts with the products that only analyze imported data, perimeter-only services (why noto add over9000 ASV scanners than?) and scan services with "dedicated security specialist". The authors even write several times that some products "cannot be treated as a proper vulnerability management tool", so why do you include them in the report? 🤨
In any case, the report was better than last year. 🙂 I hope Forrester will make separate reports for the tools that actually detect vulnerabilities and tools that only aggregate&prioritize the vulnerabilities. It will also be great to change inclusion criteria and add smaller and more local VM vendors.
#Forrester #Brinqa #DigitalDefense #Expanse #KennaSecurity #NopSec #Outpost24 #Qualys #Rapid7 #RedSeal #RiskIQ #RiskSense #SkyboxSecurity #Tenable #BeyondSecurity #Tripwire #Symantec #BeyondTrust #IBM
Vulnerability Management and more
BTW, do you think there will be a new massive malware attack soon similar to WannaCry, but with the use of latest RDP RCE vulnerability (CVE-2019-0708)? Let's say during next 30 days.
Well, it's nice to recall this poll from May. 😉 It took ~ 6 months for #BlueKeep (CVE-2019-0708) to get a commercial exploit, then a free public exploit, and finally a first sample of malware that uses this vulnerability to deliver Monero cryptocurrency miner. Of course, this is not comparable to the WannaCry epidemics, and this malware seems to be successful in BSODing RDP honeypots mainly, but still. 🙂
What a crazy paranoid world we live in! Gitlab published the news that they will not hire people from Russia and China (by country-of-residence). At least for positions with access to sensitive data.
Eric Johnson, VP of Engineering at GitLab, calls this "a common practice in our industry in the current geopolitical climate". And the choice of only 2 countries is based on "concerns of several customers".
I am sure that #GitLab is not the only company with such country-of-residence block. But this is one of the few cases when it's discussed openly. I especially recommend to read several comments of Candice Ciresi, Director of Global Risk and Compliance at GitLab, in the thread where she criticizes this decision from both formal and rational points of view.
As for my opinion, I find absolutely ridiculous the idea that such measures will help to protect company from the insiders (who can be somehow pressured by state).
Eric Johnson, VP of Engineering at GitLab, calls this "a common practice in our industry in the current geopolitical climate". And the choice of only 2 countries is based on "concerns of several customers".
I am sure that #GitLab is not the only company with such country-of-residence block. But this is one of the few cases when it's discussed openly. I especially recommend to read several comments of Candice Ciresi, Director of Global Risk and Compliance at GitLab, in the thread where she criticizes this decision from both formal and rational points of view.
As for my opinion, I find absolutely ridiculous the idea that such measures will help to protect company from the insiders (who can be somehow pressured by state).
Anyone can be pressured. User siziyman commented in the thread: "I hope you do realize that there's no need for individual to be living within a certain state borders for that state to apply pressure to them, as long as they has family/friends or anyone/anything left to lose in that country. So if that is the concern to address, you'd have to discriminate by nationality (or even history of one's movement across countries - I do know American citizens, who lived or still live in Russia, have friends or family there)."
This is a pandora’s box. Today we see country-of-residence restrictions; tomorrow it will be country-of-origin restrictions or the fact that you have relatives in some wrong country, etc.
What if such a policy is will be applied everywhere? User jas88 commented: "Next week, the Chinese government would like a partition staffed only by Chinese nationals; the week after that, we get a European bank wanting 'EEA nationals only' for over-zealous GDPR compliance..."
I would like to see such data privacy problems to be solved technically. For example, with User Behaviour Analytics and Data Leakage Protection. The idea that you can eliminate the risk simply by not hiring people from some countries is stupid and unprofessional. But of course, GitLab has the right to do this.
BTW, don't use GitLab. Use Atlassian Bitbucket instead. 😉
This is a pandora’s box. Today we see country-of-residence restrictions; tomorrow it will be country-of-origin restrictions or the fact that you have relatives in some wrong country, etc.
What if such a policy is will be applied everywhere? User jas88 commented: "Next week, the Chinese government would like a partition staffed only by Chinese nationals; the week after that, we get a European bank wanting 'EEA nationals only' for over-zealous GDPR compliance..."
I would like to see such data privacy problems to be solved technically. For example, with User Behaviour Analytics and Data Leakage Protection. The idea that you can eliminate the risk simply by not hiring people from some countries is stupid and unprofessional. But of course, GitLab has the right to do this.
BTW, don't use GitLab. Use Atlassian Bitbucket instead. 😉
#GitHub recently introduced some great initiatives to improve the security of open-source products and libraries. They provided free access to CodeQL code analysis solution, created the global security research community GitHub Security Lab, became the CVE Numbering Authority (CNA) and provided a new way to apply for the CVE id directly from the GitHub interface. Moreover, they will automatically inform the affected projects if a vulnerability is found in some dependencies and will even make a pull request to fix the problem! And they will also scan for leaked credential tokens. Lots of great stuff!
GitHub made their own CVE-based Vulnerability Database with good mapping to commits and affected packages. The only thing is missing there - EXPLOITs.
And now the #Vulners Team makes it even better! Now you can search for GitHub advisories at Vulners and see the links to exploits in results. For example, for CVE-2019-13234. Cool, right? 😏
GitHub made their own CVE-based Vulnerability Database with good mapping to commits and affected packages. The only thing is missing there - EXPLOITs.
And now the #Vulners Team makes it even better! Now you can search for GitHub advisories at Vulners and see the links to exploits in results. For example, for CVE-2019-13234. Cool, right? 😏
Another piece of news about #Vulners (such a day). Well-known CDN provider #Cloudflare has just released the open-source network vulnerability scanner Flan Scan. What does it use under the hood to detect vulnerabilities? Yep, Vulners. 😉
"#FlanScan is a thin wrapper around #Nmap that converts this popular open source tool into a vulnerability scanner with the added benefit of easy deployment."
"We found that the “vulners” script, available on NSE, mapped the detected services to relevant CVEs from a database, which is exactly what we needed."
"The vulners script works by making API calls to a service run by vulners.com which returns any known vulnerabilities for the given service."
Features:
* Easy Deployment and Configuration (#docker, #kubernetes)
* Pushing results to the Cloud (Google Cloud Storage Bucket or an S3 bucket)
* Actionable Reports
The PDF reports look pretty good by the way 👍🏻
"#FlanScan is a thin wrapper around #Nmap that converts this popular open source tool into a vulnerability scanner with the added benefit of easy deployment."
"We found that the “vulners” script, available on NSE, mapped the detected services to relevant CVEs from a database, which is exactly what we needed."
"The vulners script works by making API calls to a service run by vulners.com which returns any known vulnerabilities for the given service."
Features:
* Easy Deployment and Configuration (#docker, #kubernetes)
* Pushing results to the Cloud (Google Cloud Storage Bucket or an S3 bucket)
* Actionable Reports
The PDF reports look pretty good by the way 👍🏻
Continuing the topic about perimeter services. As I mentioned earlier, I don’t think that the external perimeter services should be considered as a fully functional replacement for custom Vulnerability Management processes. I would rather see their results as an additional feed showing the problems your current VM process has. Recently I tested the Detectify’s Asset Inventory (Monitoring) solution, which provides such feed by automatically detecting the issues with your second, third (and more) leveled domains and related web services. Here's what they provide, and my basic API usage examples.
I tried the new #Kali Linux 2019.4 today. #XFCE as default desktop environment and fun "undercover" mode with Win10 GUI camouflage is great, but I was more interested in how #OpenVAS (it is now called #GVM) is supported there. The only available version is pretty old, #OpenVAS9.
However, it's old, but not obsolete (c). I was impressed by the setup script that updated plugins, made all the necessary configurations and launched OpenVAS fully automatically. Even problems with updating SCAP Data (because of rsync) did not cause the crash. The browser just opened and I could start scanning immediately. Those who tried to launch OpenVAS manually know how painful it is. In Kali it's amazingly user friendly. 🙂
root@kali:~# apt search openvasThe delay is two major versions (current - GVM11) and two years. It seems that if you want the latest version, you must build the code yourself or use unofficial builds. 😔
...
openvas/kali-rolling 9.0.3kali1 all
remote network security auditor - dummy package
...
However, it's old, but not obsolete (c). I was impressed by the setup script that updated plugins, made all the necessary configurations and launched OpenVAS fully automatically. Even problems with updating SCAP Data (because of rsync) did not cause the crash. The browser just opened and I could start scanning immediately. Those who tried to launch OpenVAS manually know how painful it is. In Kali it's amazingly user friendly. 🙂
A nice facepalming topic about HackerOne's own bug bounty program:
"On November 24, 2019, a Security Analyst tried to reproduce a submission to HackerOne’s program, which failed. The Security Analyst replied to the hacker, accidentally including one of their own valid session cookies". 🤦🏻♂️
Yep, it was in the curl request. This "hacker" successfully accessed the account of the analyst and got access to some vulnerability reports of HackerOne's customers ("bug bounty as a service"). He then submitted this issue and the company decided to pay him $20k bounty. Not bad, hah?
It is now debated whether this was the right decision to pay (I think it was). But IMHO it's more important to point out that "bug bounty as a service" might be dangerous. In fact it's a set of the most critical bugs of your organization, some of which, of course, have not been disclosed and fixed. And you can't really control who has access to them and how. So maybe it’s better to run it inhouse, although the costs will be higher. 😉
"On November 24, 2019, a Security Analyst tried to reproduce a submission to HackerOne’s program, which failed. The Security Analyst replied to the hacker, accidentally including one of their own valid session cookies". 🤦🏻♂️
Yep, it was in the curl request. This "hacker" successfully accessed the account of the analyst and got access to some vulnerability reports of HackerOne's customers ("bug bounty as a service"). He then submitted this issue and the company decided to pay him $20k bounty. Not bad, hah?
It is now debated whether this was the right decision to pay (I think it was). But IMHO it's more important to point out that "bug bounty as a service" might be dangerous. In fact it's a set of the most critical bugs of your organization, some of which, of course, have not been disclosed and fixed. And you can't really control who has access to them and how. So maybe it’s better to run it inhouse, although the costs will be higher. 😉