Checking System Readiness for the Bromium Platform

The Bromium Platform has several hardware and software requirements to fully function on an endpoint. Since the Bromium Client itself does not check many of these requirements until after installation, its difficult know ahead of time what machines require remediation prior to deployment.

To address this issue, I wrote PowerShell scripts to take an inventory of machines in your environment and compile a report using minimal infrastructure.


The solution is designed to be deployed without depending on an endpoint management or software delivery platform. It does however require a scheduled task to run the Endpoint_CDABromiumReadiness.PS1 on each endpoint and a centralized file share where the script can save the collected inventory data. To summarize, the following components are necessary for this solution to work:

  • File Shares – Location for collected data
  • Scheduled Task – Executes the BromiumReadiness script
  • BromiumReadiness PowerShell script – Collects inventory data from endpoint
  • Compiler script – Aggregates collected data into a readable report

File Shares

The Endpoint_CDABromiumReadiness.PS1 collects inventory data from the endpoint and although it could be stored on the machine itself, it would require a significant amount of overhead to log into each machine and gather the data. To facilitate a simpler method of data collection, the script is designed to write the inventory data to a centralized file share. This file share can be one that already exists in your environment or can be created for the purpose of this solution.

The example that I used to create the file share where the script will store inventory data has these properties:

  • Name of folder: TestShare
  • Name of share: TestShare
  • Share permissions: Allow: Change, Read
  • Folder permissions: Allow: Create files / write data, Create folders / append data

Figure 1 – Share Permissions: Allow: Change, Read

NOTE: The name TestShare is used as an example. A more descriptive name would be preferable

Figure 2 – Folder Permissions: Allow: Create files / write data, Create folders / append data

The other file share will be a network location where the Endpoint_CDABromiumReadiness.PS1 PowerShell script can be stored for execution during the Scheduled Task. This file share can be a Read Only location as the script is only read from this location.

The example that I use for a file share location where I store this script is:

Scheduled Task

Since there is no requirement to use a software delivery platform to deploy the Endpoint_CDABromiumReadiness.PS1, the simplest method for deployment and execution of the script is to use a Scheduled Task. Creating the scheduled task on each workstation would be time consuming and inefficient so the better approach would be to simply create the Scheduled Task through an Active Directory Computer Configuration GPO preference. An existing GPO or a new GPO can be used and needs to be linked to the OU or OUs that contain the workstations in the environment.

To create a Scheduled Task as a GPO preference, open the GPO using the Group Policy Management Console (GPMC) and navigate to:

Computer Configuration > Control Panel Settings > Scheduled Tasks

Figure 3 – GPO Preference – Scheduled Tasks

Right-Click “Scheduled Tasks” and choose New > Scheduled Task (Windows Vista and later)

A New Task (Windows Vista and later) Properties window should appear as follows:

Figure 4 – New Task (Windows Vista and later) Properties

Change the Action dropdown from Update to “Create”

Under the General tab, the following parameters should be entered:

  • Name: Bromium Readiness
  • User Account: NT AUTHORITY\System
  • Security Options: Run whether user is logged on or not
  • Security Options: Run with highest privileges
  • Hidden: Enabled

Figure 5 – General tab

Under the Actions tab, click “New” then in the New Action window, enter the following:


Add Arguments(optional):

Figure 6 – New Action window

NOTE: The name of the file server and shares are used as an example. Your UNC path would include the location of the Endpoint_CDABromiumReadiness.PS1 in a central file share and the data collection file share as created above. These UNC paths may not necessarily be the same.

Under the Triggers tab, click “New” then in the New Trigger window define the parameters for when to execute the scheduled task:

Figure 7 – New Trigger window

The script should be run at least once but it would be advised to not run the script continuously as the inventory data should only be necessary to collect information to assess the machine’s readiness to deploy the Bromium Client. It is not designed to be a maintenance task.

When the Scheduled Task executes, the Endpoint_CDABromiumReadiness.PS1 PowerShell script will gather the required information from the endpoints, generate a tsv file, and copy the file to the file share you set after the “CopyToLocation” parameter.

BromiumReadiness Script

This PowerShell script collects the inventory data from the endpoints and is contained here:

Figure 8 – BromiumReadiness script

Compiler Script

This PowerShell script aggregates the inventory data located in the file share from all of the individual tsv files generated from each endpoint into a single file that can be reviewed in Excel.

The Compiler_CDABromiumReadiness.PS1 is contained within the zip file.

Figure 9 – Compiler script

It is preferable to keep the Compiler script in the same file share as the tsv files that are generated so that it can be run as needed.

Figure 10 – Compiler script stored in file share

To execute the compiler script, open Windows PowerShell and run:

A finished report will look like this:

Figure 11 – Finished report

Running Multiple Rounds of Readiness Checks (Optional)

