Security administrators use a few different philosophies when configuring security policies on endpoints. In this video, you’ll learn about approval lists, block lists, quarantine areas, and the criteria used for application approval lists.
When we refer to the endpoint, we’re talking about the devices that we use day to day to do our jobs. This could be our desktop computer, the laptop that we carry around, or it might be a smartphone or tablet. And of course, there are different ways to exploit each of these devices. The endpoint is a critical piece of our security. So we have to protect against malware, operating system vulnerabilities, or users who are trying to circumvent existing security controls. The IT security team is responsible for monitoring all of these different devices. And they are constantly watching for alerts and alarms that can let them know when something unusual might be happening on the endpoint.
One security control might be to define what applications are allowed or not allowed on a particular endpoint. The concern might be that a user would download software from a third-party website. And that software might have some malicious software or malware. By providing control of the applications running on the endpoint, the IT security team can create a more secure and stable environment.
One philosophy on how to implement this type of control is through the use of an approved list. That means that the IT security team would create a list of applications that was approved. And no other applications would be able to run on that endpoint. This is obviously a very restrictive list. And you would have to go to the IT security team if there’s any software that you do need to have installed that may not currently be on the approved list.
Another way to implement this control is to have a blocklist or a deny list. This would be a list of applications that would specifically be prevented from running on this particular endpoint. This would mean that users were allowed to install applications unless that application is specifically listed in the deny list. In fact, it’s very common for anti-virus or anti-malware to have their own deny list. And if a user tries to launch that application, the anti-malware software will prevent that application from running.
If your endpoint security software does recognize an application that seems to have malicious software, then it can remove that from the system and place it into a quarantine area. This might be a folder that’s on the existing system where no applications are allowed to run. Later, the IT security team can look into the quarantine folder and perform additional analysis of that software.
The ability to run or not run an application in an operating system is commonly built into the core functionality of the OS. And the security team can enable or disable different parameters to allow certain software to run. For example, there may be a hash that is taken of an executable, and if that hash matches the executable on the system, it can either be allowed or denied access to execute. Since this is a hash, if the application changes, then the hash would change. So this may be something that the security team has to constantly update every time a new version of software is introduced.
Many applications include a digital signature. And that digital signature often is based around a particular manufacturer or developer. That developer’s name then can be allowed or disallowed to run on that system if the digital signature matches. For example, you could decide that anything that is digitally signed from Microsoft is trusted and therefore can be installed and run on that endpoint. Malicious software often installs itself into different places on a storage device. So you may be able to tell your operating system, only run software if it happens to be installed in this particular folder.
And if you limit the permissions to those folders, you can effectively create a trusted area of the storage drive. We can also set a policy that would allow or disallow an application to run based on the zone it is executing from. For example, our internal network is commonly designated as a private zone. And the internet side is usually the public zone. We could set a policy that says that any applications that are executing or running from private zone devices are allowed, and any that are coming from a public zone would be prohibited.