Using OS_Armor and Hard_Configurator together

[Lenny_Fox]

Idea background

1. OS_Armor.
Use OS_Armor in default settings to block known malware execution patterns of legitimate (Windows) programs. I only excluded some script execution block rules, because the Software Protection Rules enforced by Hard_Configurato already block them in user folders (which offers similar protection with less compatibility risk). OS_Armor block rules are very granular.. Basically OS-Armor blocks legitimate programs to execute when they are used in way often seen by malware and ransomware.

2. Hard_Configurator
Use Hard-Configurator to block dangerous file extensions in user folders, but allow execution of programs for compatibility by loading the profile: Windows_10_MT_Windows_Security_hardening.hdc. I disabled UAC Validate Admin Code Signature, because I hope/guess Windows_Defender in MAX will block unsigned programs with poor reputation to execute.

3.Configure_Defender
Use Configure Defender to use Windows Defender in MAXimum protection. One of the benefits is that it blocks unknown programs with poor reputation in this MAXimum setting. In stead of all blocking programs with SRP, this allow/block decision is now transfered to the Windows Defender cloud mechanism. My guess is that most average PC users don't install a lot of software, so this false positive risk (blocking to much) is minimal.

4. Firewall Hardening
Enabled to block LOLbins also, just as an extra layer,in case the execution of a LOLbin slips through OS_Armor.


Running it for a few days now on my Windows10 partition. What do seasoned members think of this freebie combo? I tweaked as little as possible to the default settings, because Andreas and Andy know a lot more about security than me. Keeping this combo close to the defaults , is my best bet to achieve maximum protection with maximum compatibility and maximum usability.


___________________ disabling some default OS_Armor rules to block execution of scripts (anywhere) ____________________

 

[ForgottenSeer 823865]

ahhhhh it is always interesting to see when people discovers a software you are used to.

OSA in default-setting is a waste of resources if with H_C.
H_C (im not familiar with it) should be able to do what OSA does.
All the power of OSA is about its Advanced Settings and Custom Block rule editor, for example on my OSA settings, 99% of the advanced settings are enabled and i added 100+ Custom Blocks rules.

 

[SeriousHoax]

One of the benefits is that it blocks unknown programs with poor reputation in this MAXimum setting.

This is not much related to reputation. This "Block executable files from running unless they meet a prevalence, age, or trusted list criteria" rule in Max settings causes a lot of issues while updating even trusted apps with high reputation. I would say average user should avoid this option as it causes too many false positives.

 

[Andy Ful]

Hard_Configurator was created to minimize the necessity of using 3-rd party security to keep the security most compatible with the system and Windows Updates.
OSArmor was created as a better alternative to Windows Policies.
Your conception contradicts the above, but probably can be applied by the advanced user.

I can see some cons.

1. The setup loses much of compatibility with Windows Updates.
2. It would be hard to know how Hard_Configurator settings overlap with OSArmor restrictions, because there is no OSArmor documentation.
3. It is evident that both Hard_Configurator and OSArmor restrictions overlap much, so there will be more problems when something will be blocked.
4. The setup will not be useful for the average user, because OSArmor and ConfigureDefender (in MAX Protection level) will produce many false positives.

In my opinion, such a setup could be adjusted/applied by an advanced user, but then he/she could easily use the Hard_Configurator default-deny by applying the Enhanced Recommended settings or even more restrictive settings (and skipping OSArmor).

The only reason for the H_C & OSA hybrid could be using it in the Enterprise environment. The H_C role would be to restrict the user from running files with dangerous extensions and OSA as anti-exploit prevention for processes running with high privileges.

 

[Lenny_Fox]

Thanks for the feedback,

OS_Amor has indeed once given problems with a Windows update, but what I understand of the OS_Armor settings it does block execution of legitimate software, AKA the sponsor programs of Hard_Configurator.

Blocking execution (as with H_C) could potentially be a higher windows compatibility risk than the execution context based (e.g. parent program, process directory and parsed parameters) as the granular execution block rules of OS_Armor, so there are two sides to look upon this.

As long Admins are excluded from the SRP rules, the risk of H_C bogging an Widows update should be near zero.

 

[plat]

Right now, there is OSArmor and H_C/FirewallHardening on here and it's literally perfect from a usability standpoint. OSA has not interfered with any new Insider build to date. However, with all these changes to Windows in rapid succession, I don't know whether OSA is still enforcing every single thing. The OSA developer had promised a new OSA build "asap" several months ago and for whatever reason, this hasn't shown up yet. You want to feel like your security has your back--not partially or maybe, but as much as reasonably possible.

For me, a non-Enterprise user, I will use either one OR the other because of potential conflicts, the silent ones.

 

[ForgottenSeer 823865]

