There are some best practices to use when managing the security of applications. In this video, you’ll learn how to harden application through the use of port filters, registry settings, disk encryption, patch management, and more.
As a security professional, there are a number of techniques that you can use to make sure that your applications are as secure as possible. In this video, we’re going to focus on application hardening, which means we’re going to minimize the number of attack surfaces and hopefully limit the ability of an attacker to be able to exploit an application. We’re not only trying to protect against well-known attack points, but hopefully during our process of hardening this application we’re able to protect it from unknown attack points as well.
Sometimes this attack hardening comes from a third party, or from an existing compliance. For example, there are specific regulations regarding HIPAA servers or PCI-DSS credit card protection. We can use the guidance from these compliance mandates to provide additional application hardening. If you’re not sure where to start in the process of application hardening, there are a number of resources available on the internet from the Center for Internet Security or CIS, the Network and Security Institute or SANS, or you may find some white papers at NIST or the National Institute of Standards and Technology.
If you’re a network professional, then you’re probably already familiar with the concept of limiting what ports may be accessible on a device. This is usually the case where we will close all available ports on that device, except the ones that can provide exactly the services needed by that application. This is commonly done with a firewall, where you can limit what IP addresses and port numbers are accessible, and in some cases you can use a next-generation firewall to also limit the applications that can flow over that particular IP address and port number.
It’s not unusual to find applications or services running on a device that have opened up port numbers that are accessible from the network. This is something that can commonly happen if you install software, or the default configuration for an operating system, and unless you go through all of the ports and test that particular device you may have no idea that those ports are open. And for those of us that have been tasked with configuring applications on a service, we have seen the application programmers provide us documentation that says the appropriate ports to be open on this device is port 0 through 65,535, which effectively opens every port on that device. We would obviously not want to provide every port to be available to the network, so instead it’s common to do our own testing. We may want to run an Nmap scan and verify what ports happen to be open currently, and perhaps limit access to only those particular ports.
For Windows administrators, they can perform a number of application hardening tasks inside of the Windows Registry. The Windows Registry is a large database that contains configuration settings for the Windows operating system and the applications that run on that operating system. One of the challenges we have is that when we install a new application, we have no idea exactly what may have been changed inside of the registry. It’s common to use third party tools that can show the registry settings before an application has been installed, and what settings have changed after the application has been installed. This is useful to know because some of these registry settings are very important from a security perspective. For example, the registry can allow someone to configure permissions and other applications to make changes to the registry, and in some extreme cases you can disable vulnerabilities in the registry, for example, a very well-known vulnerability took advantage of SMB version one, and now it’s very common to disable that particular protocol in the registry of every Windows computer.
Here’s a screenshot of the registry, there is a hierarchical structure for the registry and thousands and thousands of different settings inside of the registry. That’s why it’s important to always take a backup of the registry before you start making changes, because it can be very easy to accidentally remove information that might be critical for the operating system or for other applications. One way to prevent third party access to the data that we store on our computers is to use hard drives and storage devices that will encrypt the information that we’re storing. This is sometimes handled in the file system itself, through something called full disk encryption.
If you’re using Windows BitLocker you’re using an FDE, or Full Disk Encryption utility that is built into the Windows operating system. In some highly secure environments, you may use a type of encryption on a storage drive that’s built into the hardware of the drive itself. It’s not specific to any particular operating system, and anything that’s written to that drive is automatically stored in an encrypted form because it’s built into the hardware of the device. If you’re using a Self-Encrypting Drive, or SED, then there is a standard associated with these. It is the Opal Storage Specification, so if you are purchasing or implementing a self-encrypting drive, you want to be sure that drive follows the Opal standard.
Operating systems are complex environments and there are many different kinds of operating systems that we might need to provide some type of hardening. There is Windows, Linux, iOS, Android, and other operating systems and every single operating system is going to have a different set of techniques to be able to make that operating system more hardened. One common technique across all operating systems is to always keep the operating system up to date with the latest versions. These can be updates to the core operating system itself, they may be deployed using service packs, or they may be individual security patches that are installed one by one.
We also want to harden our user accounts. We want to be sure that all of our users have very good passwords and we have a password policy for every single user. We also want to be sure that the accounts that people are using to log in have limitations that are only going to allow them to perform the tasks necessary for their job. We also want to be sure these devices have limited access to other components across the network and we want to be sure that these devices have limited input from other devices across the network as well. And of course, even after performing all of these hardening tasks, there can still be attacks that occur in the operating system which is why we still run antivirus, anti-malware and other security software on these individual endpoints.
Patch management is so important in these operating systems that it is a standard part of the operating system, and it’s built into the scheduling and automated systems within the OS. You’ll find that security patches and fixes are automatically deployed to our systems to avoid any type of vulnerability or attack. Many operating systems will have monthly updates where the manufacturer of the operating system creates a batch of fixes and pushes all of those fixes out once a month. This keeps the update process manageable for the operating system administrators, and it keeps all the systems up to date and protected from any vulnerabilities.
Of course, there are other applications running on these operating systems that are created by third parties, and those applications also have to be kept up to date. The same thing applies for the device drivers that are installed in that operating system as well. It’s important that we update these systems as quickly as possible, but we don’t want to perform an update that’s going to cause a problem with the operating system or the applications that are running in that OS. That’s why many people will not use auto update on the systems that are in an enterprise, instead the IT department will first test all of the updates and then push those updates out once they know that they’re going to work properly in their environment.
But there will be times when an update is an emergency update that suddenly appears out of the normal flow of the update schedule and needs to be deployed as soon as possible. These are usually because of zero-day attacks that are being taken advantage of in the wild, and we need to make sure that all of our systems are patched as quickly as possible. Some operating systems and applications will include a sandbox functionality. This limits the scope of an application from accessing data that is not part of that application. This is something that’s commonly done during the development process so that the developers are not changing any of the data that might be in a production environment, but using sandboxing during production can be a valuable security tool as well. For example, if you’re using a virtual machine, that virtual machine is sandboxed from other virtual machines that might be running on that system, or from the host operating system itself.
You might also see sandboxing being used on mobile devices. For example, the browser on a mobile device is not going to have access to other types of data on that device, unless you as the user explicitly allow that browser to have access to that information. Otherwise, that data is sandboxed away from the browser. Browsers themselves have ways to separate and sandbox data from other parts of the browser. This is especially important with IFrames, or inline frames, where one IFrame may not know or have access to data that would exist in other IFrames on that browser. And in Windows, there is extensive sandboxing especially relating to User Account Control, or UAC, where applications would not have access to other types of data unless you grant them the access as part of that application.