Reply to thread

Message

<blockquote data-quote="vtqhtr413" data-source="post: 777574" data-attributes="member: 65229"><img src="https://calendarofupdates.org/Themes/default/images/post/xx.gif" alt="" class="fr-fic fr-dii fr-draggable " style="" /><a href="https://calendarofupdates.org/index.php?topic=770.msg9433#msg9433" target="_blank">Re: VoodooShield v4 STABLE Thread</a>« Reply #1154 on: Today at 05:47:45 pm »A lot of people think of VS as just another application whitelisting utility... and that aspect of VS would be absolutely true if all VS did was whitelist based on hash, and possibly path or file size.&nbsp; One of the many things that sets VS apart from other application whitelisting utilities is that it has many, many attribute checks on the whitelist... and one of the most important and easy to explain is the parent process check.For example, cmd or powershell has the ability to be good or bad... and it all depends on the context of the item.&nbsp; And this is pretty much true with any process / executable, especially ones that are abused and vulnerable.&nbsp; So the reason you have several different items listed in the whitelist for the same process is because VS is simply whitelisting the context of each user action, so that it can later perform parent process path comparison when the item is later launched.&nbsp; As an example, you might want to manually launch cmd.exe, but you certainly do not want Chrome to launch it without your permission <img src="https://calendarofupdates.org/Smileys/default/wink.gif" alt="" class="fr-fic fr-dii fr-draggable " style="" />.Simply classifying individual files as good or bad, and adding the &quot;good&quot; ones to the whitelist, makes little sense to me, especially when (at least in theory), every file is vulnerable.&nbsp; VS considers the entire context of the user action to determine whether to allow the item or not.VS 3.0 was quite robust, but VS 4.0 is even more secure, and this is one of the reasons why.&nbsp; So when someone says &quot;Product X already has a whitelisting feature, so you do not need VS&quot;, they are simply unaware of VS&#039;s advanced features.&nbsp; It is partially my fault because I do not publish our entire playbook.&nbsp; This is particularity true when Product X&#039;s whitelisting feature is largely cloud based (I could write another book on this).</blockquote>

[QUOTE="vtqhtr413, post: 777574, member: 65229"] [IMG]https://calendarofupdates.org/Themes/default/images/post/xx.gif[/IMG] [B][URL='https://calendarofupdates.org/index.php?topic=770.msg9433#msg9433']Re: VoodooShield v4 STABLE Thread[/URL][/B] « [B]Reply #1154 on:[/B] [B]Today[/B] at 05:47:45 pm » A lot of people think of VS as just another application whitelisting utility... and that aspect of VS would be absolutely true if all VS did was whitelist based on hash, and possibly path or file size. One of the many things that sets VS apart from other application whitelisting utilities is that it has many, many attribute checks on the whitelist... and one of the most important and easy to explain is the parent process check. For example, cmd or powershell has the ability to be good or bad... and it all depends on the context of the item. And this is pretty much true with any process / executable, especially ones that are abused and vulnerable. So the reason you have several different items listed in the whitelist for the same process is because VS is simply whitelisting the context of each user action, so that it can later perform parent process path comparison when the item is later launched. As an example, you might want to manually launch cmd.exe, but you certainly do not want Chrome to launch it without your permission [IMG]https://calendarofupdates.org/Smileys/default/wink.gif[/IMG]. Simply classifying individual files as good or bad, and adding the "good" ones to the whitelist, makes little sense to me, especially when (at least in theory), every file is vulnerable. VS considers the entire context of the user action to determine whether to allow the item or not. VS 3.0 was quite robust, but VS 4.0 is even more secure, and this is one of the reasons why. So when someone says "Product X already has a whitelisting feature, so you do not need VS", they are simply unaware of VS's advanced features. It is partially my fault because I do not publish our entire playbook. This is particularity true when Product X's whitelisting feature is largely cloud based (I could write another book on this). [/QUOTE]

Verification