If the Scheduled Task runs multiple times, it will overwrite the inventory data that was previously collected for the endpoints. To prevent the data from getting overwritten, a method to keep previous data collections would be to run multiple rounds of readiness checks. This could also be important in a situation where you need to run the inventory more than once and you expect different results.

To do this, simply add the -ReadinessCheckRound parameter to the end of the execution of the BromiumReadiness script with a number indicating the round. This parameter is set to 1 by default and tags the tsv files. Notice in the image that the number 1 precedes the device name:

Figure 12 – Round number in tsv file name

And here is an example of the command line to use. Change the command line in the scheduled task that was created in the GPO to include the -ReadinessCheckRound parameter.

-ExecutionPolicy Bypass -Command "& '\\dc01\ScriptShare\Endpoint_CDABromiumReadiness.ps1' -CopyToLocation '\\dc01\testshare\'" -ReadinessCheckRound 2

When the scheduled task runs again, the Endpoint_CDABromiumReadiness.PS1 script will generate tsv files with the round number preceding the name of the device:

Figure 13 – TSV files with multiple rounds

Add the -ReadinessCheckRound parameter when executing the Compiler script and the new report generated will show only data from that round.

Figure 14 – Compiled report from round


Aman Motazedian
Senior Consultant
Critical Design Associates

LinkedIn Profile

SWIFT Wire Transfer Security for the Banking Industry


Banks and financial institutions across the world have lost millions of dollars since 2015 due to cybercrime, with one of the primary targets being the SWIFT wire transfer system.

To combat this crisis SWIFT has presented new guidance for financial institutions to help with maintaining proper security standards and to ensure criminals cannot gain unauthorized access to financial systems.

Banks are a commonly targeted by cybercriminals. In addition to constant phishing threats, banks deal with security issues regarding legacy browsers, operating systems, and applications. The dependence on legacy technology often allows attackers to easily gain access to valuable assets.

Cyber-attackers used these legacy applications, phishing, and other techniques to gain access to multiple banks across the world allowing them to successfully steal hundreds of millions of dollars. The cyber-attackers were extremely careful and patient monitoring the individual banks’ environments for months allowing them to gain multiple credentials, record regular SWIFT transfers and plan virtually untraceable transactions.

How can banks protect themselves against these types of attacks?

Critical Design Associates has had success assisting top banks in the United States build secure delivery platforms with a particular emphasis on SWIFT and wire transfer systems. Delivering a secure platform requires many layers of security and a clear understanding of the wire transfer security requirements.

What is our solution? Critical Design recommends a multi-layered approach using the people, process, platform approach. These solutions often focus on the following areas:

People: Reviewing the existing system user authentication, authorization, and auditing roles within the organization and verifying that access is effectively limited and monitored by design.

Process: Reviewing, building or modifying the existing processes to achieve a more secure and auditable system with as many security barriers and sensors as possible to thwart fraudulent behavior. We also work with our customers to ensure effective response processes are in place based on the “assume you are breached” concept.

Platform: Building secure enclaves, thereby limiting access to “locked down” workstations, servers, data, and networks where wire transfers are performed. This is achieved by:

  • Applying industry standard security configurations
  • Implementing Multi-factor Authentication (“MFA”) and requiring multiple forms of authentication and authorization, above and beyond the typical two-factor systems where only a username, password and token code is required (i.e. Vasco and RSA). The design model we deliver adds additional layers of authentication, authorization, and auditing by adding group level, device level, and application level restrictions. This minimizes the attack surface significantly.
  • Deploying Next Generation Anti-Virus (“NGAV”): NGAV not only protects against commodity malware but is also able to prevent novel attacks by evaluating behavior and context. This provides visibility to identify all vital information in the “kill chain” to remediate the attack.
  • Implementing Application Controls/Whitelisting: While this approach is not “fool proof” it does provide for additional security and another opportunity to trigger on abnormal or malicious activity. Application Control provides tools to determine which users, systems, and applications can communicate at a very granular level.
  • Deploying Non-Persistent Virtualization: A typical attack often requires persistence to be established by the attacker. With non-persistent virtualized computing environments we are able to protect against many forms of attacks where persistence is required.
  • Deploying Micro-Segmentation solutions for desktops and servers: This allows for greater control, sensor placement, and containment of threats. Granularly restricted network access protects against an attacker’s ability to establish command and control (“C2”). Command and control is a typical tactic employed by criminals after persistence is established. Micro-segmentation allows security policies to be defined explicitly.
  • Employing granular logon and session timeout controls: Time-based session controls add security by determining when and how long a user can have specific applications open before requiring login credentials to be entered again. It also allows for greater monitoring of when computers and applications are being accessed; abnormal access times indicate suspicious behavior and trigger alerts.

Can you confidently say your environment is truly secure? Are you prepared for a cyber-attack?
Let’s make sure your wire transfer system is not vulnerable to these attacks.

Contact us below to continue the conversation