The Definitive guide to Ivanti Endpoint Security

Version 7

    Verified Product Versions

    LANDESK Management Suite 9.6LANDESK Management Suite 2016.xLANDESK Endpoint Manager 2017.x

    Ivanti’s Endpoint Security – Application Security

     

     

    Overview

    The Ivanti endpoint security agent (EPS) provides two main ways to protect applications running on the endpoint: application behavior protection and whitelisting protection. Application behavior protects applications against malicious change to the application itself (for example protect against in-memory attacks), whitelisting prevents untrusted applications from running. Those are 2 independent components and as such, each component can be enabled or disabled independently.

     

    The EPS agent protects itself and other Ivanti agents from tampering. The EPS agent will prevent deleting/modifying files protected by it. This protection is always active and does not require any configuration.

    Note: this document is designed to explain Ivanti’s endpoint protection for applications. The EPS agent also include, in addition to the capacities described in this document, the capabilities to protect against malicious import/export of data to/from removable devices (i.e. device control). The EPS agent can also encrypt data saved to external devices.

    Application Behavior

    Application behavior provides the following protection capabilities:

    1. Protect against unauthorized read/modify/delete of files by other files (file protection rules).
    2. Protect against ransomware
    3. Protect against malicious changes to an application.  This includes:
      1. Protect application in memory. Application memory protects against process injections and unauthorized memory access. This is used to prevent malicious software to run in-memory attack bypassing whitelisting controls.
      2. Protect against buffer overflow.
      3. Prevent one application from running other files
      4. Prevent from modifying protected registry key.
      5. Prevent an application from adding itself or other processes to the startup
      6. Prevent the application from sending emails

    How to enable application behavior

    To enable all the application behavior capabilities, check the enable checkbox under Application Control agent settings -> General Settings tab. Once enabled choose the operation mode:

    • Block: enforce the policy and stop all activities that don’t comply with the policy.
    • Learn: monitor each application behavior and build a baseline.
    • Log: don’t block in case of violation but only report back to the core. This is an auditing mode.

     

    Note: only block mode will actively enforce all the file protection rules, the ransomware protections and the protection against malicious changes to an application.

    All modes send logs (auditing logs) to the core. The difference between all modes is the enforcement used. All audit logs can be viewed from the console under the Security Activity -> Application Control tab. In 2017.1 all those audit logs can be sent to Syslog server using the Alerts mechanism.

    What happens in learning and blocking modes?

    Except for numbers 1 and 2 all other capabilities (3a-3f) rely on the learning mode to build the baseline for each protected application. It is important to run in learning mode for a few days before changing to block mode.  During the learning period, EPS will build the baseline for each application running on the endpoint. EPS will learn if the application is executing other files, modifying protected registry keys etc. EPS will update each application baseline based on what was learned (for example in case the application is executing other files, this application will be allowed to execute files in the future ensuring the application will continue to work once switching to block mode). The learning mode assumes the endpoint is “clean”.

     

    During the learning period, every learned file is added to the “learning” application file list (the one defined in the agent settings). Opening the application file list in the console will show a list of all learned applications. Double clicking on each application in the list will open a new window which details the attributes of the specific file. This window allows overriding learned behavior or setting new ones. The following options are relevant for application behavior:

    • Bypass all protections – when enabled permissions are not enforced (check the checkbox to see which permissions are disabled in the console UI).
    • Can modify executable files. If checked, the application is allowed to modify an EXE/DLL/SYS file on disk. Otherwise, it cannot.
    • Can modify protected files – if checked and the Allow trusted files to bypass rule (in the File protection rule settings) is checked – this file will not be affected by the specific file protection rule.
    • Can modify protected registry keys. Protected registry keys are a set of pre-defined list of keys that cannot be edited by the customer.
    • Can be added to system startup and can send emails – as the name suggests.
    • Inherit permission to child processes – all processes that are span by the specific application will have the same permissions as their parent.
    • Bypass buffer overflow protection. Buffer overflow works only on Windows X32
    • Do not protect application in memory.
    • Lock application file rights from modifications (file rights will not be updated via learning mode) – Prevent the assigned permissions to be overridden by some learned permissions (if the EPS client is running in learning mode on some computer the learned capabilities will not be used).
    • Ivanti firewall: outbound & inbound connections – control inbound and outbound traffic for this specific application.
    • For applications that are signed by a trusted signer (as configured in the digital signature tab under Endpoint security) the permissions are set automatically based on the following defaults:
      • Allow execution
      • Can modify executable files
      • Can modify protected registry keys
      • Can be added to system startup
      • Allow this file to connect (Trusted scope and Internet)
    • If a file was run from a trusted folder (as configured in the trusted folders tab under Endpoint security) the permissions are set based on the permissions assigned to the folder (permissions are set when adding a trusted folder).
    • For both “treat good reputation files as if they are in the associated trusted file list” and “automatically include good reputation files when sending list to clients” the admin can configure the permission to set.
      • “treat good reputation files as if they are in the associated trusted file list” is a whitelisting feature (see whitelisting section to learn more)
      • “automatically include good reputation files when sending the list to clients” is part of the application file list. When enabled, each application that has a good reputation will be assigned with the permissions as defined for this checkbox (definition is done when clicking on the special Allows application behavior button).
    • Each file that is in an application file list receives the assigned permissions. EPS will enforce the assigned permission for this file for each one of this file instances on all endpoints that use this application file list.
    • If the file is not in the above categories, it won’t get any permission and as a result, it won’t be allowed to bypass any restricted operations (operation that belong to all the EPS permissions)

    What happens to new applications running for the first time when in block or log mode

    Application Behavior – Ransomware Protection Settings

    Application Control -> General Settings:

    • Application behavior: enabling both the “restrict access to physical drives” and the “auto detect and blacklist crypto-ransomware” will provide protection against ransomware.
    • When “restrict access to physical drives” is enabled, ransomware like Peyta cannot encrypt the master boot record (MBR). Specifically, when enabled no process can modify the MBR. To enable specific processes to bypass this rule, add those processes to the associated application file list and make sure the “bypass all protection” checkbox is checked (double click on the application in the list to see its permission and enable “bypass all protection”).
    • When “auto detect and blacklist crypto-ransomware” is enabled, the EPS client will detect any new process that tries to encrypt files, kill the process so it will not be able to encrypt other files and add this file to the blacklist. That is the file will be added to the application file list as a “blocked execution” file. On the next sync of each endpoint with the core, the updated application file list will be downloaded to the endpoint blacklisting the specific file detected as a ransomware. In some rare circumstances, an application (i.e. encryption software) might be erroneously detected as a crypto- ransomware. In such situation, add this software to the application file list, so it won’t be blocked by the EPS client. No specific permission is required (only “Allow execution”).
      Note: in case this feature is enabled, blacklisting will be enforced even if the whitelisting feature is disabled.
    • Make sure application behavior is set to block mode for those ransomware protections to be able to actively block the ransomware.

    File Protection Rules

    Use file protection rules as a second layer of defense against ransomware. This will prevent the ransomware from encrypting files on the infected endpoint. To learn more visit this link: https://community.ivanti.com/docs/DOC-40939

    Scripts – Protect against the most common infection method (old and NEW features)

    File protection rules can also be used to block the most common way endpoints are getting infected by a malware (or ransomware). That is, the user is tricked to open a file that contains the malware. This is usually involved a phishing email that tricks a user to open an attachment or to download a file from the internet. The vast majority of those files users are tricked to open are of known types - word document with Macros, .JS (JavaScript) files and other types of scripts.

     

    Using file protection rules admins can set rules that prevent .JS files and other scripts to be used by users

    Note: This does not limit users from using JavaScript in their browser). By blocking the usage of scripts (which most users do not need to use) a large portion of this attack vector can be eliminated.

    It is most likely that users will not need to run scripts on their machines however in some cases legitimate 3rd party applications may need to run scripts. For that reason, it is recommended to start using file protection rules in learning mode (i.e. set the application behavior mode to learn). In this mode, the EPS agent learns which applications are running scripts and will not block the usage of scripts by those applications once changing to blocking mode.

     

    For example, using file protection rules one can configure the following rule: don’t allow WSCRIPT and CSCRIPT to run *.JS files. Once enforced, users will not be able to use the Microsoft scripting engine (wscript/cscript) to run .js files. Make sure to enable the “allow trusted files to bypass the rule” checkbox as this checkbox bypasses this protection for applications that were learnt to be using WSCRIPT to run .JS files (during the learning period).

     

    New in 2017:

    Two new options were added to file protection rules as well as 2 new pre-defined rules. Those are meant to help in blocking users from running scripts from a browser or mail application even though the scripts were downloaded inside a ZIP file.

     

    “Apply if the process is in the execution chain”. When enabled, monitored programs are any program in the “chain of execution”.
    For example, in case a user runs chrome and opens a .js file downloaded by chrome (i.e .the user “double clicks” the “.js” file after it has been downloaded by Chrome), the chain of execution will be chrome -> wscript -> .js. When this checkbox is enabled, the “monitored program” can be Chrome and the “protected files” can be *.js. This will ensure any JS file that runs from Chrome is blocked.

    A new out-of-the-box file protection rule is designed to prevent script execution from a browser or a mail application. This rule is designed to prevent a set of browsers and mailers (as defined in this rule) from running CMD, CSCRIPT, WSCRIPT and POWERSHELL. This will block any attempt to run a script by a browser or a mail app (this applies only to scripts that run “outside” the browser – not JavaScript running in the browser as part of a website).

     

    Important note: there is one common case where using the “Apply if the process is in the execution chain” will not block execution of scripts. This is in case the script is packed into a ZIP file and the user extracts the zip using the native Windows ZIP extractor (and not using 3rd party app). However, this rule will work to block an attachment zip file that is opened by WINZIP and then the user runs a script which was inside the ZIP file.

    To solve the above problem a second option was added to 2017.1, “Apply only to files downloaded from the Internet”. By default, every file that is downloaded by a browser is “flagged” by the browser as “downloaded from the internet”. This flag is kept with the file even if the file is copied (this flag only applies to files on a NTFS file system). When this checkbox is enabled, the rule will only apply to files that has this flag enabled.


    A new out-of-the-box rule uses this feature to prevent script execution from files downloaded from the internet by a browser (“Prevent access to downloaded scripts”). When a user downloads a zip file from the internet, if the zip includes a script (.bat, .cmd, .js, .vbs), the script will be blocked from been executed, even if the zip was extracted using the native windows zip application and even if the file was saved to disk and extracted in a later stage.

     

    Another Layer of Security:

    In addition, running application behavior in learning mode provides another important benefit. During learning mode all legitimate app network behavior is learned (i.e. learn if an application/script is connecting to the internet as part of their legit operation). Once switching application behavior to blocking mode, new apps/scripts running will not have access to the internet. Since the majority of malware infecting endpoints must “call home”, the application behavior, configured as suggested above, will block any attempt of new malicious applications/scripts to “call home” disabling the malware effectiveness and in most cases rendering the malware useless.

     

    Note: The “Treat scripts as executable files” checkbox must be enabled for the above feature to work. This checkbox is found under the Application Control agent settings -> general settings -> enable whitelisting (even thought this checkbox is placed under the whitelisting section in the UI it is relevant in order to allow learning on network activity for applications).

     

    Block Macro Files: A policy to block macro files can be deployed using the Ivanti patch engine. Downloading security content will download a content item to help with macro blocking enforcement (the content name is ST_BlockOfficeMacros).  This content is only available to block macros on Office 2016.

    Whitelisting

    Once enforced a whitelisting rule will only allow trusted applications to run on the endpoint. Whitelisting can also be used in “log” mode providing an audit trail of all untrusted applications run by users (in this case no application is actively blocked).

     

    The trusted applications list can be dynamically created based on the following:

    • All applications that are found in a gold image (or any other image)
    • All applications signed by a trusted vendor
    • All applications running from trusted folders
    • All applications that have good file reputation (as defined in Ivanti’s cloud-based file reputation service at the time the application is launched)
    • All files that are copied to local storage by a trusted installer
    • All applications running on the endpoint during the learning period (i.e. assume the endpoint is “clean” and trust all applications the user actually uses)
    • All files updated by Ivanti patch

     

    In addition, trusted applications can be added manually or requested by the end user.

    How to enable whitelisting

    To enable all whitelisting capabilities, check the checkbox under Application Control agent settings -> General Settings tab. Once enabled choose the operation mode:

    • Block: only trusted applications can run on the endpoint. Other applications will be blocked.
    • Learn: monitor all applications running on the endpoint and trust them by default (see below to learn more about learning mode).
    • Log: don’t block in case of violation (i.e. if the application is not trusted) but only report back to the core. This is an auditing mode.

    All modes send logs (auditing logs) to the core. The difference between all modes is the enforcement used. All audit logs can be viewed from the console under the Security Activity -> Application Control tab. In 2017.1 all those audit logs can be sent to Syslog server using the Alerts mechanism.

    How to build trust policies

    Import from gold image

    Create a new Application File list agent settings (found under the agent settings -> Security -> Endpoint security). In the Application file list window, click the import button (the yellow button on top of the list) and import files from other gold images or CSV (the import from trusted devices option is the one that can be used to import from “gold” images). All files added to this application file list will be trusted by this policy.

     

    Trust based on vendor (i.e. based on signature):

    • Create a new Endpoint Security agent settings or update an existing one. Choose the digital signature tab. Check the 3rd option: “Trust digital signed application from these vendors”. You may add more trusted vendors to this list.
    • Discovered vendors are vendors that are discovered by the EPS agent. Each time an EPS client see a new digital signer, it sends the info to the core. That's how the list of trusted signers get populated on the core.
    • When trusted installer is enabled, an installer that is signed by this signature is trusted. In such case, all files installed by the installer are also trusted.  You may use this option in case a vendor has an auto-update capability. This will ensure that the application can update itself and still be trusted.
    • Each file that the user will run on his endpoint and has the trusted signature will be allowed to run. No further configuration is required.

    Trust based on the folder the application was running from:

    • Create a new Endpoint Security agent settings or update an existing one. Choose the trusted folder tab
    • All files in the trusted folders are trusted and allow to run
    • For example, if you add c:\myfolder\ as trusted, the user will be able to run all files under c:\myfolder\ on his machine

    Allow application with a good reputation to run:

    • Create a new Application Control agent settings or update an existing one. Choose the general settings tab
    • Ensure the “treat good reputation files as if they are in the associated trusted file list” is checked.
    • Once the policy is deployed, each time a user run a new application that is “unknown” to the EPS agent, the EPS agent will “ask” the core if this new application is trusted, if the core does not have information about this application, the core will “ask” the Ivanti cloud service if this application is known or not. The Ivanti cloud service will determine if this application has a good reputation or not. Based on the response, the agent will allow/block the application from running. In case the application has a good reputation, the relevant application file list will be updated with the new file.
      Note: Users will experience a short delay before the application can run as the EPS agent is waiting for a response from the core.

    Allow trusted installer to install other applications:

    • As explained in the trust based on vendor section, trusted vendors can be treated as installers (see above).
    • In addition, individual files can be treated as trusted installers. This is configured from the application file list settings:
      • Open the application file list that is associated with the endpoint security policy
      • Find the file in the list or add a new file (using the green plus button).
      • Double click on the file and enable the “this is an authorized installer”
      • The chosen file will be treated as an authorized installer and as a result, it can install other files which will also be trusted by EPS

     

    Learn applications used by user:

    To use the learning capabilities, ensure that the policy is set to learning mode. In learning mode, EPS will monitor all applications that run on each endpoint. The applications information (as detected by EPS on all endpoints) will be sent to the core and will be added to the learning list (the application file list defined in the Endpoint security -> default policy tab -> learning list). Each application in the list will have a file reputation value as defined by the Ivanti cloud file reputation service. In case the application has “bad” reputation it will be automatically flagged as blocked (and cannot run on the endpoint by all users), otherwise the application will be flagged as “allowed” so users can run this application (i.e. this is a trusted application). To change the default setting, double click on the file (in the application file list window) and choose “allow execution” or “block execution”.

     

    Application File Lists:

    For each Endpoint security agent settings, you have to define which application file list to use and which learning list to use. You may define more than 1 application file list per policy.  All the defined application file lists are used by the EPS client for enforcement – i.e. those are the list of trusted applications that can run or be blocked. If more than one application file list is used (this includes the learning application file list), the EPS client will merge all lists on the client side.

    When the learning period is over, all the lists (even the “learning list”) are used for enforcement

    For every file that the user runs the EPS agent will check if the file complies with a trusted policy (for example is it signed by a trusted vendor) or if the file is found in one of the application file lists that are associated with the policy (and if the file is allowed to run or blocked).

     

    Whitelisting and scripts:

    Under the Application Control agent settings -> general settings -> enable whitelisting there is a checkbox to “Treat scripts as executable files”.

    There are 3 options to choose from:

    1. 1.      “Windows Script host”. This will track users opening .js and .vbs scripts that are opened by using the native Windows scripting engine (wscript & cscript)
    2. 2.      “Windows batch script”. This will track users opening .bat scripts using CMD
    3. 3.      “Windows PowerShell scripts”. This will track users opening .ps1 (PowerShell) scripts using powershell.exe

    If at least one of the 3 options are selected, EPS will treat the scripts the same way executables are treated.

    For example, if a user opens 2 PowerShell files, a.ps1 and b.ps1 and whitelisting is set to blocking mode, a.ps1 will be blocked if it is not defined as a trusted application but b.ps1 will run if it is defined as a trusted application (i.e. b.ps1 is in the associated applications file list). If whitelisting is set to learning mode, for this example, 2 new entries will be added to the trusted file list: a.ps1 and b.ps1.

    Note: The above is new in 2017.1. The same functionality can be found in 2016.3 SU3 however there are some known limitations in 2016.3.

    Application Firewall

    Ivanti firewall provides an application level firewall – i.e. its rules are enforced per application and not per device.

    Creating Firewall rules

    Create a new Ivanti Firewall agent settings and set it operational mode to block, learn or log.

    Define trusted scopes if appropriate -  a trusted scope is a set of IPs that are trusted and/or internal. If no trusted scope is defined, all traffic will be considered as internet traffic (i.e. untrusted) by EPS.

    Define connection rules if required. Connections rules are similar to rules defined for Microsoft Firewall, the main difference is that EPS enforces those rules on the application level and not on the device level like Microsoft Firewall.

    How does the application firewall work?

    If connection rules are defined, the EPS client will enforce those rules per application and will block or log its action based on the mode.

    In case a firewall rule is configured and associated with a policy, the EPS client can block inbound and outbound traffic per each application. When running in learning mode, the EPS client learns each application network requirements. For example, if during learning mode, application A connects to 10.0.0.1 which is in a trusted scope, the EPS agent will set the “send outbound traffic to trusted scopes” permission for Application A to allow.

    The EPS client can monitor inbound and outbound traffic from/to trusted and un-trusted scopes.

    Once in block mode, if the permission to send outbound traffic to non-trusted scopes is set to disallow, the application will not be able to connect with external untrusted resources.

    The firewall rules per specific application can be overridden from the application file list. Find the required application in the application file list, double-click on the application and change the firewall settings.

    Note: if there is no firewall agent settings associated with the endpoint security policy, the EPS client will not run any network inbound/outbound related activities.

    Malicious Activity Detection

    Auditing

    All EPS activity is sent as auditing logs to the core. All audit logs can be viewed from the console under the Security Activity -> Application Control tab. In 2017.1 all those audit logs can be sent to Syslog server using the Alerts mechanism

    Malicious activity detection

    When creating a new endpoint security agent setting, under the general settings tab -> administrator there are 2 checkboxes: collect accesses IP/URL and collect CPU and memory. Checking those 2 checkboxes will enable the EPS advanced data gathering capabilities.

    When CPU and memory is enabled, EPS will gather average CPU and memory consumption per each application running.

    When IP/URL is enabled, EPS will track all in/out network traffic per each running application. EPS will calculate bandwidth usage as well as audit all IP/URLs the process connects to/connected from.

    Note that not all network traffic will have a URL associated with it – in such case only IP will be gathered. For efficiency reasons EPS will aggregate data specifically the IP/URL information.

    EPS will gather all CPU, memory and IP/URL readings on the client. The gathered and aggregated information is sent to the core with every inventory sync. This information is part of each device inventory and as such can be accessed from the device inventory view or the query mechanism on the core.

    However, the best way to view this information is from the application information view.

    Application Information View

    To open this view right-click on a device (in the console) and choose the “application information view”.

    The application file reputation shows all applications that were discovered on a chosen device. The following information is available per each application:

    • File name
    • Discovered date – when was this file first discovered (reported by inventory scan)
    • Executed date – when was the file last executed (reported by inventory scan)
    • Reputation – if the file reputation was overridden by the user this will be the override value, otherwise, this is the same as Ivanti reputation.
    • Ivanti Reputation - file reputation as decided by Ivanti cloud reputation database
    • Is the file digitally signed and by which vendor.
    • Inventory: how many devices have the same file
    • Trust count: how may application file lists have this file
    • File meta data: version, company (vendor), product name, path (based on inventory)
    • Received/Sent bytes: the sum of bytes received/sent by this file. This is a good indicator if the file does network activity which may be suspicious
      • Double-clicking on each line in this view will open a new window which will provide information about all the URL/IP this application connected to.
    • Average CPU/memory consumed by the file

    Using the same view admins can take the following actions:

    • Query VirusTotal for the status of a specific file
    • Query Google, IOC bucket and the Ivanti’s community on the validity of a specific file.
    • Run device diagnostics reports
    • Look at inventory details for the device
    • Manage the patch level of the device (and all applications installed on this device)
    • Open a remote control session to the device for further investigation
    • Run AV scan
    • Shutdown or reboot the device

    The application information view does not require the EPS agent to be deployed, however, having EPS deployed will enhance the value of this view as more information will be presented.

    The application information report shows a list of all applications discovered by inventory scan (independent of EPS). It is important to ensure that inventory scan sends the hash value of each scanned file to the core (this can be enabled under the Configure menu -> Services option -> inventory tab -> advanced settings button -> Send All File Hashes).

    The core will calculate the file reputation of each file by default however admins need to download the file reputations content. This is done under “patch and compliance” -> download updates -> in the tree, under windows-security-check the Ivanti file reputation updates.

    Integrating with 3rd Party tools like SIEM tools (new in 2017.1)

    In 2017.1 a new feature will be added to the Alerting mechanism. This new capability will enable admin to configure the core to send all EPS reported audit logs (as can be viewed in the Security activity tab) to a SYSLOG server. To enable this feature, create a new Alert (under the console’s Alert UI – the Flash-based interface) and set Syslog as the action.

    Browser Isolation for not patched browsers (new in 2017.1)

    This is a new policy addition to the Endpoint Security settings. A new tab “intermediate patching” allows admins to create a policy that prevents unpatched browsers from accessing the internet.  As a result, users with un-patched browsers (or browsers that cannot be patched since the patch breaks compatibility with business application) can only access trusted websites (or corporate application sites). This reduces the attack vector on those un-patched browsers as those browsers cannot access the internet and therefore cannot access malicious websites.

    Supported browsers: Chrome, Firefox, Internet Explorer, Opera.

    Unpatched browsers are browsers that vulscan detects that at least one patch is missing.

    In case the browser is unpatched, EPS will block any access to this device to untrusted URL/IPs. Admins can define a list of trusted URLs and IPs as part of this agent settings. The list of trusted IP/URL can be defined manually or imported from inventory (i.e. the list of all IPs of endpoints managed by LDMS).

    How does it work:

    With every vulscan sync, the patch status of the browsers is downloaded from the core. The customer must scan the endpoint for browsers vulnerabilities (“standard” vulscan scanning) in order for EPS to learn the patch level of the browser. If the patch level is not the latest, EPS will only allow the browser to access IPs and URLs that were defined as trusted in the policy.

    Device Network Isolation + Remediation (new in 2017.1)

    The best practice in case an endpoint is suspected to have a malware running (whether the malware was detected by Ivanti’s tools or by 3rd party tools) is to isolate the endpoint from the network ensuring the malware does not spread to other endpoints.

    Ivanti isolation capability provides an end-to-end solution for admins enabling admins to quickly respond to security threats and remediate them as quickly as possible.
    Using Ivanti admins can:

    1. Isolate a device directly from the management console. No need to physically “walk” to the endpoint. A new isolation menu item is added to each device in the console.
    2. Open a remote control session to the isolated device so the security admin can estimate the “damage”
    3. Deploy any type of software or script to the endpoint. Specifically, this is useful to deploy a “one time” AV scanner.  In addition, once installed for the first time, the AV software requires to download its latest virus definitions from the internet. Ivanti allows admins to enable access to the internet for a specific software while the rest of the device is isolated.

    All the above capabilities can be done from one simple view (by enabling the relevant checkboxes) ensuring faster time to remediation.

    A specific icon is shown in the console for each isolated device. The icon represents the EPS client acknowledging it was able to isolate the endpoint.

    How Does It Work:

    When the isolation option is selected a new window is opened allowing admins to choose if to start a remote control session immediately and choose a software package to deploy (list of software packages is imported from the SWD settings). Once selecting the desired options and clicking the ok button the core will immediately try to notify the endpoint (i.e. the EPS agent) using the standard push mechanism. In case the endpoint cannot be connected directly from the core (i.e. the endpoint is connected over CSA), the core will use another push technic leveraging the remote control push capabilities to notify the endpoint.

    Once the EPS agent is notified, the EPS agent will block any network traffic in/out the device on all ports except the LDMS and RC communication ports. This will allow the core to continue and manage the endpoint once the device is isolated. EPS will also allow DNS traffic ensuring the LD agent can continue to operate. In addition, the EPS will only allow traffic to/from the core/CSA on the specific opened ports (i.e. even though the ports required by LDMS are opened they can only be used to send/receive traffic from the LDMS console.

    In addition, if the admin required a software package to be deployed, or an RC session to start the relevant components will be notified (when connected over CSA, the RC mechanism is used to remotely execute the PolicySync.exe on the client to let the client pull the SWD package from the core). For RC, the HTML remote control is launched on the client which is the same as the administrator click the HTML remote control menu item on the console.

    To allow a specific process to connect to the Internet while the device is isolated from the network, open the EPS agent UI and look for the process to allow access. Right-click and chose the relevant option.

     

    Note: The RC agent is required to be installed on the endpoint in-order for the core to be able to push the isolation command to endpoints connecting through CSA.

     

    In addition to the above admins can use the other remediation capabilities of the product, once the endpoint is isolated. These capabilities include:

    • Remote file view and management (delete remote files)
    • Processes view and kill a process
    • Full inventory analysis, understanding which applications were installed on the endpoint, when and when last run
    • Full access to Windows logs remotely
    • Shutdown or reboot the endpoint

    In case the malicious software was removed from the endpoint, admins can “release” the endpoint from isolation. Otherwise, admins can use the reimaging capabilities to re-image the endpoint.

     

    To isolate a device from the network:

     

    1. Right-click the device in the network view.
    2. Choose the option "Isolate from network..."

      The following menu should appear:
      IsolatedMenu.png
    3. You can elect to Do nothing, or you can select a Package from the drop-down.  The drop-down is a selection of software distribution packages.
      As an example, a Provisioning Template to reimage the computer could be saved as a Software Distribution Package and then run to re-image the infected computer.
    4. Click "Start".  After clicking start it will take a few moments for the isolation to take effect.
    5. After the computer is isolated it will show the following icon: Isolated.png
      (Note the red mark in the upper left)

     

    To "release" the device from isolation:

    1. Right-click the device in the network view..
    2. Select the "Recover from isolated..." option.
    3. The computer icon should return to normal.