OSA doesn't need frequent updates, the LOLbins it blocks probably won't change their path, and even if they do, the user should be able to adapt and create the necessary rules, if not i highly suggest him to find another software, one he can handle.

Also using two default-deny softs at same time is redundant unless you have a very specific strategy/use that requires both.

 

[Andy Ful]

Thanks for the feedback,

OS_Amor has indeed once given problems with a Windows update, but what I understand of the OS_Armor settings it does block execution of legitimate software, AKA the sponsor programs of Hard_Configurator.

How do you imagine the effectiveness of OSA if it would not block many new applications? If it would be easy to see what is legitimate and what is malicious then there would not be any problem with malware. There are many applications already whitelisted by OSA due to cooperation with MT and Wilderssecurity members. But, there will be more new applications for sure.

Blocking execution (as with H_C) could potentially be a higher windows compatibility risk than the execution context based (e.g. parent program, process directory and parsed parameters) as the granular execution block rules of OS_Armor, so there are two sides to look upon this.

It is not a compatibility risk, because when you install something with H_C in Recommended or Enhanced settings, then most H_C restrictions do not apply to the installation process - the same is true for manual updates (or auto-updates via scheduled tasks, other auto-updates are blocked). After the installation, you can whitelist anything you want by path or by hash. Just install an application and add it to the whitelist if necessary. Make manual updates, and that is all. No, compatibility issues.
You will probably have more compatibility issues with OSA because when the application is auto-updating the OSA rules are not released for the update processes, which can break sometimes the update in the middle.

As I already mentioned, the real advantage of OSA can be seen in the enterprise environment, where the malware can attack the computer with high privileges from the network and there is a much greater risk of exploiting the unpatched software/system via high privilege vulnerabilities.

 

[oldschool]

The desire to tinker with and combine different software is part of the typical user experience on security forums, much like a disease that exhibits different symptoms at various stages. One either recovers, perishes or simply gives up due to exhaustion!

 

[ForgottenSeer 823865]

The desire to tinker with and combine different software is part of the typical user experience on security forums, much like a disease that exhibits different symptoms at various stages. One either recovers, perishes or simply gives up due to exhaustion!

or ascend to a new level, where wearing tons of weapons and armors becomes irrelevant and is replaced by mastery of the built-in power.
This is called "Security Saint"

 

[Andy Ful]

or ascend to a new level, where wearing tons of weapons and armors becomes irrelevant and is replaced by mastery of the built-in power.
This is called "Security Saint"

View attachment 231026

Ha, ha. It is a nice idea, somewhat similar to the teachings of Zen.

 

[oldschool]

Ha, ha. It is a nice idea, somewhat similar to the teachings of Zen.

Yes, like this

 

[Lenny_Fox]

@Umbra and @Andy Ful

OSA blocks the executables, but also allows whitelists on signer (like AppLocker), H_C with the Windows_Security (or Avast profile) does not block exectables. On my girlfriends PC I have added own blockrules and exception rules. One for Microsoft (all she uses is M$) and one a photobook program (which updates in AppData). I rather make an allow on signature than on program name, so that is the specific use.

So they do NOT overlap and are clearly complementary, SRP does not facilitate signer based rules, With OS_Armor I get more sophisticated blocking options (using process name, folder, parent process and signatures) compared to only using H_C. With H_C I get a lot of extra protection for file formats which could include code, while the impact of those SRP rules is minimal on system performance (because it is build into Windows?). So pairing them makes sense to me.

; Block execution in user folders
[%PROCESSFILEPATH%: C:\ProgramData\*]
[%PROCESSFILEPATH%: C:\Users\*]
[%PROCESSFILEPATH%: D:\*]

; Allow Microsoft
[%FILESIGNER%: Microsoft*] [%PROCESSFILEPATH%: C:\ProgramData\*]
[%FILESIGNER%: Microsoft*] [%PROCESSFILEPATH%: C:\Users\*]
[%FILESIGNER%: Microsoft*] [%PROCESSFILEPATH%: D:\*]
; Allow Albelli fotoboek
[%FILESIGNER%: Albumprinter B.V.] [%PROCESSFILEPATH%: C:\ProgramData\*]
[%FILESIGNER%: Albumprinter B.V.] [%PROCESSFILEPATH%: C:\Users\*]

 

[Andy Ful]

@Umbra and @Andy Ful

OSA blocks the executables, but also allows whitelists on signer (like AppLocker), H_C with the Windows_Security (or Avast profile) does not block exectables.

It is not true.
These H_C profiles + Avast set to Hardened Mode Aggressive can block any 'unsafe/not whitelisted' executable (EXE, MSI, scripts, etc.) and allow only EXE files whitelisted by Avast File Reputation service in the cloud.
But you are right that whitelisting by signer would be welcome in SRP.

