Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Inactive Support Threads
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Software
Security Apps
Hard_Configurator Tools
Hard_Configurator - Windows Hardening Configurator
Message
<blockquote data-quote="Andy Ful" data-source="post: 909002" data-attributes="member: 32260"><p>[USER=87161]@nadis[/USER],</p><p></p><p>I understand your point, because I thought so a few years ago before I was starting the H_C project. This way can be followed when using something like Simple Software Restriction Policies.</p><p>The problem is that H_C was not created to be "a nicer GUI for basic SRP functionality". It would be much easier for me to do such a GUI, but in fact, the H_C project was intended for something more ambitious. It tries to adopt some Windows built-in features to make<span style="color: rgb(0, 168, 133)"> <strong>consistent and safe security in the home environment.</strong></span> These features were made by Microsoft for enterprises, not for home users. So, the security model of H_C is different as compared to enterprises.</p><p></p><p>In enterprises, one has to assume that:</p><ol> <li data-xf-list-type="ol">It is impossible to fully prevent malware and the security has to fight the malware executed in the system.</li> <li data-xf-list-type="ol">The system cannot be highly restricted because of remote administration, automation via scripts (macros), shortcuts, etc.</li> <li data-xf-list-type="ol">The software/system installations are not frequent and limited in number. The updates are usually made manually/remotely by Administrators.</li> </ol><p></p><p>The H_C security model in the home environment (Recommended Settings on Windows 8+) assumes that :</p><ol> <li data-xf-list-type="ol">It is possible in practice to prevent malware by highly restricting users' actions on the user level (medium integrity processes), and restricting only some Windows features on the administrative level.</li> <li data-xf-list-type="ol">The remote administration can be disabled and automation via scripts (macros) can be highly restricted. The shortcuts can be blocked except for some typical locations (like Desktop or Start Menu).<br /> The malware cannot use the command-line in the usual way (no access to LOLBins)</li> <li data-xf-list-type="ol">The software/system auto-updates should be allowed without disabling the protection. The user should have the possibility to install safely popular (legal) applications without disabling the protection.</li> <li data-xf-list-type="ol">The security cannot be too complex, because the "home administrator" does not have much time. For the same reason, the security model should avoid producing hidden incompatibilities.</li> <li data-xf-list-type="ol">After applying the restrictions, the average user should use the computer without problems, with occasional help from "home administrator".</li> </ol><p>The above security model is actually a base for H_C. That is why I had to skip DLL protection and I am not eager to add any possible LOLBin. I added some other setting profiles which are more or less compatible with this security model, especially with points 4 and 5. Of course, when choosing a more restrictive profile one has to sacrifice more time to manage it or use fewer desktop applications.</p><p>I know well the complexity of Unrestricted/Disallowed SRP rules. Using such complex rules is often hard to understand - some combinations work in an unusual way and some are buggy. Furthermore, the rules can work differently with some other SRP settings (Enforcement, Default Security Level) - if one is not the SRP expert then it is easy to apply rules that do not work as intended. So, I use these combinations that work well and are easy to understand. The Unrestricted/Disallowed rules applied in H_C settings are very complex - if you would add your own Disallowed rule, then in many cases, it would be altered by the H_C rules (and would not work as intended).</p></blockquote><p></p>
[QUOTE="Andy Ful, post: 909002, member: 32260"] [USER=87161]@nadis[/USER], I understand your point, because I thought so a few years ago before I was starting the H_C project. This way can be followed when using something like Simple Software Restriction Policies. The problem is that H_C was not created to be "a nicer GUI for basic SRP functionality". It would be much easier for me to do such a GUI, but in fact, the H_C project was intended for something more ambitious. It tries to adopt some Windows built-in features to make[COLOR=rgb(0, 168, 133)] [B]consistent and safe security in the home environment.[/B][/COLOR] These features were made by Microsoft for enterprises, not for home users. So, the security model of H_C is different as compared to enterprises. In enterprises, one has to assume that: [LIST=1] [*]It is impossible to fully prevent malware and the security has to fight the malware executed in the system. [*]The system cannot be highly restricted because of remote administration, automation via scripts (macros), shortcuts, etc. [*]The software/system installations are not frequent and limited in number. The updates are usually made manually/remotely by Administrators. [/LIST] The H_C security model in the home environment (Recommended Settings on Windows 8+) assumes that : [LIST=1] [*]It is possible in practice to prevent malware by highly restricting users' actions on the user level (medium integrity processes), and restricting only some Windows features on the administrative level. [*]The remote administration can be disabled and automation via scripts (macros) can be highly restricted. The shortcuts can be blocked except for some typical locations (like Desktop or Start Menu). The malware cannot use the command-line in the usual way (no access to LOLBins) [*]The software/system auto-updates should be allowed without disabling the protection. The user should have the possibility to install safely popular (legal) applications without disabling the protection. [*]The security cannot be too complex, because the "home administrator" does not have much time. For the same reason, the security model should avoid producing hidden incompatibilities. [*]After applying the restrictions, the average user should use the computer without problems, with occasional help from "home administrator". [/LIST] The above security model is actually a base for H_C. That is why I had to skip DLL protection and I am not eager to add any possible LOLBin. I added some other setting profiles which are more or less compatible with this security model, especially with points 4 and 5. Of course, when choosing a more restrictive profile one has to sacrifice more time to manage it or use fewer desktop applications. I know well the complexity of Unrestricted/Disallowed SRP rules. Using such complex rules is often hard to understand - some combinations work in an unusual way and some are buggy. Furthermore, the rules can work differently with some other SRP settings (Enforcement, Default Security Level) - if one is not the SRP expert then it is easy to apply rules that do not work as intended. So, I use these combinations that work well and are easy to understand. The Unrestricted/Disallowed rules applied in H_C settings are very complex - if you would add your own Disallowed rule, then in many cases, it would be altered by the H_C rules (and would not work as intended). [/QUOTE]
Insert quotes…
Verification
Post reply
Top
