Advice Request What will cybersecurity software look like in the future, say 10-30 years from now?

[NoVirusThanks]

Blocking entirely a file type like .js .vbs .hta .ps1 etc is what I call hardening a system and a smart approach: if a script is known to be commonly abused to deliver malware and it is not widely used or not strictly needed, then block it and problem solved. No need to check if the script is malicious or not, the user can write exclusion rules if needed.

Same approach goes for commonly abused system processes like powershell.exe, certutil.exe, mshta.exe, bash.exe, etc.

Globally blocking anything by file type without context is very stupid.

Do you think so? Instead I think it is very good for hardening a system by blocking/disabling what is not needed, thus reducing the attack surface and the malware delivery methods.

If you need to execute a script that is blocked you can write exclusion rules, that's all.

I joined the conversation not to discuss about the topic but about this:

VS blocks by context and OS Armor blocks by file type. There is a HUGE difference between the two.
I have said this a million times... please understand that blocking something by file type is really, really, really stupid.

I personally believe there are probably better ways and words to express your opinion.

Because to me it sounds as you said "OS Armor blocks by file type" -> "blocking something by file type is really, really, really stupid."

 

[ForgottenSeer 69673]

I think I globally block PowerShell and maybe that is why Defender UI doesn't work for me?

 

[danb]

Blocking entirely a file type like .js .vbs .hta .ps1 etc is what I call hardening a system and a smart approach: if a script is known to be commonly abused to deliver malware and it is not widely used or not strictly needed, then block it and problem solved. No need to check if the script is malicious or not, the user can write exclusion rules if needed.

Same approach goes for commonly abused system processes like powershell.exe, certutil.exe, mshta.exe, bash.exe, etc.



Do you think so? Instead I think it is very good for hardening a system by blocking/disabling what is not needed, thus reducing the attack surface and the malware delivery methods.

If you need to execute a script that is blocked you can write exclusion rules, that's all.

I joined the conversation not to discuss about the topic but about this:



I personally believe there are probably better ways and words to express your opinion.

Because to me it sounds as you said "OS Armor blocks by file type" -> "blocking something by file type is really, really, really stupid."

This was supposed to be a fun thread, and we are way off topic, but I will say one last thing.

When we first started developing VS, we blocked a lot of potentially dangerous items globally. The problem was that blocking items globally broke a lot of stuff on endpoints, and we quickly realized that was a really bad idea, and that we had to find a better way.

Every app has its strengths and weaknesses, for example, I LOVE OSA’s anti-exploit feature (for obvious reasons ). Having weaknesses does not mean the whole app is weak or bad, it simply means that certain features are not optimal.

Just look at ticklemefeet’s post above and ask yourself, which scenario would you prefer?

Scenario 1:
Block DefenderUI from running powershell
Block malware from using powershell

Scenario 2:
Allow DefenderUI to use powershell
Block malware from using powershell

I apologize if I hurt your feelings, that was not my intention. The reason I used the word stupid is because that is honestly the best word that I could find that describes what I think of blocking globally.

 

[n8chavez]

Both products are fantasic. Both are valuable. Now that OSArmor is not free, I went with the cheaper of the two.

 

[bellgamin]

Both products are fantasic. Both are valuable. Now that OSArmor is not free, I went with the cheaper of the two.

Umm.. I believe that, as of recent date, VS also is NOT free.

By the way, I have been using NVT's apps and following his forum posts for nearly 20 years. Never once have I seen a single one of his posts where he criticized competing apps, much less called them by an epithet such as stupid. I am a long-time user of OSA. I have also used Voodoo Shield and may do so again. VS speaks for itself by means of its high quality and unique approach. The same is true for OSA. So there really isn't any need to denounce other security apps in public forums, is there?

In my experience, A versus B comparisons always generate much more heat than light.

 

[Thales]

I think the AI will be an important part of the AV engines. This is my only prediction.

 

[n8chavez]

Umm.. I believe that, as of recent date, VS also is NOT free.

I never said Voodoo Shield was free. I said I went with the cheaper of the two; and $65 for nine years versus $17 per year for OSA qualifies VS as cheaper. Other than that, we're saying the same things.

 

[vuksha_xc60]

Security software will still exist, but I doubt in it's effectivness. We would have manually monitor the processes, connections, and scan PCs with appropriate software. Maybe antivirus extensions will be still relevant (as pieces from of the old era). Since free versions which will use more and more data and resources of PCs as compensation for paying the licence, third party software will be less and less popular.