On my girlfriends PC I have added own blockrules and exception rules.
...
So they do NOT overlap and are clearly complementary, SRP does not facilitate signer based rules, With OS_Armor I get more sophisticated blocking options (using process name, folder, parent process and signatures) and b

; Block execution in user folders
[%PROCESSFILEPATH%: C:\ProgramData\*]
[%PROCESSFILEPATH%: C:\Users\*]
[%PROCESSFILEPATH%: D:\*]

; Allow Microsoft
[%FILESIGNER%: Microsoft*] [%PROCESSFILEPATH%: C:\ProgramData\*]
[%FILESIGNER%: Microsoft*] [%PROCESSFILEPATH%: C:\Users\*]
[%FILESIGNER%: Microsoft*] [%PROCESSFILEPATH%: D:\*]
; Allow Albelli fotoboek
[%FILESIGNER%: Albumprinter B.V.] [%PROCESSFILEPATH%: C:\ProgramData\*]
[%FILESIGNER%: Albumprinter B.V.] [%PROCESSFILEPATH%: C:\Users\*]

In fact, any block/allow rule in OSA (for EXE files) will not overlap with the H_C setting profiles which allow EXE files. But still, OSA with default settings (or even worse with advanced settings) overlaps much with H_C, independently of additional block/allow rules. Furthermore, these OSA block rules add the inconvenience of creating allow rules for applications installed in c:\Users and c:\ProgramData.
So, your example makes things worse. All four points from my previous post are true and I can add another one:

1. The setup loses much of compatibility with Windows Updates.
2. It would be hard to know how Hard_Configurator settings overlap with OSArmor restrictions, because there is no OSArmor documentation.
3. It is evident that both Hard_Configurator and OSArmor restrictions overlap much, so there will be more problems when something will be blocked.
4. The setup will not be useful for the average user, because OSArmor and ConfigureDefender (in MAX Protection level) will produce many false positives.
5. The setup will not be easy for the average user, because one has to add allow rules in OSArmor for applications installed in %UserProfile%.

Edit.
I am not saying that your idea cannot be realized in practice by you. But, I can see some issues that can be important for many users.

 

[Lenny_Fox]

@Andy Ful

H_C in recommended settings blocks execution (but not for Admins) in user folders, so for software living in Appdata you aso need to create an allow exception. So I am completely missing the point considering the fact that OS-Armor displays a warning with the option to allow. Which makes it easier to create an exception as with H_C.

Also the option to block sponsors with H_C is not as granular as with OS-Armor, so the chances of a block with H_C to interfere with some legitimate software is (in theory) bigger than with OS-Armor, so yes they overlap, but the advantage goes to OS-Armor (more granular, context aware execution block extensive internal whitelist AND it throws a warning).

I don't want to start a Pro OS_Armor - Against H_C discussion, because I lam glad I am able to use your software for free, so I settle for let's agree to disagree, As confirmed by youm H_C with W_S or AVAST profile does not overlap with OS_Armor, because it does not block executables,

Regards Lenny

 

[Andy Ful]

@Andy Ful

H_C in recommended settings blocks execution (but not for Admins) in user folders, so for software living in Appdata you aso need to create an allow exception. So I am completely missing the point considering the fact that OS-Armor displays a warning with the option to allow. Which makes it easier to create an exception as with H_C.

That is right, but I commented on your post:

@Umbra and @Andy Ful
OSA blocks the executables, but also allows whitelists on signer (like AppLocker), H_C with the Windows_Security (or Avast profile) does not block exectables.

which was not related to the H_C Recommended Settings.
Anyway, you are right that in the Recommended Settings one must whitelist the applications installed in Appdata or ProgramData folders and that it is easier in OSA. But it is also true, that you do not need to whitelist the applications installed in Appdata or ProgramData folders when using W_S or AVAST profile (in H_C).
By the way, did your girlfriend found out how to install the new applications in your setup? She will not do it from the Downloads folder without turning off the OSA protection.

Also the option to block sponsors with H_C is not as granular as with OS-Armor, so the chances of a block with H_C to interfere with some legitimate software is (in theory) bigger than with OS-Armor, so yes they overlap, but the advantage goes to OS-Armor (more granular, context aware execution block extensive internal whitelist AND it throws a warning).
...

Yes, but this will probably be important in enterprises. Most Sponsors should be blocked both for parent processes and for child processes, because both the parent and the child can be malicious. This can be done for most Sponsors in the home environment by using H_C (SRP). If you will block the same Sponsors in OSA, then they will be blocked also for high privileged processes, which is riskier than blocking them only for standard processes.

