AppGuard News and Feedback

Hi All,

Barring any last minute QA issues, we expect to begin a beta for our 64 bit Win7 AppGuard next week (Wednesday). The beta will also include 32 bit Win7 because of a new feature called MemoryGuard found in AppGuard for 32 bit Win Vista, 32 bit Win 7, and 64 bit Win 7. It may never support WinXP (we're researching it though).

MemoryGuard is NOT a 'memory firewall' like that of Comodo or others. It doesn't seek to improve upon what ASLR, DEP, SEPx, etc do. Instead, it prevent code injection attacks by one process on another process.

Also in the beta, one can customize AppGuard policies such that one can add an exception rule that allows a guarded application to write to a specific file, whereas before this one could only define a directory.

We expect to release the new AppGuard at the end of this month, which will be version 2.0.x.

One of the features that will be included in the release but not in next week's beta will be the long awaited parental controls. We'd like your feedback such that we might improve/tweak it before the concrete dries.

Also to be in the release, but NOT in the beta:
- New AppGuard Version Alert
- MBRguard Integration
- Ignore specific AppGuard blocks ('right-click on a log event, click ignore')

Parental Controls Description:

There is no password that locks AppGuard policies. We wish to avoid issues associated with lost passwords. Instead, our approach leverages the existing Windows user account credentials on a PC. So, "family" computers must have at least two Windows user accounts to utilize our parental controls, which SHOULD always be so, though it isn't. Folks new to having a separate local admin account should make certain their password is never lost as consequences can be disastrous (a public service announcement!).

Until a user clicks on the AppGuard 'Advanced' button and activates the 'Parental Controls', no user is restricted in what may be done via AppGuard. Once 'parental controls' are activated, one must enter "super user mode" to edit parental controls. The Windows account used to first activate parental controls is endowed with "super user mode" privileges. AppGuard associates those that may run "super user mode" with Windows user accounts, which are not required to have Windows local admin rights. To enter "super user mode", one must click on the AppGuard "Advanced" button, answer the Windows authentication challenge (does not involve logging in or out of a Windows account), and then the parental controls dialog is displayed.

Parental control is a variant of our TamperGuard technology. Only a Windows account with local admin rights and with "super user mode" enabled may uninstall AppGuard. If AppGuard detects that there are no longer any "super user" accounts, the uninstall feature as well as parental controls in general would be disabled.

A user that has simply logged into a Windows account with the "super user mode" privilege has not enabled this mode. One has to click on a button in the AppGuard GUI, which initiates a Windows authentication challenge prompt, "super user mode" is activated, and then one may edit parental controls, allowing one to:
- Enable, disable, and edit parental controls
- Uninstall AppGuard
- Designated specific Windows accounts as having "super user mode" privileges

Thus, from an AppGuard parental controls perspective, there are two types of AppGuard users (or Windows user accounts), those with and those without the "super user mode" privilege. Windows accounts with the "super user mode" privilege are in no way restricted by parental controls; other Windows accounts are.

If someone without "super user mode" privileges needs assistance from someone with the privileges to temporarily remove an obstacle, that person with the privileges does not have to log out of that person's account and into their own. Instead, that person simply navigates to AppGuard, clicks on the 'Advanced' button, gets an authentication challenge, and then has "super user mode" enabled. When no longer needed, return there and log out of there (not the Windows account) to return things to normal.

Cheers,

Eirik

PS I may be a little slow in responding to questions this afternoon/evening as I will shortly be reliant on unknown Wi-Fi. I'll be online off and on all weekend.

 

Here are the parental control options:


End-users may do the following:

Suspend All protections (temporarily)
Yes
No

Add additional applications for the agent to guard
Yes
No

Customize protection policy to allow a guarded application to perform an operation is normally may not (e.g., save and modify files to a custom directory such as C:\Downloads)
Yes
No

Suspend guarding of an individual application
Yes
No

Suspend drive-by download protection (i.e., allow an unknown application to launch from user-space, which includes ‘My Documents’, ‘Desktop’, and other hard drive locations where an end-user without local admin rights has write privileges according to the Windows operating system)
Yes
No

Customize drive-by download protection settings (i.e., agent allows executable as well as script launches from specified directories/folders)
Yes
No

Suspend USB malware protection (e.g., allow applications and scripts to launch from a USB thumb drive)
Yes
No

Suspend privacy mode, which restricts an application guarded this way from accessing specified user folders, to prevent information theft:
Yes
No

Modify privacy mode (i.e., re-define folders that agent prevents applications guarded in privacy mode from accessing without user suspending privacy mode)
Yes
No

 

Glad to see it made it to vista 32,bought it when I had my old XP, and let it set in my mail box. Hoping one day I could use it on my vista 32 sp2.

 

Sounds interesting

Is this done by manual edits of the xml policy or will the UI provide this capability? This for me is going to be a likeable feature.

Looking forward to the release

 

Eirik, two questions

Does Win7 x64 also includes Vista x64 compatibility?


Will the current lisences work (since it is a major release upgrade)

 

I'm just guessing here but I doubt it. I say this because of something Eirik has mentioned to me in the past which at the time didn't make sense but I think after reading your question it just became clear. Key word here being think so I could be wrong.

 

Hi Eirik,

Will new releases of AppGuard continue to support 32-bit Windows XP (with or without MemoryGuard) or is the current 1.4.7 version the end of the line for XP users?

 

GUI dialog

 

Yes on licensing. On Vista 64, we technically do not support it, but 64 bit AppGuard may work because Win 7 is so similar. We chose to make win 7 the only 64 bit supported OS to reduce costs. I apologize if this proves an inconvenience.

Eirik

 

AppGuard will continue evolving with XP indefinitely. However, as MS does not retrofit new API's and other tech, AppGuard will diverge on XP somewhat from Vista/7. MemoryGuard is an example.

Eirik

 

Thanks Eirik, that's good to hear.

 

Eirik,

Good news on lisences. I think I will migrate from XP to Windows7 within 5 years or so. I hope by that time you offer an option to lockdown the browser (enable all build in security features, allow no third part BHO's and only admin approved plug-ins, lockdown all hijack bits) for home usage.

With UAC default -prevents lower rights objects to infect higher rights objects, no registry protection (as was in Vista) for usaeability


With Appguard - MBR protection, Registry and File protection of admin space (and I hope some user space registry entries/directories) for internet faced and office aps, download/drive by protection AND side by side infection of objects

Even with a Windows7 Home version you are protected all over

What's on the wish list?

Appguard adding two way protection to internal Win7 frewall

 

Hi Eirik,

When AppGuard 2.0.x is released, is it recommended to uninstall AppGuard 1.4.7 and/or the standalone version of MBRguard first before installing AppGuard 2.0.x?

 

kinda curious is there a GUI change for 2.0 ?

 

I'd hate to misinterpret what you mean by this. Would you mind elaborating?

I fear I do not understand.

The present version of AppGuard protects the Win7 firewall from an application/executable that might otherwise have access to and alter the executables of the firewall binaries and supporting files/registries.

The next release protects it from code injection attacks. MemoryGuard will also prevent data egress vectors whereby the malicious executable injects code and data into a process that is authorized to have Internet access by the firewall.

I suspect you mean something else. Please describe.

Cheers,

Eirik

PS I always enjoy your recommendations. I'm afraid we cannot pursue the browser hardening at present, however. But, never say never.

 

This should not be required. However, I'll send a note to engineering accordingly.

Cheers,

Eirik

 

Some minor tweaks, but not nearly as much as I'd like.

Cheers,

Eirik

 

So what do you folks think of our parental controls implementation?

Eirik

 

I had held out hopes that AppGuard would be something we could use in a small office environment to tighten up security, especially from unwanted new apps and foreign USB flash drives. The key element that holding me back from seriously considering trying/using it was the lack of password protection to lock program settings.

However, after reading the above info, I feel that the need for a second user account on Windows is way over the top for control of user settings for one program. If someone has to set up a new user and password for Windows, how is that better than just adding a password to AppGuard? Certainly the Windows method adds more files and complexity to Windows while the other doesn't. And having a second Windows account password doesn't make it anymore likely to be remembered than having a password for AppGuard.

Sorry but IMO, this is overkill to solve a simple thing...

 

that is total crap. I cant fathom a vendor saying they can only do one OS in 64 bit.

 

Adding 64 bit XP/Vista support after the Win 7 release is not economically justifiable for us. This choice actually provided a little relief to our developers and test group. None of our enterprise customers use 64 bit Win XP or Vista. In fact, over 99% of their endpoints are either 32 bit XP or one of the Win 7 flavors. The consumer figures are similarly discouraging. Of the Windows 64 bit family, we plan to support Win 7 only.

Eirik

 

Thanks for the feedback Han.

BTW, one needs to 'add' a Windows account only if the computer (s) in question only had one, which would mean that it would be running with local admin rights on a daily basis. Our parental controls implementation encourages people NOT to run computers on a daily basis with local admin rights, which seems like a good thing to me.

However, we thought there might be reservations about this approach, which is why we posted our approach before the code had been compiled (figuratively speaking).

Again, thank you for your feedback. I actually have your Wilders' alias on a list of folk that have requested some form of parental controls (a.k.a., password protection). I'll mark you down as 'against'.

Cheers,

Eirik

 

Thanks, Eirik.

 

As in 1) being Built-in Admin Account and 2) being Admin User account?

 

Is this similar to Trend Micro Browser Guard? Can Memory Guard run along side of Trend Micros Browser Guard or would Trend Micro Browser Guard not be needed wiht Memory Guard?

http://free.antivirus.com/browser-guard/