<< PREVIOUS  NEXT >>

APP CONTROL POLICIES MANAGEMENT

Virsec Security Platform uses a dual strategy of system integrity assurance and runtime protection to ensure that even the most advanced attackers cannot exploit the server infrastructure for any malicious act.

The host security module of VSP forms the foundational aspect of the server workload protection by ensuring that only authorized, trusted and safe executables are running on a server, thereby ensuring that even zero-day threats are blocked immediately from execution. This stops a large majority of kill chains at the initial stage of the typical attack kill chain itself, not leaving any room for post-exploitation execution.

While Process and Library monitoring capabilities of VSP ensure only the processes and libraries that are pristine, trusted and safe can run on the server workloads, malicious actors often leverage advanced defense evasion techniques at various exploitation and post-exploitation stages of an attack cycle. This involves the execution of non-binary entities like scripts and the use of living-off-the-land binary applications. Script execution is difficult to detect using traditional signature-based controls. Living-off-the-land binaries are already a part of these servers in the form of OS packages and other trusted packages that have typical uses in enterprises. This makes it particularly critical for their usage to be controlled to allow regular business operations to continue, but it does not let attackers weaponize them.

Typical use cases for AppControl policies are:

1. Script-based attack prevention

2. Living-off-the-land attack prevention

3. Protection against defense evasion techniques

4. Critical data collection

5. Lateral Movement Prevention

6. Protection against Persistence

7. Remote-Code Execution

AppControl Policies allow control over the dynamic execution of otherwise genuine binary applications. Through AppControl Policies, VSP users can:

1. Block a particular binary application from running under all circumstances, even if they are generally trusted

    

   Example:

   Block mshta.exe that attackers use to execute javascript/vbscript hosted on a remote web server.

    

2. For binary applications that act as interpreters and allow file-based scripts to be executed, this feature provides the definition of an allow-list of such scripts

    

   Example:

   Allowing only certain powershell, bat, shell, python scripts

    

3. Control the execution of these binaries by ensuring

   1. Only specific command-line arguments and flags are allowed, or

   2. Some risky command-line arguments and flags are disallowed

       

      Example:

      Block "-encodedcommand" flag for powershell, used to obfuscate malicious powershell payload or allow only "CREATE" for schtasks.exe to ensure tampering with scheduled tasks is not possible.

       

   3. From VSP 2.8, the provided regex is compared only against the parameters and not the actual command:

      1. When the command: "/bin/ls /home/test" is executed, the commandline regex is valuated against: "/home/test"

      2. To match an empty commandline using a commandline regex, the user can provide "^$" as the regex input string

   4. For releases VSP 2.7 and below, the provided regex is compared against the command and the parameters

      1. When the command: "/bin/ls /home/test" is executed, the commandline regex is valuated against: "/bin/ls /home/test"

      2. To match an empty commandline using a commandline regex, the user can provide "^/bin/ls$" as the regex input string

4. Put additional access control on these binaries to put an allowlist or denylist for these processes so that either

   1. Only a certain set of users are allowed to run these applications, OR

   2. A specific set of users are always denied to run these applications

    

   Example:

   Restricting usage of certain Linux commands only to root user

    

5. Put a runtime control on what kind of parent processes are

   1. Allowed to spawn a child process of the binary application in scope

   2. Disallowed to spawn a child process of the binary application in scope

    

   Example:

   For binary applications powershell.exe, the only parent process that is allowed is explorer.exe, thereby allowing PowerShell execution through only interactive sessions.
   mshta.exe can be blocked, that attackers use to execute javascript/vbscript hosted on a remote web server

    

6. Put additional runtime control on allowing/disallowing the binary applications to spawn any child process

    

   Example:

   For binary applications cmd.exe, iis.exe cannot be a parent process, thus potentially stopping remote command execution by exploiting web applications running on iis.exe

    

<< PREVIOUS  NEXT >>