AppGuard 4.x 32/64 Bit - Releases

It still not working at all. See pm.

 

Windows 8.1 x86-64 - Clean Install
Beta 4.3.4.3

Confirmed...

• SchTasks block
• Handle leak
• (x86) file path issue with Power Apps

 

It's currently being tested on a Windows 7 x64 VM. The problem exists with the stable version on my live system as well however. I created a quick Problems Step Recorder record if you want to take a look.
It's larger than the allowed attachment size so I put it up here:
http://www38.zippyshare.com/v/ZmkGWw99/file.html

 

Schtasks block is functioning as designed. It has always been blocked - just not reported.
Can't replicate the Handle Leak yet, but I tried on Windows 7 64 bit.
(x86) file path issue has always been there and is just a bug in the GUI - not in actual power app operation.

 

Is this with the new version? What OS? Will you send us your msinfo file and Windows Application Event Log (to AppGuard@BlueRidge.com). If you need instructions we will provide.

 

You aren't losing Locked Down. It is available from the Tray menu Protection Level selection.

 

Did you recently uninstall and re-install the new Beta? If so you may need to re-activate it. That is done by clicking on the "Activate" button on the About Box. What does AppGuard's status say?

 

The problem is because the Guard list that you see in the GUI reflects the actual programs installed on the machine. If the drive isn't attached when the policy is applied (at reboot for instance), it won't dynamically add it to the list when the drive is attached. Right now the work-around is to change the level and then change it back. You should see it back in the list.

 

We are intending to do that eventually.

 

Scheduled Tasks controls OS System Maintenance and SSD TRIM. Both of those are important functionality - especially on SSD systems.

Lots of OEM utilities use Scheduled Tasks, such as driver verification\update utilities.

This is where block alerts - with capability to Allow or Block - and capability to white-list command lines would greatly improve usability.

 

I responded to Cutting Edge's post about this issue. Currently before the Guard List policy is sent to the driver to be enforced (and to the GUI to be displayed), the paths are checked to see if they exist and only those paths that actually exist at that time are recognized. The work-around is to attach the drive, change the AppGuard level briefly (like a couple seconds) and change it back. I've spoken to the developer in charge of this component and he claims to do otherwise would be a very complicated change. Though I think that I have an idea about how to do this that might not be so invasive. Still it won't be in this release.

