The Crystal Eye Attack Surface Reduction (CEASR) application ensures devices on your network conform to security policies based on standard security frameworks such as the Australian Signals Directorate's Information Security Manual (ISM) and the Essential Eight guidelines. It also allows CE XDR administrators to apply operating system policies across a range of devices and provide ongoing device monitoring to keep track of your compliance baseline in real-time.
Attack surface are the areas in the digital stack of the organization that can be targeted by attackers to compromise the devices running in the network. The primary mitigation strategy here must be to reduce the attack surface which leaves the attackers with fewer ways to perform malicious attacks. The CEASR application with its Windows hardening feature can be used to configure attack surface reduction rules and other windows 10 (enterprise) security settings.
The following windows hardening rule categories can be applied using the CEASR application:
Attack Surface Reduction: Attack Surface Reduction (ASR) is a security feature in Microsoft Windows 10 version 1709 that forms part of Windows. It is designed to combat the threat of malware exploiting legitimate functionality in Microsoft Office applications. In order to use ASR, Windows Defender Antivirus must be configured as the primary real-time antivirus scanning engine on workstations. Click here to know how to implement this rule
Credential Caching: Cached credentials are stored in the Security Accounts Manager (SAM) database and can allow a user to log onto a workstation they have previously logged onto even if the domain is not available. Whilst this functionality may be desirable from an availability of services perspective, this functionality can be abused by an adversary who can retrieve these cached credentials (potentially Domain Administrator credentials in a worst-case scenario). To reduce this risk, cached credentials should be limited to only one previous logon. Click here to know how to implement this rule
Elevating Privileges: Microsoft Windows provides the ability to require confirmation from users, via the User Access Control (UAC) functionality, before any sensitive actions are performed. The default settings allow privileged users to perform sensitive actions without first providing credentials and while standard users must provide privileged credentials they are not required to do so via a trusted path on the Secure Desktop. This provides an opportunity for an adversary that gains access to an open session of a privileged user to perform sensitive actions at will or for malicious code to capture any credentials entered via a standard user when attempting to elevate their privileges. To reduce this risk, UAC functionality should be implemented to ensure all sensitive actions are authorised by providing credentials on the Secure Desktop. Click here to know how to implement this rule
Credential Entry: When users enter their credentials on a workstation it provides an opportunity for malicious code, such as a key logging application, to capture the credentials. To reduce this risk, users should be authenticated by using a trusted path to enter their credentials on the Secure Desktop. Click here to know how to implement this rule
Operating System Patching: Patches are released either in response to previously disclosed security vulnerabilities or to proactively address security vulnerabilities that have not yet been publicly disclosed. In the case of disclosed security vulnerabilities, it is possible that exploits have already been developed and are freely available in common hacking tools. In the case of patches for security vulnerabilities that have not yet been publicly disclosed, it is relatively easy for an adversary to use freely available tools to identify the security vulnerability being patched and develop an associated exploit. This activity can be undertaken in less than one day and has led to an increase in 1-day attacks. To reduce this risk, operating system patches and driver updates should be centrally managed and deployed in an appropriate timeframe as determined by the severity of the security vulnerability and any mitigating measures already in place. This can be achieved using Microsoft System Centre Configuration Manager (SCCM) 20. Microsoft Windows Server Update Services (WSUS) 21 can also centrally deploy patches but only for Microsoft applications. For more information on determining the severity of security vulnerabilities and timeframes for applying patches see the Assessing Security Vulnerabilities and Applying Patches publication 22. Click here to know how to implement this rule
Early Launch Antimalware: Another key security feature of Trusted Boot supported by Microsoft Windows 10 version 1709 and motherboards with an Unified Extensible Firmware Interface (UEFI) is Early Launch Antimalware (ELAM) 13. Used in conjunction with Secure Boot, an ELAM driver can be registered as the first non-Microsoft driver that will be initialised on a workstation as part of the boot process, thus allowing it to verify all subsequent drivers before they are initialised. The ELAM driver is capable of allowing only known good drivers to initialise; known good and unknown drivers to initialise; known good, unknown and bad but critical drivers to initialise; or all drivers to initialise. To reduce the risk of malicious drivers, only known good drivers should be allowed to be initialised during the boot process. Click here to know how to implement this rule
Exploit Protection: An adversary that develops exploits for Microsoft Windows or third party applications will have a higher success rate when security measures designed by Microsoft to help prevent security vulnerabilities from being exploited are not implemented. Windows Defender Exploit Guard’s Exploit Protection 14 functionality was introduced in Microsoft Windows 10 version 1709 to provide system-wide and application-specific security measures. Exploit Protection is designed to replace the Enhanced Mitigation Experience Toolkit (EMET) that was used on earlier versions of Microsoft Windows 10. System-wide security measures configurable via Exploit Protection include, Control Flow Guard (CFG), Data Execution Prevention (DEP), mandatory Address Space Layout Randomization (ASLR), bottom-up ASLR, Structured Exception Handling Overwrite Protection (SEHOP) and heap corruption protection. Many more application-specific security measures are also available. Click here to know how to implement this rule
Microsoft Edge: Microsoft Edge is a web browser that was first introduced in Microsoft Windows 10 to replace Internet Explorer. Microsoft Edge contains significant security enhancements over Internet Explorer and should be used wherever possible. Internet Explorer 11’s use should be restricted to supporting any legacy web applications hosted on corporate intranets. If Internet Explorer 11 is not required, it should be uninstalled from Microsoft Windows 10 to reduce the operating system’s attack surface. For organisations using Microsoft Edge instead of third party web browsers, the following Group Policy settings can be implemented to harden Microsoft Edge, including Windows Defender SmartScreen 18. Click here to know how to implement this rule
Anonymous Protection: An adversary can use anonymous connections to gather information about the state of workstations. Information that can be gathered from anonymous connections (i.e. using the net use command to connect to the IPC$ share) can include lists of users and groups, SIDs for accounts, lists of shares, workstation policies, operating system versions and patch levels. To reduce this risk, anonymous connections to workstations should be disabled. Click here to know how to implement this rule
Account Lockout Policy: Allowing unlimited attempts to access workstations will fail to prevent an adversary’s attempts to brute force authentication measures. To reduce this risk, accounts should be locked out after a defined number of invalid authentication attempts. The threshold for locking out accounts does not need to be overly restrictive in order to be effective. For example, a threshold of 5 incorrect attempts, with a reset period of 15 minutes for the lockout counter, will prevent any brute force attempt while being unlikely to lock out a legitimate user who accidently enters their password incorrectly a few times. Click here to know how to implement this rule
Password Policy: The use of weak passwords, such as eight-character passwords with no complexity, can allow them to be brute forced within minutes using applications freely available on the Web. In addition, having no maximum password age can allow an adversary to maintain extended access to a workstation or network once a password has been compromised while having no minimum password age can allow an adversary to recycle passwords if forced to change them due to maximum password ages. To reduce this risk, a secure password policy should be implemented. Click here to know how to implement this rule
Antivirus Software: An adversary can develop malicious code to exploit security vulnerabilities in software not detected and remedied by vendors during testing. As significant time and effort is often involved in the development of functioning and reliable exploits, an adversary will often reuse their exploits as much as possible before being forced to develop new exploits. To reduce this risk, endpoint security applications with signature-based antivirus functionality should be implemented. In doing so, signatures should be updated at least on a daily basis. Whilst using signature-based antivirus functionality can assist in reducing risk, they are only effective when a particular piece of malicious code has already been profiled and signatures are current. An adversary can create variants of known malicious code, or develop new unseen malicious code, to bypass traditional signature-based detection mechanisms. To reduce this risk, endpoint security applications with host-based intrusion prevention functionality, or equivalent functionality leveraging cloud-based services, should also be implemented. In doing so, such functionality should be set at the highest level available. Click here to know how to implement this rule
Powershell: Allowing any PowerShell script to execute exposes a workstation to the risk that a malicious script may be unwittingly executed by a user. To reduce this risk, users should not have the ability to execute PowerShell scripts; however, if using PowerShell scripts is an essential business requirement, only signed scripts should be allowed to execute. Ensuring that only signed scripts are allowed to execute can provide a level of assurance that a script is trusted and has been endorsed as having a legitimate business purpose. For more information on how to effectively implement PowerShell see the Securing PowerShell in the Enterprise publication 29. Click here to know how to implement this rule
Registry Editing Tools: One method for malicious code to maintain persistence (i.e. remain after a workstation is rebooted) is to use administrative privileges to modify the registry (as standard privileges only allow viewing of the registry). To reduce this risk, users should not have the ability to modify the registry using registry editing tools (i.e. regedit) or to make silent changes to the registry (i.e. using .reg files). Click here to know how to implement this rule
Remote Assistance: While Remote Assistance can be a useful business tool to allow system administrators to remotely administer workstations, it can also pose a risk. When a user has a problem with their workstation they can generate a Remote Assistance invitation. This invitation authorises anyone that has access to it to remotely control the workstation that issued the invitation. Invitations can be sent by email, instant messaging or saved to a file. If an adversary manages to intercept an invitation they will be able to use it to access the user’s workstation. Additionally, if network traffic on port 3389 is not blocked from reaching the internet, users may send Remote Assistance invitations over the internet which could allow for remote access to their workstation by an adversary. While Remote Assistance only grants access to the privileges of the user that generated the request, an adversary could install a key logging application on the workstation in preparation of a system administer using their privileged credentials to fix any problems. To reduce this risk, Remote Assistance should be disabled. Click here to know how to implement this rule
Remote Desktop Services: An adversary who gains access to a workstation can use the Command Prompt to execute in-built Microsoft Windows tools to gather information about the workstation or domain as well as schedule malicious code to execute on other workstations on the network. To reduce this risk, users should not have Command Prompt access or the ability to execute batch files and scripts. Should a legitimate business requirement exist to allow users to execute batch files (e.g. cmd and bat files); run logon, logoff, startup or shutdown batch file scripts; or use Remote Desktop Services, this risk will need to be accepted. Click here to know how to implement this rule
Voice Recorder: Sound Recorder is a feature of Microsoft Windows that allows audio from a device with a microphone to be recorded and saved as an audio file on the local hard drive. An adversary with remote access to a workstation can use this functionality to record sensitive conversations in the vicinity of the workstation. To reduce this risk, Sound Recorder should be disabled. Click here to know how to implement this rule
Remote Procedure Call: Remote Procedure Call (RPC) is a technique used for facilitating client and server application communications using a common interface. RPC is designed to make client and server interaction easier and safer by using a common library to handle tasks such as security, synchronisation and data flows. If unauthenticated communications are allowed between client and server applications, it could result in accidental disclosure of sensitive information or the failure to take advantage of RPC security functionality. To reduce this risk, all RPC clients should authenticate to RPC servers. Click here to know how to implement this rule
Reporting System Information: Microsoft Windows contains several in-built functions to, often automatically and transparently, report system information to Microsoft. This includes system errors and crash information as well as inventories of applications, files, devices, and drivers on the system. If captured by an adversary, this information could expose potentially sensitive information on workstations. This information could also subsequently be used by an adversary to tailor malicious code to target specific workstations or users. To reduce this risk, all in-built functions that report potentially sensitive system information should be directed to a corporate Windows Error Reporting server. Click here to know how to implement this rule
Safe Mode: An adversary with standard user credentials that can boot into Microsoft Windows using Safe Mode, Safe Mode with Networking or Safe Mode with Command Prompt options may be able to bypass system protections and security functionality. To reduce this risk, users with standard credentials should be prevented from using Safe Mode options to log in. Click here to know how to implement this rule
Secure Channel Communications: Periodically, workstations connected to a domain will communicate with the domain controllers. If an adversary has access to unprotected network communications they may be able to capture or modify sensitive information communicated between workstations and the domain controllers. To reduce this risk, all secure channel communications should be signed and encrypted with strong session keys. Click here to know how to implement this rule
Server Message Block Sessions: An adversary that has access to network communications may attempt to use session hijacking tools to interrupt, terminate or steal a Server Message Block (SMB) session. This could potentially allow an adversary to modify packets and forward them to a SMB server to perform undesirable actions or to pose as the server or client after a legitimate authentication has taken place to gain access to sensitive information. To reduce this risk, all communications between SMB clients and servers should be signed, with any passwords used appropriately encrypted. Click here to know how to implement this rule
System Cryptography: By default, when cryptographic keys are stored in Microsoft Windows, users can access them without first entering a password to unlock the certificate store. An adversary that compromises a workstation, or gains physical access to an unlocked workstation, can use these user keys to access sensitive information or resources that are cryptographically protected. To reduce this risk, strong encryption algorithms and strong key protection should be used on workstations. Click here to know how to implement this rule
Session Locking: An adversary with physical access to an unattended workstation with an unlocked session may attempt to inappropriately access sensitive information or conduct actions that won’t be attributed to them. To reduce this risk, a session lock should be configured to activate after a maximum of 15 minutes of user inactivity. Click here to know how to implement this rule
Resultant Set of Policy Reporting: By default, all users have the ability to generate Resultant Set of Policy (RSOP) reports which allows them to view the Group Policy settings being applied to their workstation and user account. This information could be used by an adversary to determine misconfigurations or weaknesses in Group Policy settings being applied to the workstation or the user account. To reduce this risk, users should not have the ability to generate RSOP reports. Click here to know how to implement this rule
Windows Remote Management: Windows Remote Management (WinRM) 31 is the Microsoft implementation of the WS-Management Protocol 32 which was developed as a public standard for remotely exchanging management data between devices that implement the protocol. If appropriate authentication and encryption is not implemented for this protocol, traffic may be subject to inception by an adversary. To reduce this risk, Windows Remote Management should be securely configured. Click here to know how to implement this rule
Windows Remote Shell Access: When Windows Remote Shell is enabled it can allow an adversary to remotely execute scripts and commands on workstations. To reduce this risk, Windows Remote Shell should be disabled. Click here to know how to implement this rule
Windows Search and Cortana: As part of the in-built search functionality of Microsoft Windows, users can search for web results in addition to local workstation results. This functionality if used could result in the accidental disclosure of sensitive information if sensitive terms are searched for automatically on the web in addition to the local workstation. To reduce this risk, the ability to automatically search the web should be disabled. Click here to know how to implement this rule
Windows to Go: A feature of Microsoft Windows 10 version 1709 is Windows To Go. Windows To Go allows users to boot into a workspace stored on USB media from any machine that supports the minimum hardware requirements. While this may be highly beneficial for Bring Your Own Device (BYOD) or remote access initiatives, it can also pose a risk to an organisation’s network. Workstations that allow automatic booting of Windows To Go workspaces do not discriminate between approved workspaces and malicious workspaces developed by an adversary. As such, an adversary may use a malicious workspace they have customised with their desired toolkit to attempt to gain access to sensitive information on the network. To reduce this risk, automatic booting of Windows To Go media should be disabled. Click here to know how to implement this rule
Displaying File Extensions: When extensions for known file types are hidden, an adversary can more easily use social engineering techniques to convince users to execute malicious email attachments. For example, a file named vulnerability_assessment.pdf.exe could appear as vulnerability_assessment.pdf to a user. To reduce this risk, hiding extensions for known file types should be disabled. Showing extensions for all known file types, in combination with user education and awareness of dangerous email attachment file types, can help reduce the risk of users executing malicious email attachments. Click here to know how to implement this rule
File and Folder Security Properties: By default, all users have the ability to view security properties of files and folders. This includes the security properties associated with files and folders as well as users and groups that they relate to. An adversary could use this information to target specific accounts that have access to sensitive information. To reduce this risk, users should not have the ability to view security properties of files and folders. Click here to know how to implement this rule
Location Awareness: When users interact with the internet their workstations often automatically provide geo-location details to websites or online services to assist them in tailoring content specific to the user’s geographical region (i.e. the city they are accessing the internet from). This information can be captured by an adversary to determine the location of a specific user. To reduce this risk, location services in the operating system and applications should be disabled. Click here to know how to implement this rule
Microsoft Store: Whilst applications in the Microsoft Store are vetted by Microsoft, there is still a risk that users given access to the Microsoft Store could download and install potentially malicious applications or applications that cause conflicts with other endorsed applications on their workstation. To reduce this risk, access to the Microsoft Store should be disabled. Click here to know how to implement this rule
Publishing Information to the Web: Microsoft Windows has the ability to assist users in either directly publishing information to the Web or sending information to publishers for professional publication. If not disabled, this functionality could result in the accidental or intentional release of sensitive information into the public domain. To reduce this risk, the ability to publish information to the Web or send to publishers should be disabled. The following Group Policy setting can be implemented to disable the ability to publish information to the Web or send it to publishers. Click here to know how to implement this rule
Audit Event Management: Failure to capture and analyse security related audit events from workstations can result in intrusions going unnoticed. In addition, the lack of such information can significantly hamper investigations following a security incident. To reduce this risk, security related audit events from workstations should be captured and routinely analysed. Click here to know how to implement this rule
Attachment Manager: The Attachment Manager within Microsoft Windows works in conjunction with applications such as the Microsoft Office suite and Internet Explorer to help protect workstations from attachments that have been received via email or downloaded from the internet. The Attachment Manager classifies files as high, medium or low risk based on the zone they originated from and the type of file. Based on the risk to the workstation, the Attachment Manager will either issue a warning to a user or prevent them from opening a file. If zone information is not preserved, or can be removed, it can allow an adversary to socially engineer a user to bypass protections afforded by the Attachment Manager. To reduce this risk, the Attachment Manager should be configured to preserve and protect zone information for files. Click here to know how to implement this rule
Autoplay and AutoRun: When enabled, Autoplay will automatically begin reading from a drive or media source as soon as it is used with a workstation, while AutoRun commands, generally in an autorun.inf file on the media, can be used to automatically execute any file on the media without user interaction. This functionality can be exploited by an adversary to automatically execute malicious code. To reduce this risk, Autoplay and AutoRun functionality should be disabled. Click here to know how to implement this rule
Bridging Networks: When workstations have multiple network interfaces, such as an Ethernet interface and a wireless interface, it is possible to establish a bridge between the connected networks. For example, when using an Ethernet interface to connect to an organisation’s wired network and a wireless interface to connect to another non-organisation controlled network such as a public wireless hotspot. When bridges are created between such networks an adversary can directly access the wired network from the wireless network to extract sensitive information. To reduce this risk, the ability to install and configure network bridges between different networks should be disabled. This won’t prevent an adversary from compromising a workstation via the wireless network and then using malicious software as a medium to indirectly access the wired network. This can only be prevented by manually disabling all wireless interfaces when connecting to wired networks. Click here to know how to implement this rule
Built-in Guest Accounts: When built-in guest accounts are used, it can allow an adversary to log onto a workstation over the network without first needing to compromise legitimate user credentials. To reduce this risk, built-in guest accounts should be disabled. Click here to know how to implement this rule
CD Burner Access: If CD burning functionality is enabled, and CD burners are installed in workstations, an adversary may attempt to steal sensitive information by burning it to CD. To reduce this risk, users should not have access to CD burning functionality except when explicitly required. Click here to know how to implement this rule
Command Prompt: An adversary who gains access to a workstation can use the Command Prompt to execute in-built Microsoft Windows tools to gather information about the workstation or domain as well as schedule malicious code to execute on other workstations on the network. To reduce this risk, users should not have Command Prompt access or the ability to execute batch files and scripts. Should a legitimate business requirement exist to allow users to execute batch files (e.g. cmd and bat files); run logon, logoff, startup or shutdown batch file scripts; or use Remote Desktop Services, this risk will need to be accepted. Click here to know how to implement this rule
Direct Memory Access: Communications interfaces that use Direct Memory Access (DMA) can allow an adversary with physical access to a workstation to directly access the contents of a workstation’s memory. This can be used to read sensitive contents such as cryptographic keys or to write malicious code directly into memory. To reduce this risk, communications interfaces that allow DMA (e.g. FireWire and Thunderbolt) should be disabled. This can be achieved either physically (e.g. using epoxy) or by using software controls  (e.g. disabling the functionality in the BIOS or UEFI; removing the SBP-2 driver and disabling the Thunderbolt controller; or using an end point protection solution). Click here to know how to implement this rule
Hard Drive Encryption: An adversary with physical access to a workstation may be able to use a bootable CD/DVD or USB media to load their own operating environment. From this environment, they can access the local file system to gain access to sensitive information or the SAM database to access password hashes. In addition, an adversary that gains access to a stolen or unsanitised hard drive will be to recover its contents when connected to another machine on which they have administrative access and can take ownership of files. To reduce this risk, 256-bit AES full disk encryption should be used to protect the contents of hard drives from unauthorised access. Click here to know how to implement this rule
File and Print Sharing: Users sharing files from their workstations can result in a lack of appropriate access controls being applied to sensitive information and the potential for the propagation of malicious code should file shares have read/write access. To reduce this risk, local file and print sharing should be disabled. Ideally, sensitive information should be centrally managed (e.g. on a network share with appropriate access controls). Disabling file and print sharing will not affect a user’s ability to access shared drives and printers on a network. Click here to know how to implement this rule
Endpoint Device Control: An adversary with physical access to a workstation may attempt to connect unauthorised USB media or other devices with mass storage functionality (e.g. smartphones, digital music players or cameras) to facilitate malicious code infections or the unauthorised copying of sensitive information. To reduce this risk, endpoint device control functionality should be appropriately implemented to control the use of all removable storage devices. Click here to know how to implement this rule
Group Policy Processing: Relying on users to set Group Policy settings for their workstations creates the potential for users to inadvertently misconfigure or disable security functionality without consideration of the impact on the security posture of the workstation. Alternatively, an adversary could exploit this to disable any Local Group Policy settings that are hampering their efforts to extract sensitive information. To reduce this risk, all audit, user rights and security related Group Policy settings should be specified for workstations at an organisational unit or domain level. To ensure these policies aren’t weakened, support for Local Group Policy settings should also be disabled. Click here to know how to implement this rule
Installing Applications: While the ability to install applications may be a business requirement for users, this privilege can be exploited by an adversary. An adversary can email a malicious application, or host a malicious application on a compromised website, and use social engineering techniques to convince users into installing the application on their workstation. Even if privileged access is required to install applications, users will use their privileged access if they believe, or can be convinced that, the requirement to install the application is legitimate. Additionally, if applications are configured to install using elevated privileges, an adversary can exploit this by creating a Windows Installer installation package to create a new account that belongs to the local built-in administrators group or to install a malicious application. To reduce this risk, all application installations should be strictly controlled. Click here to know how to implement this rule
Internet Printing: Microsoft Windows can print to internet printers over HTTP. If not disabled, this functionality could result in the accidental or intentional release of sensitive information into the public domain. To reduce this risk, internet printing should be disabled. Click here to know how to implement this rule
Legacy and Run Once Lists: Once malicious code has been copied to a workstation, an adversary with registry access can remotely schedule it to execute (i.e. using the run once list) or to automatically execute each time Microsoft Windows starts (i.e. using the legacy run list). To reduce this risk, legacy and run once lists should be disabled. This may interfere with the operation of legitimate applications that need to automatically execute each time Microsoft Windows starts. Click here to know how to implement this rule
Microsoft Accounts: A feature of Microsoft Windows 10 version 1709 is the ability to link Microsoft accounts (formerly Windows Live IDs) to local or domain accounts. When this occurs, a user’s settings and files are stored in the cloud using OneDrive rather than locally or on a domain controller. While this may have the benefit of allowing users to access their settings and files from any workstation (e.g. corporate workstation, home PC, internet cafe) it can also pose a risk to an organisation as they lose control over where sensitive information may be accessed from. To reduce this risk, users should not link Microsoft accounts with local or domain accounts. Click here to know how to implement this rule
Network Authentication: Cached credentials are stored in the Security Accounts Manager (SAM) database and can allow a user to log onto a workstation they have previously logged onto even if the domain is not available. Whilst this functionality may be desirable from an availability of services perspective, this functionality can be abused by an adversary who can retrieve these cached credentials (potentially Domain Administrator credentials in a worst-case scenario). To reduce this risk, cached credentials should be limited to only one previous logon. Click here to know how to implement this rule
NoLMHash Policy: When Microsoft Windows hashes a password that is less than 15 characters, it stores both a LAN Manager hash (LM hash) and Windows NT hash (NT hash) in the local SAM database for local accounts, or in Activity Directory for domain accounts. The LM hash is significantly weaker than the NT hash and can easily be brute forced. To reduce this risk, the NoLMHash Policy should be implemented on all workstations and domain controllers. As the LM hash is designed for authentication of legacy Microsoft Windows operating systems, such as those prior to Microsoft Windows 2000, there shouldn’t be a business requirement for its use except in very rare circumstances. Click here to know how to implement this rule
Power Management: One method of reducing power usage by workstations is to enter a sleep, hibernation or hybrid sleep state after a pre-defined period of inactivity. When a workstation enters a sleep state it maintains the contents of memory while powering down the rest of the workstation; with hibernation or hybrid sleep, it writes the contents of memory to the hard drive in a hibernation file (hiberfil.sys) and powers down the rest of the workstation. When this occurs, sensitive information such as encryption keys could either be retained in memory or written to the hard drive in a hibernation file. An adversary with physical access to the workstation and either the memory or hard drive can recover the sensitive information using forensic techniques. To reduce this risk, sleep, hibernation and hybrid sleep states should be disabled. Click here to know how to implement this rule
The CEASR application is bundled with the CE XDR and can be downloaded from the Risk Auditing application under the Windows Audit section.
Follow these steps to download and install the CEASR application in the end-point device connected to the CE XDR:
Step 1: Go to Compliance Controls > Risk Auditing
Step 2: You will be directed to the Risk Auditing app page. Click the Windows CEASR tab on the top panel.
Step 3: Click the Download CEASR App for Windows button and then unzip the folder.
Step 4: You will now see the Windows Installer Package named ‘Red Piranha CEASR – vXXXX’. Click it and a Windows Protected your PC pop-up will appear.
Step 5: Click the More info link in the Pop-up.
Step 6: Click the Run anyway button.
Step 7: Run the Red Piranha CEASR app setup wizard and allow the app to make changes to your device.
Step 8: Browse the desktop page and you will find the CEASR app icon.
You have successfully installed the Red Piranha CEASR app!
CEASR application helps to configure the overall security settings of the Windows 10 (Enterprise) OS installed in a device which is connected to the Crystal Eye XDR. The CE XDR can display the windows hardening status report of all the devices in a centralised dashboard in the Risk Auditing application. As a default feature the CEASR application forces the user to sync the end-point app with the CE XDR appliance. This can be successfully done by entering the Communication Key and hostname of the CE XDR in the CEASR app.
Note: To take full advantage of reporting from the CEASR application, devices on the network must be mapped in the Network Map app. Click here to know how to map devices in a CE XDR network.
How to Sync CEASR application with the CE XDR?
Step 1: Double click the CEASR app icon (in the desktop page) and you will see a Windows User Account Control pop-up (see screenshot below). Click the Yes button to allow the CEASR application run on your device.
Note: Once you click the Yes button on the Windows User Account Control pop-up, you will see the CEASR app initialisation pop-up (See screenshot below).
Important: Windows 10 Enterprise is required to access all features including policy creation. Other versions will have a reduced feature set and may result in the following message when trying to create WDAC policies. (See screenshot below).
Step 2: You will now see the CEASR app user interface. Click the Export Data to CE button.
Step 3: Enter the following and then click the Sync/Export button.
Note: The default hostname of the CE XDR is crystaleye.lan. CE XDR’s communication key can be retrieved from the Risk Audit app under the Windows CEASR tab. The synchronization interval is 5 mins as a default feature.
Step 4: You will now see the CE synchronized message.
The CE XDR’s Windows CEASR app can be used for system hardening allowing CE XDR administrators to minimize the attack surface of a computer system running on windows 10 (Enterprise). The actual goal of performing windows OS hardening is to ensure that the vulnerabilities and security weaknesses are reduced making it difficult for threat actors to exploit them.
Important: Click here to know the various windows OS hardening rules categories that can be enabled from the CEASR app user interface.
How to harden Windows OS using the CEASR application?
Note: Below is a demonstration of how to enforce Windows OS hardening rules related to Attack Surface Reduction rule category. You may enforce other rules associated with other Windows OS hardening rule categories similarly.
Step 1: Click System Hardening Config tab in the CEASR app UI. You will then see the list of windows hardening rules categories on the left-hand side of the app UI.
Step 2: Click the rule and then click the Enable button. In the screenshot below, we have enabled a rule that blocks email executable.
Step 3: You will now see the ‘Rules Applied message’.
The application control feature ensures that all the apps installed in the end-point device is listed in the app UI and are allowed by default. The apps which are not required can then be blocked from the CEASR application UI under the Application allow-listing tab. If need be, the Applications can also be uninstalled from the device.
Note: It is recommended to test the application block rules using the audit logs feature to ensure that the app block rules work as desired before enforcing it. This can be done by selecting the app (that needs to be blocked), enabling audit logs, disabling whitelist application and then clicking the activate allow-listing button. This would essentially instruct the CEASR application to log information about applications that would have been blocked if the policy is enforced. This procedure is usually followed to identify the potential impact of the block rules.
How to block an application using the CEASR application?
Step 1: Click Application Allow-Listing tab. You will then see all the applications installed in the end-point device.
Step 2: Click the application that needs to be blocked and ensure that the Whitelist Application tick box and the Audit Mode tick box is unchecked.
Step 3: Click the Activate Allow-Listing button.
Note: You will now see the progress bar of the blocking policy for Microsoft edge.
Step 4: You will now see the ‘Restart your computer pop-up notification.
The CE XDR appliance collects the logs from the CEASR application and displays windows hardening audit reports (in the risk auditing app). These audit reports shed’s light on the status of the windows hardening rules (whether its enabled or disabled) in all the devices connected to it. Each endpoint device is identified in the report by its MAC address, Device Name, IP address, Device Type and the network interface its connected to. The audit report is end-point device specific and can be viewed by clicking the View Audit Report button (see screenshot below).
The CEASR app works in tune with the CE XDR which ensures that the windows hardening rules created in the end-point device is displayed in a centralised dashboard. All devices which are connected with the CE XDR and have the CEASR app running in it would have its windows hardening rules status displayed in the risk audit app. These windows hardening rules of each end point can be viewed as an audit report (see screenshot below).
The audit time below shows the last time the intune CE XDR received the details regarding the updated windows hardening rules enforced in the end-point device (see screenshot below). Other details which would help in identifying the ends-point device is the Hostname and the MAC address.
The status of the rules can be known by reviewing each rule category. If the rule is enabled, it would show ‘True’ in the CE XDR user interface and a disabled rule would show ‘False’ in the interface (see screenshot below)