Did you know that Telegram supports Discussion groups for channels? It's like a regular chat group linked with the channel and all the posts from the channel are automatically forwarded to this chat. So you can discuss them, ask questions, flame a little bit, etc. I think that the lack of feedback (especially negative) is the most powerful feature of Telegram channels. 🙂 But, why not to try. So, if you want to talk about Information Security Automation welcome to @avleonovchat 😉

IMHO, these new enormous GDPR fines against data breach victims ("British Airways faces record £183m fine for data breach") will only lead to more efficient blackmailing. The attacker will send messages like "Your data has been stolen, this is sad, but you don't want to lose up to 4% of turnover if this information will become public, right?". It will work even better than cryptolockers, because in case of cryptolocker attack victim at least can accept the data loss, especially if there are some backups.

What is even more dangerous is that in British Airways case it seems like an attack on CDN or third party service: "...website were diverted to a fraudulent site. Through this false site, details of about 500,000 customers were harvested by the attackers."

I just combined a few recent messages from this channel in a post for my blog "The most magnificent thing about Vulnerabilities and who is behind the magic"

#vulnerability #reverseengineering #NSA #hacking #backdoor #VulnerabilityManagement #VulnerabilityDatabase #Concept

Due to the recent CVE-2019-13450 vulnerability in Zoom Client for macOS "remote attackers can force a user to join a video call with the video camera active", I am curious...

BTW, it's a best practice in Mac OS X 10.5 Leopard CIS Benchmark. No kidding 😉

#Greenbone keeps doing weird stuff with #OpenVAS. But some of these I even like. 🙂 Well, I already mentioned that they renamed entire project In GVM and left the name "OpenVAS" only for the oldest part of project, that was forked from the last opensource version of Nessus (btw, a good history page from Greenbone perspective). Even the libs that OpenVAS uses are called gvm-libs. But now it goes further. New OpenVAS logo will have a green "Greenbone" skull. OpenVAS "Open Vulnerability Assessment System" was renamed as "Open Vulnerability Assessment Scanner". And, most importantly, they decided to "turn the scanner service into a command line tool", so it won't be a daemon anymore.

I actually like this last part, because I wasn't able to deal with openvassd from GVM10 installed from the sources. And it's rather unclear how to debug this thing. 😅 So, maybe with command tool I will be more lucky. Future GVM11 will control OpenVAS through the OSP server, which is written in Python (cool!)

I spent a lot of time last week working with the new API of Kaspersky Security Center 11. KSC is the administration console for Kaspersky Endpoint Protection products. And it has some pretty interesting features besides the antivirus/antimalware, for example, vulnerability and patch management. So, the possible integrations with other security systems might be quite useful.

A fully functional API was firstly presented in this latest version of KSC. It’s is documented pretty well, but in some strange way. In fact, the documentation is one huge .chm file that lists the classes, methods of these classes and data structures with brief descriptions. It’s not a cookbook that gives a solution for the problem. In fact, you will need to guess which methods of which classes should be used to solve your particular task.

For the first task, I decided to export the versions of Kaspersky products installed on the hosts. It is useful to control the endpoint protection process: whether all the necessary agents and products were installed on the hosts or not (and why not). So, see the python code with my comments in my blog. 😉

#API #EndpointProtection #Kaspersky #KSC #KSC11 #python #python3

To say the truth, all attempts to optimize the installation of security updates ("patch this, it's critical; don't patch this - it's not"), including the latest Predictive Prioritization concept, seem quite weak and awkward if you keep in mind how little we know about all exasting vulnerabilities. There are so many uncertainties in this area, so much information is hidden. In fact, it's a miracle that sometimes information about some vulnerability comes to the software vendor, which confirms it and releases the patch with a very short description. Most likely, this vulnerability has been already exploited in a wild for a long time before this lucky moment, but still.

If the vulnerability is high/critical, the software vendor usually recommends to install the updates immediately. The regulators, such as the PCI Counsil, also recommend to do this. What is the most strange and unhealthy is that nowadays big Enterprises (basically their IT and business departments) in mass are not ready to implement these recommendations as is: to track security updates from the vendor constantly and install them all on each and every host. Simply because it takes too much time and efforts. What they really want from the Vulnerability Management is an excuse, an indulgence for the disobeying. They want somebody to show them why each vulnerability is not critical in "reality" even if it is marked as critical by the software vendor. And they want it to be done based on some incomplete and contradictory data.

Don't get me wrong, I stand for more practical Vulnerability Management processes that propose real attack scenarios. But when we talk about vulnerability remediation, the best strategy, IMHO, is to install all the patches and make the configuration, just as vendors recommends. And do it constantly and proactively. I don't have to scan a server that wasn't patched in two months to say that it has high and critical vulnerabilities. It's just a natural thing. And, after all, it's IT and business, who choose these IT vendors and the solutions, not Security guys, right?

The Vulnerability Management process should demonstrate that everything is fine in the company and alarm if something goes wrong with some IT processes. NOT to push the patching process all the time! (Well, ideally)

The Russians Did... Oh, not this time. 🙂 "A spokesperson for Turning Point USA, meanwhile, told the paper he was stumped as to the origins of the image, characterizing it as “a last-minute A/V mistake”... a staffer, who has been fired, stumbled on the image in an online search and used it in error. “I don’t think it was malicious intent”..." #friday #fun

When the ideal scenario for Vulnerability Management is not possible, there are other options. Business sets the priority; every whim for your money. 🙂

Let's say we can't update every host in the organization regularly and fully. Fair point, it requires a lot of resources.

1. We can play with the scope and regularly update at least the most critical hosts (this mean that we need excellent Asset Management and clear criteria for critical hosts, data and processes) and isolate them from other organization as much as possible.

We don't have resources to install all the updates at least on these most critical hosts?

2. Ok, let's go further and play with criteria for the most critical vulnerabilities and fix these vulnerabilities first. This is much more complicated task, because information about vulnerabilities is partial, subjective and confusing. Can you say that a vulnerability is critical and will be exploited soon just by reading a short description? Especially if you are not very familiar with the particular software and how it is used in the organization. I can't. And there is no magical neural network that could do this. This is a form of future telling.

Still no way to fix even these most critical vulnerabilities on a limited scope of hosts?

3. Ok, I get it. Let's think about workarounds, compensation mechanisms, advanced monitoring and isolation. At least it will make the exploitation harder.

Vulnerability Management can be very flexible!

Winter is coming... #bluekeep #metasploit #rdp #CVE20190708