ML/AI, Sandbox and Behaviour monitoring would be essential components, but the integration with operating systems would have to be better. Especially with Android, which will grow more and more in popularity in next years. (See Operating System Market Share Worldwide | Statcounter Global Stats)

P.S. I am amateur in this field.

 

[l0rdraiden]

With all of the boxes checked? Hehehehe.

We unfortunately are not afforded the opportunity of knowing what attacks we are going to experience.

I have said this a million times... please understand that blocking something by file type is really, really, really stupid.

VS blocks by context and OS Armor blocks by file type. There is a HUGE difference between the two. VS has done this for years but it wasn't until about 6 months ago that we put it all into one algo, which is the Antimalware Contextual Engine.

If you want you block by file type, please use one of the other products.

OS hardening, doesn't need to be something like OS armor is 101 in security, is in the TOP 5 of OWASP, although not related to OS hardening and in any security report as a one of the main causes of cyberattacks.

 

[danb]

Hehehe, I am just saying that it is improbable that we will be blocking anything by file type or file name 10-30 years from now. The whole point of this thread is to discuss what is going to happen in the future, which probably does not include making a simple list of things to block and then blocking them .

Algorithms take a massive amount of time and dedication to develop, spanning over many years, they do not happen overnight.

I look back at some of the stupid things VS had done and the past and simply laugh. We did what we thought was best at the time, and later figured out we were way off. It happens. But the cool thing is that we struggled through it all and found a better way.

I apologize if did not use the correct words. But I stand behind the idea that blocking anything by file type or file name is a very, very, very bad idea.

Someone was saying that I was avoiding questions. They should be answered on our website now, but if not, please let me know!

 

[dinosaur07]

Clearly any default deny/SRP/anti-exploit software will certainly survive. I like all the 3 famous software mentioned in this thread, I use them alternatively or in different configuration. I like the customization options of OSArmor, the strength of VS Pro and the sense of solid protection given by H_C. So, guys, don't fight, you all develop great software and keep the flame on further.

 

[Kubla]

In 10-30 years I would suspect home computers would evolve into complete home automation systems with AI that would be advanced enough that would give it a level self autonomy over its own protection, constantly updating, running self diagnostics, etc... perhaps even writing its own anti virus security code/algorithms in real time as it is alerted new threats and how other similar systems on its network/cloud encountered and dealt with it.

 

[vuksha_xc60]

We are too far away from that. That would interesting to see, especially if it could talk with the owner to say like Why do you force me to scan myself if I'm well or any other funnier situations.

In 10-30 years I would suspect home computers would evolve into complete home automation systems with AI that would be advanced enough that would give it a level self autonomy over its own protection, constantly updating, running self diagnostics, etc... perhaps even writing its own anti virus security code/algorithms in real time as it is alerted new threats and how other similar systems on its network/cloud encountered and dealt with it.

 

[ForgottenSeer 95367]

The problem was that blocking items globally broke a lot of stuff on endpoints, and we quickly realized that was a really bad idea, and that we had to find a better way.

One can globally block the top 200 abused LOLBins and experience but a few temporary breakages. Except for rare cases, any "breakages" arising from SRP policy are only temporary because allow exceptions that fix the breakage can be created.

Blocking globally is not the problem that you make it out to be. And it's not a bad idea. It is just one particular way of providing security among many. In fact, the practice is part of the backbone of enterprise security and best practices.

 

[danb]

One can globally block the top 200 abused LOLBins and experience but a few temporary breakages. Except for rare cases, any "breakages" arising from SRP policy are only temporary because allow exceptions that fix the breakage can be created.

Blocking globally is not the problem that you make it out to be. And it's not a bad idea. It is just one particular way of providing security among many. In fact, the practice is part of the backbone of enterprise security and best practices.

This statement perfectly demonstrates your lack of understanding of how VoodooShield works, especially our Antimalware Contextual Engine, which solves this issue perfectly. VoodooShield is light years ahead, and you don't even realize it.

SRP is dead. I told you guys several months (and years) ago that its days were numbered, but you failed to listen.

 

[ForgottenSeer 95367]

This statement perfectly demonstrates your lack of understanding of how VoodooShield works

The statement was 100% accurate about SRP and refutes your claim that SRP is onerous because it causes breakages.

VoodooShield is a simple product. It is not difficult to understand how it works.

especially our Antimalware Contextual Engine, which solves this issue perfectly.