I don't want to start a Pro OS_Armor - Against H_C discussion, because I lam glad I am able to use your software for free, so I settle for let's agree to disagree,
...

You are welcome.
But, I do not post about OSA against H_C. I think that we rather talk about using both applications in the home environment. You can try to do it, but it will not be as easy as you think. Please do not forget, that I admitted this setup to be potentially useful in the enterprise environment.

Glad you confirmed my point that H_C with W_S or AVAST profile does not overlap with OS_Armor.
...

To be precise, H_C with W_S or Avast profile will not overlap with the block/allow rules from your post, which are not included in the default OSA setup. But, W_S or Avast profile will overlap with other rules included in the default or advanced OSA setup, even when you remove the rules related to the script extensions.
You are a smart guy, so you will probably manage to use H_C & OSA, but there are some surprises waiting, for sure.

 

[ForgottenSeer 823865]

@Lenny_Linux

1- when you use SRP, there is no such thing as recommended/default settings.

2- don't compare H_C (which is a tool for Windows Home users needing SRP) and OSA (anti-exe).
OSA is a great and very granular anti-exe but it is limited to executables. SRPs scope are wider, they monitor more objects.

3- Sure OSA is more convenient than Windows SRP/Applocker. Reason why those aren't in home editions of Windows.

4- I'm not sure if H_C has all the functionalities than Windows 10 Ent. Built-in SRP and Applocker, if yes then OSA will not afford much more except for convenience and usability.

My use of OSA was to complement Appguard (a 3rd party SRP) which had the annoying inconvenience of limiting the number of custom rules. OSA isn't.
Now since I use Windows 10 SRP and AppLocker, OSA isn't required on my systems anymore.

 

[Lenny_Fox]

@Lenny_Linux

1- when you use SRP, there is no such thing as recommended/default settings.

2- don't compare H_C (which is a tool for Windows Home users needing SRP) and OSA (anti-exe).
OSA is a great and very granular anti-exe but it is limited to executables. SRPs scope are wider, they monitor more objects.

3- Sure OSA is more convenient than Windows SRP/Applocker. Reason why those aren't in home editions of Windows.

4- I'm not sure if H_C has all the functionalities than Windows 10 Ent. Built-in SRP and Applocker, if yes then OSA will not afford much more except for convenience and usability.

My use of OSA was to complement Appguard (a 3rd party SRP) which had the annoying inconvenience of limiting the number of custom rules. OSA isn't.
Now since I use Windows 10 SRP and AppLocker, OSA isn't required on my systems anymore.

Ad 1: tell that to Andy Ful, this is how he labels his adviced setup of H_C.

Ad 4: H_C has all the functionality of managing SRP rules like secpol or gpedit. All Windows versions have SRP build-in (but in Home version you normally can't manage them, but thanks to Andy Ful's H_C it is possible) H_C is easier to use than Microsoft secpol/gpedit.

AppLocker rules take precedence over SRP rules, so you are a real Umbra--San to use them both (link to Microsoft explaining it)

 

[Lenny_Fox]

By the way, did your girlfriend found out how to install the new applications in your setup? She will not do it from the Downloads folder without turning off the OSA protection.

The only stuff she installed herself was from the Microsoft store (Netflix, Ziggo-Go and Spotify).

She normally does not install software. Like most average PC users I know, she just uses software and does NOT want to invest time in learning/playing with software. I installed Microsoft Office because she uses office at her work (and a digital license is cheaper than Office365).

The only other thing she uses is photo-book software (to print holiday pictures). Although that company has a full fledged web version, she asked me to install the old (desktop) version, because the GUI looked different (and she did not want to spend time trying to figure out how the webbased version worked). So with Microsoft* and Albumprinter B.V. I (think) I have everything covered (I replaced Chrome with Edge-chromium).

 

[Andy Ful]

The only stuff she installed herself was from the Microsoft store (Netflix, Ziggo-Go and Spotify).

She normally does not install software.
...

Ha, ha. You are a happy man. The H_C & OSA setup will work well for her after initial adjusting. The only thing you should eventually do, would be looking from time to time for blocked events.

I have a similar situation with my wife. She does not install new applications and uses two desktop applications which must be updated two times a year (H_C is one of them).
So I could apply Windows_10_NoElevationSUA_Enhanced profile and my wife works safely on highly restricted SUA (I even blocked CMD). This profile allows software updates from Microsoft Store and updates made via scheduled tasks (high privileges).
I simply update manually two applications on Administrator account, and that is all. The web browser can auto-update without problems. This setup is even more restrictive than yours, because nothing new can be run by the user and nothing can elevate on such a SUA. So, the possible exploit cannot elevate to bypass the default-deny protection. But it survived Windows Updates and upgrades without any trouble and additional maintenance (for 3 years). I wish you the same.