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

Please provide comments and solutions that are helpful to the author of this topic.

danb

From VoodooShield
Thread author
Verified
Top Poster
Developer
Well-known
Forum Veteran
May 31, 2017
2,350
13,625
3,278
Overland Park, KS
Please compare effective mechanisms to ineffective mechanisms.
Of course I am HEAVILY biased on this topic, but in my opinion…

Effective
1) Contextual engine
2) Dynamic security postures
3) ML / Ai
4) To a certain extent behavior blocking

Ineffective
1) Sandboxing
2) Antivirus signatures (I would have put this first, but Sandboxing is kinda silly)
3) Relying too much on Digital Signatures

I will probably change my mind a little after thinking about this more, I just thought of this and wanted to post it before I forgot.
 
I would add sandboxing/isolation in the effective category. I've been using sandboxie for about 10 years, and if you want to know what will be effective 10+ years from now I still see there being a place for it. Explain what you mean by 1) Contextual engine, 2) Dynamic security postures, please.
 
I would add sandboxing/isolation in the effective category. I've been using sandboxie for about 10 years, and if you want to know what will be effective 10+ years from now I still see there being a place for it. Explain what you mean by 1) Contextual engine, 2) Dynamic security postures, please.
Yeah, because it is SOOOOOO easy to use ;).
 
  • Like
Reactions: Sorrento
Ummmmmm, yeah, they still rely heavily on sigs, and ML/AI did not happen until 2015 or so. Just answer the question.
In what way do they still rely heavily on signatures?

Webroot was the first to employ Machine Learning in the early 2010's.

I wont answer an question based on misinformation
 
Last edited by a moderator:
  • Like
Reactions: Sorrento
In 30 years it will be all cloud. Software and hardware. no need to buy pc, software. In the future there wil be skynet.
 
  • Like
Reactions: Sorrento
Operating System hardening, like OS Armor
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.
 
  • Like
Reactions: ForgottenSeer 94633
Forget all of this nonsense, let's write the future.
In 10 to 30 years, you will connect through a neural link to Starlink:LOL:


 
@danb

With all of the boxes checked? Hehehehe.

User can choose what to harden/block easily via (yes, 100+) checkboxes, once an option is checked nothing more is needed (something like group policy editor?).

This allows a company/user to harden specific areas as needed, such as block scripts, block commonly abused system processes (powershell, cmd,...), child processes of a parent process, processes on specific locations, processes signed with an invalid/expired/revoked certificate and much more, possibilities are really a lot.

Using custom block rules companies/users can block any process behaviour they want with very simple and smart custom rules.

OSA also has pre-defined protection profiles like Basic, Medium, Advanced, Extreme that requires only one-click of the mouse.

OSA is focused in hardening the system and blocking malware delivery methods, and is very strong and effective in doing so.

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.

OSA blocks a process based on its behaviour, not by file type...

OSA analyzes many aspects of a process (parent process, command-line, location, file type, contest, permissions, hash, risk score, and much much more) using our own algorithms.

With OSA you can configure a system using a zero trust strategy: block any process (unsigned processes, unknown signers, etc) except what you know/trust.

Hope you don't consider this so "stupid" :)
 
Last edited:
@danb



User can choose what to harden/block easily via (yes, 100+) checkboxes, once an option is checked nothing more is needed (something like group policy editor?).

This allows a company/user to harden specific areas as needed, such as block scripts, block commonly abused system processes (powershell, cmd,...), child processes of a parent process, processes on specific locations, processes signed with an invalid/expired/revoked certificate and much more, possibilities are really a lot.

Using custom block rules companies/users can block any process behaviour they want with very simple and smart custom rules.

OSA also has pre-defined protection profiles like Basic, Medium, Advanced, Extreme that requires only one-click of the mouse.

OSA is focused in hardening the system and blocking malware delivery methods, and is very strong and effective in doing so.



OSA blocks a process based on its behaviour, not by file type...

OSA analyzes many aspects of a process (parent process, command-line, location, file type, contest, permissions, hash, risk score, and much much more) using our own algorithms.

With OSA you can configure a system using a zero trust strategy: block any process (unsigned processes, unknown signers, etc) except what you know/trust.

Hope you don't consider this so "stupid" :)
Thank you for joining the conversation!

How do users automagically guess which cyber attack they are going to experience, so they know which boxes to check?

There are some OSA rules that are based on behavior, but a lot of the rules (that are going to actually be enforced) specifically block by file type, or in a lot of cases simply by file.

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.

Here is one of many examples...

If I check the OSA rule "Block execution of .cmd scripts", then all cmd scripts are blocked, even if they are necessary and benign. In my opinion, the best way to handle this rule is to include context, so that it is blocked when it needs to be blocked, and auto allowed when it needs to be allowed. For example, if a non-risky whitelisted app launches a cmd script, should it be blocked or not? With OSA, it is blocked either way, without context.

Simply blocking "unsigned processes, unknown signers", etc, is NOT zero trust. Sure, OSA will harden the system to a certain extent, but it is far from zero trust.
 
Last edited: