Agent, endpoint and user session

  • Configure Ivanti Workspace Control Agents to always connect to a parent Relay Server, do not allow Agents to connect directly to the Datastore.

  • Configure the User to not have Local Administrator rights so that:

    • The User will not be allowed the option to Uninstall IWC from Windows Control Panel > Programs and Features.

    • The User will not be allowed the option to End Processes of (pfwsmgr.exe, pwrcache.exe, res.exe) from Windows Task Manager.

    • The User will not be allowed to Stop the IWC Services (Agent or PE). The PE (Privileged Execution) Service is responsible for adding Dynamic Privileges to processes in a managed session.

  • Configure Agent Users to not allow access to the IWC application files by Enabling the Security > Data > Files and Folders feature from within the Console.

  • When using Linux, ensure Linux end users do not have root privileges.

  • When using Linux, ensure the SUDO configuration is locked down so only privileged users can access the Superuser functionality.

    • Ensure logging is enabled in a SUDO environment.

The Agent is only as secure as the device it is running on. Securing the endpoint from unauthorized changes is important to protecting the user's environment.

  • Utilize UEFI and SecureBoot for ensuring the integrity of firmware and the Operating systems bootloader. Utilize a Trusted Platform Module plus a pin or key when available. Utilize BIOS Passwords to prevent disabling of security features.

  • Utilize Bitlocker, FileVault, or other hard disk encryption technologies to prevent offline attacks.

  • Follow Microsoft Best Practices in preventing remote use of local accounts:

  • Do not allow non-administrative users to adjust system time.

  • Disable Microsoft Office Macros, or only allow macros that are validated and signed by a trusted authority to run.

  • Utilize Host and Network Based Firewalls whenever possible. Do not allow file sharing, remote desktop, remote registry, or other access from the local subnet or any non-trusted networks.

Securing the user's session is important in preventing unauthorized access of organization resources. Various controls are available within the user's Workspace that help prevent lateral movement and exploitation of user credentials.

  • When a user is required to run an application with Administrative rights, utilize Ivanti Workspace Control to allow the user to only run that specific application with elevated privileges.

  • Enable User Account Control to prompt for credentials on the secure desktop for all users (even administrators).

  • Enforce application allow-listing for all users that can log in to computers.

  • Prevent high privilege users like Domain Administrators from launching applications like Web Browsers or Productivity Tools like Microsoft Outlook.

  • Lock user accounts after consecutive failed log in attempts.

Allow-listing is intended to limit the execution of code on a system to specific programs that have been added to the list of authorized processes. The goal is to provide a secure environment by limiting the types of activities a user can perform. However, it is possible to execute arbitrary code using multiple bypass techniques if you do not block potentially harmful Windows system files from executing.

Definition of Allow-listing Read moreClosedThe National Institute of Standards and Technology (NIST) from U.S. Department of Commerce, states “An application whitelist is a list of applications and application components that are authorized for use in an organization. Application whitelisting technologies use whitelists to control which applications are permitted to execute on a host. This helps to stop the execution of malware, unlicensed software, and other unauthorized software”.More information can be found by reviewing the NIST Special Publication 800-167, Guide to Application Whitelisting. This publication is intended to assist organizations in understanding the basics of application whitelisting. It also explains planning and implementation for whitelisting technologies throughout the security deployment lifecycle.

From an IvantiWorkspace Control perspective, allow-listing is:

  • Active during Interactive Sessions for Windows, generally defined as when a user signs into a system and receives a Windows Explorer-based session. These include:

    • Local Logon, i.e. “at the keyboard”

    • RunAs.exe

    • Remote Desktop, VNC, TeamViewer, etc.

    • VDI solutions: Citrix, VMWare, Microsoft

    • Citrix XenApp, VMware ThinApp, Microsoft RDSH application sessions

  • Inactive during Network-Based or System Process such as:

    • PSExec.exe. Applications launched using a different user security context than the current logged in user are not protected by Ivanti Workspace Control.

    • PowerShell remoting, SSH session, or any remote “shell” sessions are not protected, i.e. allow-listing is not active for these type of sessions/activities.

IWC protects interactive user sessions only, so that Windows services and background process will remain fully functional. Authorized files security can be enhanced by checking the executable's file hash which requires the population of allowed/denied file hashes, or by checking the certificate signing properties of a file.

Organizations deploying application allow-listing technologies should utilize the Learning Mode to identify all necessary applications to be approved on the allow-list. In this mode, attempts to start unauthorized applications and executables will not be blocked, but they will be logged and made available in the console. This helps you identify and authorize any executables that are started by users. When you have fine-tuned your environment sufficiently in Learning mode, you can set Application security to Enabled mode. Learning mode should only be enabled for a short period of time to prevent any security risk.

Monitor the Security > Managed Application > Log frequently. This log shows who accessed which unauthorized file on which computer. Also, here, unauthorized files can be authorized (added to the allow-list) on an individual basis per user need, security impact, or an organization’s governance policy.

Some standard Windows OS files have the ability to load a harmful script and run it as a regular executable program. It is advised to assess the inclusion of these files to your allow-list very cautiously.

For example, you may want to deny files such as: rundll32.exe, powershell.exe, cscript.exe, wscript.exe, msbuild.exe, regsvr32.exe or any other application that offers a full-blown scripting and/or development environment.

Other files that require consideration before adding to the allow-list are:

  • msconfig.exe

  • reg.exe

  • regedt32.exe

  • at.exe

  • runonce.exe

  • taskschd.msc

  • powershell_ise.exe

  • schtasks.exe

  • regedit.exe

  • wt.exe

The files listed above are only a sample representation in the Windows OS. This same analysis should be conducted on other operating systems present in the users environment, such as Linux and MAC. For a more comprehensive list, see Microsoft recommended block rules.