Advanced Plus Security Thales Hard Protected Setup

[ForgottenSeer 823865]

Again, Firewalls were never meant to protect the system from malware calling home. If you have a proper security strategy, software firewalls are useless security-wise.

All those FUD about having a outbound monitoring firewall is consequences of perpetual brainwashing from 3rd party security vendors...
Be logic, if their own security features are so good at detecting and blocking malwares , why would they implement outbound monitoring, malware wouldn't even be able to call home if it were the case.

Don't let yourself get FUDed.

 

[Thales]

Added

• HMPA

Love it! This is my 2nd license after the last one expired. I am very happy about the product.

• RunBySmartscreen
• eM Client to handle my Emails.

 

[Andy Ful]

Added

• HMPA

Love it! This is my 2nd license after the last one expired. I am very happy about the product.

• RunBySmartscreen
• eM Client to handle my Emails.

Hi,
RunBySmartScreen is already in H_C. It can be activated by setting <Run As SmartScreen> = "Standard User". In some cases, using the standalone RunBySmartScreen will get a configuration error in H_C. Do you still use H_C?

 

[Thales]

Hi,
RunBySmartScreen is already in H_C. It can be activated by setting <Run As SmartScreen> = "Standard User". In some cases, using the standalone RunBySmartScreen will get a configuration error in H_C. Do you still use H_C?

Ahh Got it. My setting was administrator. Now I disabled the standalone RunBySmartScreen and changed to "standard user" in H_C.
However my account type is administrator because I login via MS account. I used SUA in the past but not anymore.
Yes, I still use H_C. As far as I know HMPA and H_C work well together.

 

[notabot]

However my account type is administrator because I login via MS account.

You can login via MS account and the local account being SUA

 

[Thales]

You can login via MS account and the local account being SUA

So that means I need to use 2 different account, one SUA and one admin via MS? Because I couldn't find a solution to login with MS account as SUA.

 

[notabot]

So that means I need to use 2 different account, one SUA and one admin via MS? Because I couldn't find a solution to login with MS account as SUA.

Steps are:

1. Make a local admin account that's not an MS account - as you need a local admin account.
2. Change your current local account ( that is linked to your MS account ) to SUA.

 

[Thales]

Steps are:

1. Make a local admin account that's not an MS account - as you need a local admin account.
2. Change your current local account ( that is linked to your MS account ) to SUA.

Thanks.
Yeah did it in the past but because I use SRP I had to log in and out quite often.
I admit using SUA over admin is more secure but with SRP and common sense I'm still good. (at least I hope so)

 

[notabot]

Thanks.
Yeah did it in the past but because I use SRP I had to log in and out quite often.
I admit using SUA over admin is more secure but with SRP and common sense I'm still good. (at least I hope so)

Imo SRP is an impractical setup if you do dev work , even SUA is but not as much, eg updating Docker from SUA acc fails, I'm keeping SUA for now but I may do away even with SUA ultimately.

 

[Andy Ful]

Imo SRP is an impractical setup if you do dev work ...

It is not. Simply use an elevated shell for dev work. I run Total Commander via "Run as administrator" or "Run As SmartScreen" and then this Total Commander session works as an elevated shell which bypasses the SRP restrictions introduced by H_C. So, I have two shells for running applications, one is elevated and the second (Explorer) is not. - Explorer is still restricted by SRP.

 

[Andy Ful]

Ahh Got it. My setting was administrator. Now I disabled the standalone RunBySmartScreen and changed to "standard user" in H_C.
However my account type is administrator because I login via MS account. I used SUA in the past but not anymore.
Yes, I still use H_C. As far as I know HMPA and H_C work well together.

The <Run As SmartScreen> settings in H_C has nothing to do with accounts, but only with execution privileges.

<Run As SmartScreen> = Administrator, means that you can use the "Run As SmartScreen" entry in the right-click Explorer context menu, and the application which you are going to execute will be forced to ask for Administrator rights (high integrity level). This work both on Administrator type of account and on SUA.

<Run As SmartScreen> = Standard User, means that you can use the "Run By SmartScreen" entry in the right-click Explorer context menu, and the application will not be forced to ask for Administrator rights (high integrity level) and usually it will run with Standard User rights (medium integrity level). This work both on Administrator type of account and on SUA.

If you will use the Standard User setting with the H_C default-deny setup, then the application executed via "Run By SmartScreen" will be checked by SmartScreen, but will not bypass SRP restrictions (will not be executed). That is why <Run As SmartScreen> = Administrator is used to bypass safely default-deny SRP. This work both on Administrator type of account and on SUA.

 

[notabot]

It is not. Simply use an elevated shell for dev work. I run Total Commander via "Run as administrator" or "Run As SmartScreen" and then this Total Commander session works as an elevated shell which bypasses the SRP restrictions introduced by H_C. So, I have two shells for running applications, one is elevated and the second (Explorer) is not. - Explorer is still restricted by SRP.

It is dysfunctional for dev, that's why nobody uses it, including enterprises. An elevated shell is not all that one uses, a lot of tools become dysfunctional. For personal desktop it's a different discussion.

 

[Andy Ful]

The design of SUA is usually misunderstood by users. There are no misunderstandings when the application is running on SUA with standard rights (medium integrity level). But, if the application is started on SUA and asks for Administrator rights (you can see UAC prompt), then after allowing it, the application process is started on Administrator account (not on SUA), but still, the application GUI is displayed on SUA desktop. In this case, the application uses two accounts simultaneously. This can be a problem for some applications installed from SUA.

 