We hope that the "typical" AppGuard user never has a need to look at the event log (and they really don't have to very often). They are for our troubleshooting (though instructing users how to send the event log is sometimes difficult).

 

It's also used as an attack vector. AppGuard has been blocking this all along. Have you noticed any issues? We are planning on adding the white-list command lines in a future release, but I don't foresee the Allow/Block be approved by our Product Manager for various reasons (I think I've outlined them here before).

 

99.99 % of issues reported here at Wilders are Lock-Down Mode related... since virtually everyone here runs AG in Lock-Down Mode.

Getting apps to work correctly in Lock-Down mode can be a real challenge.

So I am constantly having to look in the Events Log...

 

I tried to download and Chrome wouldn't let me.

 

That's why we're "Hiding" locked down. We love you guys/gals, but you have to admit that you aren't the "average" users. With one of our channel partners, we have in the neighborhood of 50,000 very non-technical users. We rarely (I mean once or twice a year) get trouble tickets from them. Our usual trouble tickets come from people thinking that they have to "Guard" everything or that they have to make an exception for every event that they see (that's why we're hesitant to display too many events). The default AppGuard policy running in "Protected" level provides significant protection without interfering with the end-user's productivity.

 

Extended non-maintenance and TRIM of SSDs causes data corruption and various failures. That statement comes directly from Microsoft.

The issue is that SSDs are not maintained per the recommended schedule (weekly).

Also, the user must perform system maintenance and TRIM manually by lowering AG protection to Install Mode - if they remember to do it.

It negatively impacts usability and the SSD.

 

It would be very beneficial in HELP file to explain that registry, .log, etc blocks are not necessary. .dat blocks I am not so sure about (e.g. - rundll32 => sqmboot.dat).

Better yet, if they have no negative impact whatsoever, then they should not even be logged or explained; such block events sow nothing but user confusion and frustration if they do not know that they are harmless.

 

I still want the registry blocks logged in the Activity Report. It does not bother me at all. If it causes user confusion then just give a separate option in the settings with registry logging disabled by default. If users like myself wanted to enable registry logging in the Activity Report then all they would have to do is tick a box.

 

You're dealing with security soft geeks here at Wilders that are attempting to configure AppGuard Lock-Down Mode - and their other installed apps - to work together and provide 99.999% protection.

I know you keep saying "Protected" Mode is sufficient, but users here will not accept Protected Mode... even if it is probably 95 % or better.

I mean not to offend anyone, but the truth is the truth.

 

Hopefully those that make the decisions at BRN will like my ideal, and just give all the options that Locked Down Mode provides with tickboxes in the setttings. I actually think only having one mode of protection will work out much better. It will greatly cut down on documentation in the manual, and make things much easier to explain to new AG users. All the functionality of Locked Down Mode can be provided using tickboxes in the settings. I know it will make it much easier for me when helping new users on the forum. I don't have to go into a long explanation explaining the difference in functionality of the modes of protection. I think only having one mode of protection will be the key in making AG more simple to use.

 

If I am understanding @Barb_C correctly, the majority BRN perspective is that Lock-Down mode is needlessly trouble-some; Medium Mode (now renamed "Protected Mode") is sufficient.

Well, in my experience, typical computing on a day-to-day basis has reached the point of being a high security risk activity. Therefore, I think maximum-possible protection is an imperative. The problems associated with Lock-Down Mode can be greatly mitigated by incorporation of many of the recommendations made here on this thread. Their incorporation will make Lock Down Mode easier to configure and, therefore, Lock Down mode will be less of a support burden.

The end result will be a much more user-friendly AppGuard at the best possible protection level.

I would think most security soft vendors would fiercely embrace this concept, but in my experience there are a whole host of issues not related to actual security that drive their development choices.

Who's experience using AppGuard carries more weight - 75 or so security soft geeks at Wilders or their supported install-base of 50,000+ users?

I am sure they will at least consider the grumblings of a few security soft geeks, but in the end, if Lock-Down mode is costing BRN time and $ in additional support requests, then Lock-Down Mode will be removed.

What I see is that BRN is not willing to put forth the time and effort - for whatever reason(s) - it doesn't matter - I am not judging - to make dedicated, 100 % Lock-Down Mode use much less troublesome.

I know what official policy is... AG is designed to run in Protected Mode.

However, I have seen it a few times, Protected Mode can be by-passed. Yes, it is rare, but it can most definitely be done. All one needs to do is doggedly pursue vulnerabilities. Persistence does pay off in this regard...

Yes...yes, you say. That applies to all security softs. Besides, what malware author is going to bother trying to exploit AppGuard. Really ? You're gonna put forth that argument ? That the possibility of a Protected Mode exploit is infinitesimally small ?

Any by-pass, in my book, is a by-pass. Protected Mode has been compromised over the years and that is all there is to it.

On the other hand, in my experience, Lock-Down Mode has never been compromised against malware for which it was designed to protect against - and believe me - I have tried really hard to by-pass Lock-Down Mode. Eventually, I gave up - since AppGuard Lock-Down Mode proved to me that it provided the best protection of its kind.

FWIW...

 

I'm pretty sure your mistaken Barb. ALL users, everywhere, obsess over tinkering with the guts of their security software settings, just like we do. Right?

An alternative to hiding the lockdown settings would be to just have an Advanced interface option. A simple interface by default for the average user, but check a little box in the settings to bring up the full slider with lockdown and maybe a few other options. I have seen many programs do this over the years. It not exclusively an either/or proposition. I think that would make everyone happy.

 

I thought that is what we already have

 

Not by actual malware (that we're aware of).

 

Sort of. I meant an advanced option that would bring the full slider with lockdown back to the main window. Having the option in the trey is good enough, but I have always preferred using the main window.