Ransomware is one of the biggest threats faced by organizations today. After encrypting all files on servers and desktops, ransomware perpetrators demand payment before decrypting what are often business-critical systems and data.
Application whitelisting and the removal of local administrator access from day-to-day user accounts are two of the best ways to prevent the installation of ransomware applications. However, these approaches are not always technologically or politically possible. Windows 10 controlled folder access is another option for organizations.
Controlled folder access (CFA) prevents untrusted applications from making changes to essential folders. Deployed as part of Windows Defender, CFA can prevent malicious applications installed by users from encrypting files in folders identified by Microsoft and the organization.
How CFA works
According to Chris Hoffman, writing for How-To Geek, CFA is primarily intended to protect against ransomware. It prevents executable files, scripts and DLLs from making changes to files in the protected folders. Malware can still read and copy files in those folders.
CFA is not enabled by default. Instead, it is an opt-in feature that requires the implementation of Windows Defender Antivirus real-time protection.
Microsoft writes that all commonly trusted applications can still make changes to the protected folders. This includes Microsoft Office applications and other major vendor products. I was unable to find a definitive list of what is or is not allowed. As described later in this article, not knowing what works is a good reason to enable audit mode when first enabling CFA.
Like most Windows security configurations, how you approach implementing CFA depends on the size of your organization and how you manage CFA policy exceptions. We’ll take a look at three methods: Windows Defender Security Center configuration, use of PowerShell and configuration of group policy.
Regardless of the approach, organizations (Read more...)
*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Tom Olzak. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/N5dcSJCX5qg/