Now let's think how we can protect ourselves and make the Vulnerability Management process in the organization better.
When we have a serious IT security incident related to some unpatched vulnerability, this could happened because:
1) we did not find this vulnerability during the Vulnerability Assessment procedures 🤪🙈
or
2) we found it, but for some reason the issue was not fixed properly and on time 🤦🤷♂️
When we have a serious IT security incident related to some unpatched vulnerability, this could happened because:
1) we did not find this vulnerability during the Vulnerability Assessment procedures 🤪🙈
or
2) we found it, but for some reason the issue was not fixed properly and on time 🤦🤷♂️
What if we did NOT find this vulnerability, what could be the reason?
1) Maybe this host was not in our Vulnerability Management scope and we simply did not scan it? Who is responsible for updating the scope? Maybe someone told us that we can't scan such systems, because they are too critical and sensitive?
2) Maybe we scanned this host but not very often, so the vulnerability was exploited before we had a chance to detect it? Why didn't we scan this host several times in a week? Who limited our scan rate?
3) Maybe we scanned the host with our vulnerability assessment tool, but there were no this vulnerability in the scan results? Did we scan with the authentication and had all the necessary permissions? If not, then who limited them and why?
Dealing with the hosts we have to assess, scan credentials and permissions, scan rate, etc. are the parts of a bigger Asset Management process, we should have it at least.
1) Maybe this host was not in our Vulnerability Management scope and we simply did not scan it? Who is responsible for updating the scope? Maybe someone told us that we can't scan such systems, because they are too critical and sensitive?
2) Maybe we scanned this host but not very often, so the vulnerability was exploited before we had a chance to detect it? Why didn't we scan this host several times in a week? Who limited our scan rate?
3) Maybe we scanned the host with our vulnerability assessment tool, but there were no this vulnerability in the scan results? Did we scan with the authentication and had all the necessary permissions? If not, then who limited them and why?
Dealing with the hosts we have to assess, scan credentials and permissions, scan rate, etc. are the parts of a bigger Asset Management process, we should have it at least.
If we did everything as Vulnerability Management vendor recommends, including the up-to-date scanner engine and detection rules, and have not detected this vulnerability, the vulnerability assessment tool is probably not good enough and there are some questions how did chose it and who made the final decision to buy this garbage. 🤔
So, to protect yourself:
-> track the hosts, credentials and regular scans; collect the evidence for each external requirement (most likely from your IT team) that limits your Vulnerability Assessment capabilities and make them all visible;
-> check the capabilities of your Vulnerability Assessment tool, use several different tools if it is possible.
So, to protect yourself:
-> track the hosts, credentials and regular scans; collect the evidence for each external requirement (most likely from your IT team) that limits your Vulnerability Assessment capabilities and make them all visible;
-> check the capabilities of your Vulnerability Assessment tool, use several different tools if it is possible.
What if we found this vulnerability, but for some reason it was not fixed properly and on time, what could be the reason?
1) Maybe IT administrators were not informed about this vulnerability? Obviously, if you want to update some vulnerable hosts, you must inform the responsible team of IT administrators about the problem. Things like "go to the web GUI of our great Vulnerability Management tool and find yourself what you have to patch" usually don't work. People want to know what exactly they have to do and why. Usually it is necessary to create some separate remediation tasks for each case and assign them to specific groups of IT administrators/devops. Just to make harder for them to ignore the problem. 😏 It's great if you made a mutual agreement to run the process without all these tasks (perhaps by using reports or dashboards instead), but make sure that it really works.
1) Maybe IT administrators were not informed about this vulnerability? Obviously, if you want to update some vulnerable hosts, you must inform the responsible team of IT administrators about the problem. Things like "go to the web GUI of our great Vulnerability Management tool and find yourself what you have to patch" usually don't work. People want to know what exactly they have to do and why. Usually it is necessary to create some separate remediation tasks for each case and assign them to specific groups of IT administrators/devops. Just to make harder for them to ignore the problem. 😏 It's great if you made a mutual agreement to run the process without all these tasks (perhaps by using reports or dashboards instead), but make sure that it really works.
2) Maybe IT administrators don't have formal requirements to fix such vulnerabilities in N days? If you have to prove that each vulnerability in the report is critical and exploitable or it won't be fixed, you will get huge amount of unnecessary work that can't be easily automated. It will be much easier for you if the IT administrators will have to patch vulnerabilities that match some formal criteria without asking additional questions, like, for example, PCI DSS requires us to do. These requirements should be added to the Security Policy of the organization. If you do this, it will be possible just to track the remediation tasks and send the reminders to the teams that are out of schedule. Otherwise continuous manual proofing and pushing will take all the time and efforts of security analysts.
3) Maybe IT administrators said that vulnerability can't be fixed? There would be some vulnerabilities that can't be fixed by a simple update and you should be ready to offer compensational measures and control the implementation of such measures. If nothing can be done, you should at least collect formal rejections from for the responsible IT administrators. All the rejections should be carefully documented and all stakeholders should be informed, so it would be possible to use this data in the case of real incident. Will this really protect you (a security analyst) in such case? Not really. But at least it makes the responsible people think about the possible consequences. Even if there were a decision to ignore some vulnerability and the risks were taken, you should still regularly update the status for each host, because in future circumstances and the final decision may change.
As you can see, Vulnerability Management process requires a lot of communication with IT teams responsible for the remediation. It looks like continuous selling "the need of patching" to your IT guys. Like any sale sometimes it goes easily, sometimes it requires a lot of pushing and discussing. The thing is that the Vulnerability Management vendors usually don't see this part of job and when you try to implement the VM process in your particular organization you face this problems alone and have to create something like a CRM system or it simply won't work. 🙂
So, to protect yourself:
-> try to make a formal requirement in the organization "critical vulnerabilities should be fixed in N days";
-> make specific remediation tasks that couldn't be missed or misinterpreted by the teams of IT administrators;
-> track how quickly the teams of IT administrators close these tasks and if they don't meet the schedule - discuss and escalate the issue, if necessary;
-> track the implementation of countermeasures and all the rejections.
Remember, an ability of IT teams to patch their systems relatively quickly is crucial and without it all other metrics and prioritizations don't make much sense.
3) Maybe IT administrators said that vulnerability can't be fixed? There would be some vulnerabilities that can't be fixed by a simple update and you should be ready to offer compensational measures and control the implementation of such measures. If nothing can be done, you should at least collect formal rejections from for the responsible IT administrators. All the rejections should be carefully documented and all stakeholders should be informed, so it would be possible to use this data in the case of real incident. Will this really protect you (a security analyst) in such case? Not really. But at least it makes the responsible people think about the possible consequences. Even if there were a decision to ignore some vulnerability and the risks were taken, you should still regularly update the status for each host, because in future circumstances and the final decision may change.
As you can see, Vulnerability Management process requires a lot of communication with IT teams responsible for the remediation. It looks like continuous selling "the need of patching" to your IT guys. Like any sale sometimes it goes easily, sometimes it requires a lot of pushing and discussing. The thing is that the Vulnerability Management vendors usually don't see this part of job and when you try to implement the VM process in your particular organization you face this problems alone and have to create something like a CRM system or it simply won't work. 🙂
So, to protect yourself:
-> try to make a formal requirement in the organization "critical vulnerabilities should be fixed in N days";
-> make specific remediation tasks that couldn't be missed or misinterpreted by the teams of IT administrators;
-> track how quickly the teams of IT administrators close these tasks and if they don't meet the schedule - discuss and escalate the issue, if necessary;
-> track the implementation of countermeasures and all the rejections.
Remember, an ability of IT teams to patch their systems relatively quickly is crucial and without it all other metrics and prioritizations don't make much sense.
Yep, I finally added support for simple search requests in #Zbrunk. 😅 You can get the events by event_type and time range. You can also delete these events if you set
Currently it works quite primitively. I just make the mongo find (or remove) during the processing of POST request 🤦♂️. So, it will most likely crash if you try to process too many events at once. BUT I hope that it will be enough to start building some dashboards with it 🙃.
delete: "True" in the search request. See the examples in "MANUAL -> Test cases".Currently it works quite primitively. I just make the mongo find (or remove) during the processing of POST request 🤦♂️. So, it will most likely crash if you try to process too many events at once. BUT I hope that it will be enough to start building some dashboards with it 🙃.
The news that Rostelecom (Solar) will begin to provide Qualys Vulnerability Management services (rus) probably doesn't mean much on a global scale, but it's quite interesting for Russian market and for markets of other "countries with strict data sovereignty rules".
What problems we have with global cloud-based security solutions, including Vulnerability Management solutions? When the data about vulnerabilities of Russian organizations is stored and processed somewhere abroad and it is not clear how and by whom, (even if we are not even talking about the real threats) it's is a red flag for government regulators, like FSTEC. And they can easily make the usage of such services VERY complicated, at least among the customers that are somehow related to the government. The same restrictions stimulate the development of local security products, that's why we have local players on Russian #VulnerabilityManagement market, like Positive Technologies, Altx-Soft, NPO Echelon, etc.
What problems we have with global cloud-based security solutions, including Vulnerability Management solutions? When the data about vulnerabilities of Russian organizations is stored and processed somewhere abroad and it is not clear how and by whom, (even if we are not even talking about the real threats) it's is a red flag for government regulators, like FSTEC. And they can easily make the usage of such services VERY complicated, at least among the customers that are somehow related to the government. The same restrictions stimulate the development of local security products, that's why we have local players on Russian #VulnerabilityManagement market, like Positive Technologies, Altx-Soft, NPO Echelon, etc.
BUT when a foreign security vendor delivers its solution in a form of Private Cloud through the largest Russian service provider, which also has Russian state as the main shareholder, it's is a different story. Data will be stored and processed in Russia, US vendor only updates the cloud platform, so what's the problem? If it will be needed, Rostelecom has enough resources to get all necessary certificates for this cloud service, and may re-label it as their own.
Currently it is not clear how much the offer from #Rostelecom will differ from the standard #Qualys services. Details of the deal are not publicly known. Will Rostelecom pay Qualys a fix, and Rostelecom will then try to monetize it? Will Qualys and Rostelecom share money from the actual customers somehow? Will Qualys pay Rostelecom for hosting, and the money from customers will go directly to Qualys? It's unclear now. Most likely 1 or 2, but they could agree on a very different terms. 🙂
But in any case, the domestic Russian Vulnerability Management market might be shaken. And I think it's great. At least for the end-users. 🙂 And when Tenable will someday release their own Private Cloud with Tenable.io, it will be even better. 😉
Currently it is not clear how much the offer from #Rostelecom will differ from the standard #Qualys services. Details of the deal are not publicly known. Will Rostelecom pay Qualys a fix, and Rostelecom will then try to monetize it? Will Qualys and Rostelecom share money from the actual customers somehow? Will Qualys pay Rostelecom for hosting, and the money from customers will go directly to Qualys? It's unclear now. Most likely 1 or 2, but they could agree on a very different terms. 🙂
But in any case, the domestic Russian Vulnerability Management market might be shaken. And I think it's great. At least for the end-users. 🙂 And when Tenable will someday release their own Private Cloud with Tenable.io, it will be even better. 😉
H.R.2810 - National Defense Authorization Act for Fiscal Year 2018. IMHO, it's a great lesson for any foreign cybersecurity vendor who wants to work in a free and completely competitive US market. 😏 No matter how many Transparency Centers you open and how global you are, it will be possible to label you as 'Evil Russians' (or Chinese, Iranians, Koreans, whatever) and ban without any real evidence. IMHO, this is nothing more than lobbying and protectionism. #kaspersky
I decided to publish my simple console Password Manager. I called it barapass (github). I've been using It for quite some time in Linux and in Windows (in WSL). Probably it will also work natively in Windows and MacOS with minimal fixes, but I haven’t tried it yet.
I've also described in my blog:
* Why do people use password managers?
* How to use barapass? (installation, encrypting and decrypting files, earching in encrypted file)
* Is it safe to copy passwords to clipboard?
Read here: https://avleonov.com/2019/09/17/barapass-console-password-manager/
#barapass #concept #AES #CLI #crypto #Linux #password #python #python3 #WSL #xclip
I've also described in my blog:
* Why do people use password managers?
* How to use barapass? (installation, encrypting and decrypting files, earching in encrypted file)
* Is it safe to copy passwords to clipboard?
Read here: https://avleonov.com/2019/09/17/barapass-console-password-manager/
#barapass #concept #AES #CLI #crypto #Linux #password #python #python3 #WSL #xclip
Hi guys! You are not my personal army, but can I ask you to vote for me ("Александр Леонов aka Беспощадный Эксперт") below? 🙂
One of the best satirical telegram channels about Russian Information Security community organizes "voting battles" between security bloggers, speakers and well-known company leaders. For some reason they put me there as well. 😅 Unlike most "participants", who just ignore all this mess, I find this a fun and completely free way to promote what I do. So, please vote for me and ask your friends to vote as well! 🗳✌️
And if you speak Russian, subscribe to @rusecmedia, some of their jokes are just hilarious.
One of the best satirical telegram channels about Russian Information Security community organizes "voting battles" between security bloggers, speakers and well-known company leaders. For some reason they put me there as well. 😅 Unlike most "participants", who just ignore all this mess, I find this a fun and completely free way to promote what I do. So, please vote for me and ask your friends to vote as well! 🗳✌️
And if you speak Russian, subscribe to @rusecmedia, some of their jokes are just hilarious.
Forwarded from rusecmedia
Долго не могли пригласить Александра, говорит, что был в блоггерской командировке по Фейсбуку.
Forwarded from rusecmedia
Кто победит?
Anonymous Poll
65%
Александр Леонов aka Беспощадный Эксперт
35%
Дмитрий Мананников aka BLOG KILLER
It’s not so obvious that socks servers with authentication are a necessary thing:
1. You can run a “local socks service” simply by connecting to a remote host via ssh (with -D <port>)
2. Most of software products, that support socks, don’t support socks servers with authentication
The last fact I find very unfortunate, because using socks without having to monitor ssh connection is much more comfortable. But if the software actually supports socks with authentication you can try Dante server.
Here’s how to install and configure it in CentOS 7: https://avleonov.com/2019/09/23/dante-socks5-server-with-authentication
#CentOS #Dante #SOCKS #SOCKS5
1. You can run a “local socks service” simply by connecting to a remote host via ssh (with -D <port>)
2. Most of software products, that support socks, don’t support socks servers with authentication
The last fact I find very unfortunate, because using socks without having to monitor ssh connection is much more comfortable. But if the software actually supports socks with authentication you can try Dante server.
Here’s how to install and configure it in CentOS 7: https://avleonov.com/2019/09/23/dante-socks5-server-with-authentication
#CentOS #Dante #SOCKS #SOCKS5
Pretty nice GUI feature in the latest #Nessus Professional 8.7.0. Now you can select a host or hosts in the scan results and create a new scan based on a different Scan Template/Policy. For example, you can perform a fast discovery scan, filter some hosts and then scan them deeply with authentication. Other features of this release are about Nessus Manager and Essentials, so not very interesting for me. 🙂 #Tenable
Features in the GUI are certainly pleasant, but the real game changer in Vulnerability Management, IMHO, will be automated patching for a reasonable price. It is much better when you do not just say that some systems are vulnerable but fix these problems with one click. At least most of them.
So, it's great that some VM vendors work on this. For example, 2 weeks ago #Qualys released a new 1.3 version of Patch Management module. It seems from the changes list that they understand: Windows patching is not only about the actual installation of the patches. It is also about:
- Catching the right time for patching. Now in Qualys you can choose "None" for Patch Window and install the emergency patch as soon as possible; patches can be also pre-downloaded before the job start to save some time.
- Changes in the registry and other reconfigurations.
- Reboots. Now in Qualys you can suppress reboot notification and reboot the host immediately after the patch deployment.
These are steps in the right direction.
So, it's great that some VM vendors work on this. For example, 2 weeks ago #Qualys released a new 1.3 version of Patch Management module. It seems from the changes list that they understand: Windows patching is not only about the actual installation of the patches. It is also about:
- Catching the right time for patching. Now in Qualys you can choose "None" for Patch Window and install the emergency patch as soon as possible; patches can be also pre-downloaded before the job start to save some time.
- Changes in the registry and other reconfigurations.
- Reboots. Now in Qualys you can suppress reboot notification and reboot the host immediately after the patch deployment.
These are steps in the right direction.
The main thing that upsets me in #CentOS8 (that was finally released 4 days ago) is the lack of alternative desktop environments in repositories, even in EPEL. There is only a sloooow Gnome 3 with terrible junk animations that I REALLY hate. 😢
And now I am thinking what is better: to put up with Gnome (at least for a while) and patiently wait for my favourite #XFCE in EPEL (there is a request for this), to install XFCE from the source (it seems difficult) or try to install some other minimalistic DE from source... 🤔
I doubt that there are many people who use #CentOS as a Desktop OS, but if there are any, I would be happy to hear your opinion at https://t.iss.one/avleonovchat.
And now I am thinking what is better: to put up with Gnome (at least for a while) and patiently wait for my favourite #XFCE in EPEL (there is a request for this), to install XFCE from the source (it seems difficult) or try to install some other minimalistic DE from source... 🤔
I doubt that there are many people who use #CentOS as a Desktop OS, but if there are any, I would be happy to hear your opinion at https://t.iss.one/avleonovchat.
I just saw a nice post by #JSOC (in Russian) about the new version of #Troldesh cryptolocker cyberattack. This time attackers use legitimate but compromised #WordPress websites in phishing.
The links look pretty normal:
Since these sites are legit and have a good reputation, it's quite difficult to detect and block emails with such links.
This is another good reason to update the vulnerable CMS as soon as possible, since the malware distribution can be even more dangerous for your business than the compromisation of the site itself.
#cryptolocker #phishing
The links look pretty normal:
Horsesmouth[.]org/wp-content/themes/InspiredBits/images/dummy/doc/doc/www.montessori-academy[.]org/wp-content/themes/campus/mythology-core/core-assets/images/social-icons/long-shadow/doc/chestnutplacejp[.]com/wp-content/ai1wm-backups/doc/Since these sites are legit and have a good reputation, it's quite difficult to detect and block emails with such links.
This is another good reason to update the vulnerable CMS as soon as possible, since the malware distribution can be even more dangerous for your business than the compromisation of the site itself.
#cryptolocker #phishing
Continuing the topic about the Qualys PM feature, I REALLY want to see the universal fully automated #PatchManagement (and therefore #VulnerabilityManagement), but I DON'T think we are close to that.
1. It is difficult to formalize all the steps that are necessary for patching. There are thousands of third-party software products (especially for Windows desktops). Even to get information about all the vulnerabilities in all these products is hard, getting the actionable and formal remediation instructions for them is even harder, and it's almost impossible to follow these instructions automatically and in a reliable way.
2. Patches sometimes break systems. It just happens. In a common human-driven process, there will always be a responsible person, who has not performed all necessary tests before actual patching and has not discussed the possible consequences with the system owner. In a fully automated process, you only have a PM product and the vendor who does not guarantee anything.
1. It is difficult to formalize all the steps that are necessary for patching. There are thousands of third-party software products (especially for Windows desktops). Even to get information about all the vulnerabilities in all these products is hard, getting the actionable and formal remediation instructions for them is even harder, and it's almost impossible to follow these instructions automatically and in a reliable way.
2. Patches sometimes break systems. It just happens. In a common human-driven process, there will always be a responsible person, who has not performed all necessary tests before actual patching and has not discussed the possible consequences with the system owner. In a fully automated process, you only have a PM product and the vendor who does not guarantee anything.
Due to the problems of automated Vulnerability Remediation, it seems that currently #VulnerabilityManagement and #PatchManagement vendors mainly focus on the hosts:
1) that are not very important, so the unsuccessful update won't become a complete disaster;
2) where the update operation is quite complicated.
It seems a bit foolish to offer automated remediation for the systems where almost everything can be updated with a single command from #WSUS or Linux repository. However, in the case of Linux, there will be software installed from sources, self-built packages, and other complexities. And it's even without talking about #Docker. 🤯
So, it turns out that the most convenient for vendors is to focus on Windows desktops. And not for the all programs, but only for a specific list (clarify this to avoid surprises!).
Plus, the trigger and responsibility are still in the hands of IT administrators. 😉
Such "automated remediation" off-the-shelf solutions can be successfully presented on the market right now.
1) that are not very important, so the unsuccessful update won't become a complete disaster;
2) where the update operation is quite complicated.
It seems a bit foolish to offer automated remediation for the systems where almost everything can be updated with a single command from #WSUS or Linux repository. However, in the case of Linux, there will be software installed from sources, self-built packages, and other complexities. And it's even without talking about #Docker. 🤯
So, it turns out that the most convenient for vendors is to focus on Windows desktops. And not for the all programs, but only for a specific list (clarify this to avoid surprises!).
Plus, the trigger and responsibility are still in the hands of IT administrators. 😉
Such "automated remediation" off-the-shelf solutions can be successfully presented on the market right now.