[Andy Ful]

It is dysfunctional for dev, that's why nobody uses it, including enterprises. An elevated shell is not all that one uses, a lot of tools become dysfunctional. For personal desktop it's a different discussion.

It is not true in the home environment, if SRP is properly configured to allow elevated processes. It can be true, when SRP is configured to block elevated processes (usually done in enterprises). Using the elevated File Explorer is easy for any administrator - it is much easier than using SRP. If one can use SRP then he/she can use elevated File Explorer, for sure.
If some tools do not like the elevated File Explorer, then they can be simply whitelisted or installed in Program Files (whitelisted by default).

 

[notabot]

The design of SUA is usually misunderstood by users. There are no misunderstandings when the application is running on SUA with standard rights (medium integrity level). But, if the application is started on SUA and asks for Administrator rights (you can see UAC prompt), then after allowing it, the application process is started on Administrator account (not on SUA), but still, the application GUI is displayed on SUA desktop. In this case, the application uses two accounts simultaneously. This can be a problem for some applications installed from SUA.

What Andy says, also manifests with vendor tools that come pre-installed and then the account changes to SUA. To the extent that it's vendor tools + 1-2 more it's still not a biggie but it's a bit of a nag.

 

[notabot]

It is not true in the home environment, if SRP is properly configured to allow elevated processes. It can be true, when SRP is configured to block elevated processes (usually done in enterprises). Using the elevated File Explorer is easy for any administrator - it is much easier than using SRP.

SRP breaks Docker for me, it breaks auto correct in PyCharm and many others, the time investment to narrow it down to which ones can be excluded makes SRP an unproductive setup.
SRP is also a pain when trying out new runtimes, which can happen often during the design phase.

In fortune 500 enterprises I've worked, SRP type of restrictions were lifted after dev team complaints, and in one incident someone for security was fired (dev envs stopped working for 200 folks for 2 days due to whitelisting), in series B/C startups there's no SRP-like mechanism for corporate desktops anyhow (they don't use Windows typically though).

whitelisting is not a good approach when it costs productivity

For personal use it's a different story, there SRP has minimal conflicts.

 

[Andy Ful]

What Andy says, also manifests with vendor tools that come pre-installed and then the account changes to SUA. ...

Could you say more about it?

 

[notabot]

Could you say more about it?

E.g. driver update tools by laptop vendors. Once the user account is changed to SUA, the vendor driver update tools for my laptop only work from the admin account, not when they run elevated from SUA account.

 

[Andy Ful]

SRP breaks Docker for me, it breaks auto correct in PyCharm and many others, the time investment to narrow it down to which ones can be excluded makes SRP an unproductive setup.
SRP is also a pain when trying out new runtimes, which can happen often during the design phase.

Working with Docker containers can be probably a challenge. I do not know if it is possible to make it work safely and flawlessly with pure default-deny SRP (I never did anything with Docker).
When using such programming platforms like Docker or PyCharm, you will have problems with any strong security setup. Using the elevated File Explorer + SRP is probably the simplest solution. You can also use SRP with 'Allow EXE and TMP', then all EXE files will not be restricted by SRP.

In fortune 500 enterprises I've worked, SRP type of restrictions were lifted after dev team complaints, and in one incident someone for security was fired (dev envs stopped working for 200 folks for 2 days due to whitelisting), in series B/C startups there's no SRP-like mechanism for corporate desktops anyhow (they don't use Windows typically though).

whitelisting is not a good approach when it costs productivity

For personal use it's a different story, there SRP has minimal conflicts.

That is right. SRP in enterprises is OK, only when people use the standard set of applications. Then, adjusting the SRP setup can be done on one computer and quickly repeated on all computers. If there are many computers with different applications, then there is much work for Administrators and many complaints from the users.

 

[ForgottenSeer 823865]

I have to admit i just have a good laugh after reading the few posts above, as @Andy Ful said most don't have a clue of what is SUA vs Admin purpose.

SUA is a restricted account made for daily use like surfing, watching videos, gaming, etc...
Admin account is for all ADMIN task: maintenance, drivers/softs/program/OS updates, etc...

the problem is that in the past decades, Microsoft stupidly set everybody to use an admin account by default, so devs of all sorts just used to program their software to be used on admin account when it was not necessary.

in enterprises, only the bad admin would use Admin account for others than himself, because admin are supposed to administrate, if they want browse, they use another computer or switch users.

In fortune 500 enterprises I've worked, SRP type of restrictions were lifted after dev team complaints,

those people should be fired, they are the ones why ransomware hit most companies/organizations so hard.
They are just lazy and refuse to adapt their working methodology for a safer environment.

and in one incident someone for security was fired (dev envs stopped working for 200 folks for 2 days due to whitelisting).

before implementing, SRP you have to intensively test the policy. The admin was faulty because of ignorance and carelesssness, SRP isn't faulty, SRP is the best security mechanism if properly used. There is a reason why most 3rd party corporate products from kaspersky, McAffee, Symantec, Sophos all implement some kind of SRP.

whitelisting is not a good approach when it costs productivity

If used without proper testing and implementation.

For personal use it's a different story, there SRP has minimal conflicts.

SRP isn't made for personal use, it is made for static systems like you have in corporate environment.

Notabot, i'm sorry to say that but your understanding and view of SRP is all wrong.