Moved From Virus Scan to Host Intrusion Prevention > Discussions
Technically both take place. HIPS makes substantial use of and improvements on OAS scanning based on a number of rules either additional to the VSE OAS rules, or where they overlap and enhance the policy. Much like how HIPS will take the place of BOP on a client using VSE.
If you want to test this further try turning OFF the detection / action rule in VSE and see what HIPS does. Then you'll notice the HIPS rule taking action. Also check whether your custom rule in HIPS is set to log or not. HIPS may have the action but you overlooked the log matching event setting.
Thanks, great reply. My problem is that I cannot replicate the OAS side of this in my environment. I can only say that the HIPs rule does indeed work and logs when a file with the name in its rule is created (echo "stuff"" >> C:\this_is_bad.txt). The HIPs rule is indeed in memory on that endpoint, but only the OAS log fire/was created. Understanding that both OAS and HIPs rules happen, does the deletion of the bad file prevent HIPs from successfully firing a rule on the identical file name in it's own rule?
From testing with SysInternal's process monitor, I noticed HIPs rule only fire when the API calls are "SUCCESSFUL", not "FAILED". Would OAS be making the rules "FAIL" at this point? The system's Master File Table never shows the file hitting the file system as well.
So my best guess here is that OAS is taking priority, preventing the file from being created and stopping HIPs form firing on that file name, but I'm hoping for confirmation of the OAS/HIPs process order.
Separate question: How can I make a custom OAS/VSE file name based rule to test this?
I have seen both fire HIPS block and VSE on the same file. Did not understand why VSE felt the file was delete if HIPS said it blocked it in the first place.
To test I would probably just make a HIPS signature on an EICAR file that VSE already detects.
Yes, since VSE OAS is deleting the file, you get a FAILED result on the API call, so HIPS takes no action.
Here's a not so recent, but very relevant reference - https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/ 22000/PD22818/en_US/Access_Protection_Ru…
I'm not sure I follow your second question. OAS is detecting the test file name as expected, did you perhaps mean to say HIPS? If so - locate the AP rule where the file is blocked by VSE, Select the rule and uncheck the "Block" portion of the rule.
Thanks again. I'm still looking for solid technical proof, as the link you provided is a few steps up from what I need. I'll keep in mind that I can test in the future by disabling and enabling the OAS action if the malware and host allow me to do so.
As for my second question, I was hoping there was a way to create custom AV rules similar to HIPs custom rules. HIPs custom rules are good at behavioral rules, but really bad at ingesting hundreds or thousands of specifics processes, file names, reg values etc at once.
HIPs never took any action. The example I gave was in a HIPs test environment. The malware sample that created the real event was not retrievable so I couldn't test it. As for testing on an EICAR file, I suppose that can work.
Thanks for the clarification. Yes, you can certainly create your own rules. Under Access Protection Policies | Access Protection (tab) | User-defined Rules
Click on New... and create your own as you need.
Even if ePO 5.x or VSE 8.8 are not your specific versions, the policy is configured the same way.