Discussion in 'other anti-malware software' started by Jryder54, Oct 29, 2013.
Yes, that is correct. No problem.
Document readers are also good to add to the guarded apps list. If you use Microsoft Office then it should already be in your guarded apps list though.
If you use any P2P application you should also add them if you can do so without breaking their functionality. P2P application are a major source for malicious files. AG will protect you even if you cannot add them to the guarded apps list. It is best if you can add them to the guarded apps list though because in Locked Down mode apps only on the guarded apps list are allowed to launch from the user-space. Adding them to the guarded apps list also allows you to add additional memory protection, and privacy protection.
Rule of thumb for deciding which applications to guard, applications which
1. Connect to the Internet
E.g. your Webbrowser, P2P applications, mail en mediaplayer
2. Process documents/data which contain scripts or rich content
(rich content sometimes contains meta data with embedded code, like png exploit in the past or mingle code/script with the content like PDF-documents)
- your browser processes java script, but also processes web pages which process HTML, XML and contain rich data like movies, pictures, animations
- office applications contain macro's with visual basic for application scrips, PDF reader also includes script
- media player processes and collects meta data and rich data of the digital files (sometimes innocent data as artist name etc) in movies, sound and pictures files
AppGuard's strongeholds (smart three level security: admin space, user space, execution space).
1. Besides protecting admin space, AppGuard cleverly blocks executions from userspace which can be downloaded by applications with internet connection (protection against 1-type applications).
2. Besides protecting admin space and user space, AppGuard cleverly blocks memory intrusion with in memory processing of scripts or rich content, processing this data is part of the core functionality of such an application, so when you allow such an application you allow the scripts/rich content to run also. AppGuard protects against malware/exploits using these allowed scripts/rich content with its memory protection (protection against 2-type applications).
My comment on the hyped combo of ANTI-exec with AppGuard
Because UAC protects your Admin Space. The increased security level of Vista (UAC & Protected Mode/Low Intergrity rights containment) and Win7 (better ASLR), Win8 (Enhanced protected mode), has raised the bar for malware, meaning that 80% uses in process bypassing techniques which are not blocked by an ANTI-EXEC. On Vista and higher an ANTI-Executable does not add much real life protection. Only the owner of the PC feels better because the intrusions he/she can simulate are blocked first by the ANTI-EXEC. On XP (running admin) it makes sense to add an anti-exec though on top of AppGuard.
My thoughts exactly. I have a NVT ERP licence and I like the product and developer very much but with AppGuard on the case I find it superfluous so don't use it. I understand some use it to track installs when AG is set to install but that seemsalot of system activity just to track the occassional install. Anyway.
hehe very true but it makes me feel "more secured" so why not
I'll add it to the queue of enhancements that we'll try to get into the AppGuard 4.1 release. Thanks good catch!
Thanks PEGR for taking the time give this some thought. We are experimenting with this as well as other ideas. I think having a separate tab representing all folder/file rules (both User-space and Guarded folders) is the way to go (and eventually we'll make it file-explorer-like), but I think some of the terminology that you suggested may also bring some confusion:
Renaming the Include flag to "Guarded": This would imply that any application in that folder would be allowed to launch but would be Guarded. As you know, the application policy applied to user-space folders is determined by the protection level. In Locked Down, no applications are permitted. In Medium digitally-signed applications are permitted, but they are Guarded - other applications are not permitted unless you exclude them from user-space. In Install level, all applications are permitted. If we name it "User-space" we have the same issue we are trying to avoid - the average user does not take the time to understand the term user-space . Perhaps "Contain", "Launch Control", "Protected" (but this would conflict with our concept of "Protected Folder"), or "Safeguard" or "Apply Application Control Policy" (will we have the GUI real estate to handle that mouthful?) would be better.
We can add files to this policy as well so perhaps "File System" (too technical?) or "Folders/Files" for the tab name?
Other questions come to mind:
I'm not sure there is an advantage in not considering "the folder and file access in the same context as listing of the guarded apps" because the file access rules only apply to Guarded Apps. So perhaps changing the "Type" column name to "Guarded Apps Policy" would clarify that.
Our attempt at a non-technical description of the "Guarded Apps Policy" (aka Type) of folder was to use the terms Protected / Exception / Private vs. the terms Read Only/ Read/Write/Deny Access. Does that simplify or complicate matters for the non-technical user? Getting rid of the term "Protected" here, would allow us to use it to replace the "Include" column name.
In the current Guarded Apps Folder policy, we don't include some of the default policy (i.e. Windows, Program Files, directories are protected by default and cannot be changed by the user). I think we should probably list them as we've actually had people that have added them to the policy. I think it would also serve some "educational" purposes by including them in the GUI. Opinions please?
Another question that I've been meaning to ask: Currently our Private Folder policy only applies to Guarded Apps that are configured to be in Privacy Mode. Would it be beneficial to have another type of Private Folder that is not accessible at all unless the user "Unlocks" it from the GUI? So in other words, you would not even be able to access these files from File Explorer unless you first go into AppGuard and Unlock the private folder. I'm sure other products do this, but would it be a feature that you all would use?
Thanks again for the feedback and I look forward to the discussion that will ensue from this post. Happy Memorial Day weekend for those of you in the US! It's supposed to be beautiful Spring weather in Northern Virginia and I'm looking forward to doing some hammock time with a good book (Cryptonomicom by Neal Stephenson - it's not new, but if you haven't read it, I highly recommend it). Have a great weekend everyone!
Please go ahead and install 4.0. 4.1 is going to be delayed even more (another conflict with the QA resources that I hadn't anticipated). Since the resource conflict is with our QA department we can probably release a very limited beta release (which will not undergo a lot of BRN QA testing) by mid-June. That being said, I wouldn't count on it being stable until late June - early July (though a lot of what is being released has already been tested under the AOL Tech Fortress umbrella.
Also, 4.1 doesn't really add additional protection. It adds some usability features, additional default Guarded Apps and bug fixes (which didn't affect protection - just usability and troubleshooting):
New Guarded Applications (I know other Guarded apps were suggested for those of you that filled out the recent survey, but these were the ones deemed worthy by Product Management):
VLC (media player)
New Trusted Publishers:
Auto self update: AppGuard will periodically check for updates and prompt the user to install the update if it is available. You can turn this feature off from the Advanced Tab as well as force a check for the update.
Publisher Install Mode: You can set a publisher so that when a user-space application from that publisher runs, AppGuard automatically goes to the the Install Protection Level. BRN publisher is the only publisher in the default policy with this setting turned on. This is to facilitate the auto-update feature.
Publishers are now on the User-Space page (vs. Advanced Tab).
Warning messages when AppGuard blocks an exe or installation package.
Toaster reminder message when in the Install Protection level for more than 30 minutes.
Allow individual files from system space to be included in user-space policy (has the effect of red-listing the file).
Added an event message when AppGuard starts up and tries to locate a Guarded Application (4.0 only provided the negative event - when AppGuard could not locate the program and for 64 bit systems the message was not always correct - see below for corresponding bug fix).
When saving Activity Report Events file is not truncated.
XML is now Unicode vs. utf-8. This enables support for Chinese and Kanji.
Add program on Guarded Apps tab was not enumerating the programs for non-English versions of the OS.
Fixed incorrect event: AppGuard was reporting that it could not find a Guarded application on 64-bit PCs. When the application existed on 64-bit PCs in the Program Files (x86) folder, AppGuard was reporting that it could not locate the application path.
Tool Tip for Guarded App path now indicates (x86) if that is where the app is located.
Publisher install mode, hope you will provide a whitelist with it, great feature, makes it even more install and forget.
Yes, it will be settable in the GUI. This was done for AOL Tech Fortress so that AppGuard would not interfere with all of AOL's other partners installations.
So MBAE is redundant with Appguard?
Currently trialing AppGuard. I also have MBAE installed. Turned off MBAE and ran the MBAE exploit test. With AppGuard in medium protection mode it allowed both to run. It blocked both in locked down mode. For now I will keep both enabled.
Seriously having a bad week, was posting in the wrong thread . Anyways I've been having this blocking events in AppGuard logs and don't know what they are. I haven't changed anything.
Nothing to worry. Ignore them. I get some of these messages too. Just add them to ignore list if you don't want to see them again.
Yeah that's what I figured as everything is working, thanks!
They overlap in security purpose, but implement it differently. Based on limited information I have got:
a) When you want to implement as less as possible: I would say AppGuard is able to tackle exploits without the assistance of EMET or MBAE.
b) When you like more layers: I would use AppGuard with EMET (assuming AG's development will include EMET in compatibility testing, since it is from Microsoft itself and it is free).
c) When you are paranoid on security (with the risk of reducing efficiency and protection effectiveness): I would say add both EMET and MBAE.
EMET dll insertion delay is the same as AG's overall impact on system performance, MBAE has 1.5 times the impact on program startup as EMET. Bare in mind that we are talking of very little delay (say 0.1 to 0.2 secs on an old E5200 low budget Pentium dual core)
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <ATI External Event Utility EXE Module>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <HitmanPro Scheduler>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <WinPatrol System Monitor>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <NoSleepHD>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <BUFFALO RAMDISK UTILITY>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <NoVirusThanks Driver Radar Pro>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <Gmail Growl>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <Gmail Growl>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <Growl>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <Run a DLL as an App>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <Catalyst Control Center: Monitoring program>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <Malwarebytes Anti-Exploit>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <Catalyst Control Center: Host application>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <pid: 2156>.
05/26/14 20:48:14 Prevented <NoteTab Light> from reading memory of <PopMan>.
NoteTab Light seems to be rather naughty so i tried to stop the icon blinking in the system tray.
By adding a wildcard i thought i could stop the blinking as shown below.
It doesnt work (blinks) so what am i doing wrong?
I do have notetab light in user space is that what is preventing me from excluding it from tray blinking?
Easy and better way is to place NoteTab in system space.
You cannot use a wildcard character with a star for the whole field. It can replace only a folder or file in a path. So you have to create a rule for each and every message displayed above.
I don´t get it, isn´t AG in fact also anti-exe? IMO anti-exe is one of the most important things when it comes to protecting yourself from drive by attacks. As a second layer I would choose a tool like EMET or MBAE for memory exploit protection.
If am correct AG is not using the same memory protection techniques as EMET and MBAE, am I correct? Why do you think that AG´s memory protection is good enough against exploits?
Browsers and PDF viewers when guarded, cannot read/write to protected system resource. And the child process from these applications are automatically guarded as well. So the exploit payload cannot read/write to system space.
AG blocks executions based on policy instead of whitelisting. AG does not create any whitelist of one's machine. AG does facilitate allowing applications by digital certificate, and one could consider that a form of whitelisting. In a certain sense you could consider AG an anti-executable because it blocks executions, but it blocks them based on policy instead of whitelisting. AG works much differently than AE's like Faronics AE, ERP, and VoodooShield which use whitelisting. AG works really well at blocking exploits because AG forces applications to operate in a safe manner. AG will block many attacks before their payload is ever downloaded to your computer by blocking the risky behavior of the vulnerable application that allows exploits to execute. It the payload does somehow make it to your machine then AG still will not allow it to execute unless it is digitally signed, and your protection level is set at medium. In this case the execution will be allowed, but it will be guarded (so it will not be allowed to make any changes to the system space), memory guarded (it will not be allowed to read, or write to the memory of other applications), and ran in privacy mode so the execution will not be allowed to access any folders defined as private in AG. If you have your protection level set to Locked Down then the payload will not be allowed to execute even if it is digitally signed.
AG uses policy to block applications from reading, and writing to the memory of other applications. It's simple, but it works really well. Take a look at the screenshot below. I think it will really help you understand how AG operates.
@KaptainBug, That's the system space write protection for guarded apps and not the memory guard.
I would love to know more about memory guard as well. It's the component whose concept I understand the least.
If I'm right, each application runs on its own memory address space. When the application is memory guarded, it cannot read/write to other applications memory address space.
I am a bit confused about your questions, according to user interaction design principles the answers are straight forward:
Stick to one point of view in your terminology
An example: when you use the term Guarded it relates to your program functionality, when you use the term Install, you relate to the purpose of dropping protection for the user (when he/she wants to install things). Beter would be to rename Install mode to Unprotected mode, because now they all apply to the same point of view (AppGuard functionality).
Stay away from combined concepts in one GUI object (two cooks spoil the soupe)
The real question is about protection level: unprotected (allow all), allow guarded program launches, lock down (block all). Guarded (or Secured) mode allows installs (run as admin) of whitelisted vendors and allows run as guarded (run as limited user) for signed applications. It blocks unsigned programs, since 95% of the malware is unsigned. No additional geek choices. 95% of the geeks will choose locked down mode anyway, while 95% of the average users will make the wrong choices on geek questions. Just explain the functionality of your programs, stay away from mixing it with other concepts as "trusted vendors" and "signed programs". Just explain that guarded or secured means allowing executions with restrictions depending on the reputation/origin of the program (allow admin space for trusted vendors, allow user space for signed).
Consistency is key
Don't go changing terms and GUI with every new version. Keep existing AppGuard terminology which has been adopted by most users, therefore I would endorse PEGR recommendation:
1 ==> Unprotected Mode (allow ALL), Guarded Mode (guard execution) and Locked Down mode (block ALL)
In GUI design visible objects/common terms prevail over internal mechanisms/expert terms
2 ==> Folders/files is better (because these are the objects TO which the policy applies and this is common GUI term), file system is an internal terminology related to OS-ses. Try asking a common user "which file system do you have, could you show it to me"? A bet you will get a lot of confusing eyes staring at you.
Either your development team should listen more to your GUI/UX designer or you should attract a better GUI/UX-designer.
Separate names with a comma.