Users aren't doing things on enterprise systems where a contextual engine is even needed. Inconvenience - if you can call less than 3 minutes for an admin to create and deploy a very rarely needed allow exception - is not a problem in that space.

On the other hand, secops is not going to install a consumer product like VoodooShield that presents alerts and requires decisions from the person sitting in front of the system on a network of 27,000 endpoints. In enterprise, the decisions are made by the admins.

SRP is dead. I told you guys several months (and years) ago that its days were numbered, but you failed to listen.

SRP is hardly dead. SRP in its various flavors remains a huge part of Windows security. In fact, it remains a significant part of the recent Microsoft-DoD contracts. There's millions of endpoints running SRP and Microsoft will keep supporting both the "classic" and newest version (WDAC).

Saying SRP is dead is hardly factual, but I think you need to say it for your own comfort.

 

[danb]

The statement was 100% accurate about SRP and refutes your claim that SRP is onerous because it causes breakages.

VoodooShield is a simple product. It is not difficult to understand how it works.


Users aren't doing things on enterprise systems where a contextual engine is even needed. Inconvenience - if you can call less than 3 minutes for an admin to create and deploy a very rarely needed allow exception - is not a problem in that space.

On the other hand, secops is not going to install a consumer product like VoodooShield that presents alerts and requires decisions from the person sitting in front of the system on a network of 27,000 endpoints. In enterprise, the decisions are made by the admins.


SRP is hardly dead. SRP in its various flavors remains a huge part of Windows security. In fact, it remains a significant part of the recent Microsoft-DoD contracts. There's millions of endpoints running SRP and Microsoft will keep supporting both the "classic" and newest version (WDAC).

Saying SRP is dead is hardly factual, but I think you need to say it for your own comfort.

Did you somehow miss the VoodooShield option "Require admin approval before letting the user allow new, non-whitelisted files"?

SRP is dead and you are in denial. Sure, it will be around on legacy systems, but a year from now 50%+ endpoints will be running Windows 11 which will not support SRP.

BTW, you are pretty much the only person left on MT who likes to argue. Other members enjoy polite conversations where they can learn something and help others.

It really is a shame, you have wasted massive amounts of your life the last 10 or so arguing on security forums with people who don't want to argue.

Just imagine what you could have done with all that time. You know, something constructive.

Have a great weekend JT!

 

[ForgottenSeer 95367]

Did you somehow miss the VoodooShield option "Require admin approval before letting the user allow new, non-whitelisted files"?

Might work in a 12-person medical practice, but not in an enterprise.

but a year from now 50%+ endpoints will be running Windows 11 which will not support SRP.

Provide evidence for your claim - evidence from Microsoft. We'll all wait.

You seem awfully fixated and stuck in the past with SRP from decades ago. SRP has moved on. On Windows 11 SRP is running and it is called WDAC. Or did you not know that WDAC is the latest iteration of Microsoft SRP?

BTW, you are pretty much the only person left on MT who likes to argue. Other members enjoy polite conversations where they can learn something and help others.

There is no argument happening here. I am politely responding to your posts and calling you out on your false claims about SRP.

It really is a shame, you have wasted massive amounts of your life the last 10 or so arguing on security forums with people who don't want to argue.

OK strawman.

Just imagine what you could have done with all that time. You know, something constructive.

Have a great weekend JT!

You don't know who I am or a thing about me.

 

[bellgamin]

It takes two to tango and two to argue. I do not see any argument here -- just an interesting discussion.

 

[ForgottenSeer 95367]

Processes can either be used for good, or they can be used for bad. Globally blocking anything by file type without context is very stupid.

Then you'll have to explain why SRP global blocking provides such robust security with so few problems across the entire Windows ecosystem?

If you assert that SRP is highly problematic, then you need to provide evidence. If it is as bad as you make it out to be, then it should no challenge for you to supply a lot of evidence to support your claim.

See the thing you do here at MT is to use SRP as a punching bag, claiming that it is not context-aware and therefore creates onerous problems for users. However, you never supply any factual evidence to back any of that up.

So you have incorporated a contextual engine in VoodooShield to solve usability issues for consumers? So what? And what happens when you miss or don't get the context right, and as a result there is an unwanted block - or worse - it does not protect the system from infection? Or is that not a potential problem of its own making? I can tell you that it is because that is an inherent weakness of relying upon context and there's no getting around it. It's not as if context can be ignored.

@danb - another MT member upvote; they're liking the discussion I am fostering.