Default denies all applications (part 1)

Software Restriction Policy (SRP) - a software policy restriction utility - was first introduced in October 2001 with the introduction of Microsoft Windows XP Professional. Since then, this utility has a quieter, quieter life than anything you can say. The purpose of this series is to bring SRP 'back to life' in the real world, to encourage the world of admin community to rethink software policies and even deploy SRP in devices. Its strongest setup: using Whitelisting model.

Why SRP?

Today's business users collaborate with e-mail, instant messaging, peer-to-peer applications instead of traditional meeting or phone calls that cost more than ever before. They use the Internet to search and share information. These forms are increasingly popular, the malicious code threats are also increasing. Users often bring data 'out of control' into memory, MP3 players, etc. continuously from home to office and from the office home. That data can be as simple as Word, Excel and more complex like games, hack tools and malware. Today in the west (and will be in Vietnam in the near future), laptops are more popular than desktops. They are connected to networks 'out of control' including wired networks as well as all types of wireless technologies, making them at high risk of being compromised by malicious code and attacks. .

From the above analysis, we can see there are many reasons why today it is necessary to implement SRP:

What businesses want most: To protect against dangers:

Protect your computer from being compromised.

Malware (malware);spyware (spyware);virus;trojan horse;Denial of service attacks (DoS);revealed private data or business data .

Prevent unwanted software from running on enterprise computers.

Other non-mainstream games and software reduce performance and consume network resources and computer resources.

Prevent unauthorized software from running on enterprise computers.

Running unauthorized software on the corporate network can lead to some legal problems.No organization wants to be touched by authorities.

Prohibited unsupported software running on enterprise computers.

Prevent application conflicts that can lead to system crashes, incompatibility with mainstream software, complex debugging issues .

Prohibit unidentified software from running on enterprise computers.

Things that you don't know that could (or will be) harmful to you.

Reduce the total cost of ownership (TCO).

It will take a lot of money to fix the consequences after the business computer is infected with the virus and may encounter another danger mentioned above.

Most administrators and administrators want to eliminate the dangers from computer viruses and other objects mentioned in Table 1. This can be done through SRP. In SRP, we will define how an executable file and any ActiveX control can run. If it's just advanced and digitally scripted scripts, they can run. We can make it mandatory that only advanced applications are allowed to run on enterprise computers using built-in technology. We can lock clients, sometimes even servers, so they can do it no more or less according to what you want. This gadget is completely free and located right in front of our eyes.

The Software Restriction Policy (SRP) executes at runtime. The user will receive a message block as shown in Figure 1 when trying to run unapproved code. Figure 2 shows the popup menu for prohibited scripts.

Figure 1

Figure 2

With SRP, you can even limit a local administrator from executing code other than your own. Many companies provide users with common administrative privileges by encountering various issues between privileges and applications. But with SRP running on top of the installation program, network administrators can feel almost absolutely safe.

You can say that your users cannot install unauthorized software because they are limited to privileges (not a local administrator), but in fact, all types of executable files can run and perform unwanted operation. For example, with a small utility ProduKey, it is useful if you forget the product code, such as Exchange, Office, SQL or Windows operating system itself when you want to install them. But from an administrator's perspective, this utility leaves a big problem: even limited users can read the product code on the local machine. That means that users can completely retrieve the license key (VLK) and install it on their home computer or wherever they like with the VLK copyright business has obtained.

Blacklisting and Whitelisting

The first port filtering form on the network router in the early 90s of the last century was configured to remove only a few specific ports, and to allow all the remaining components outside, on the Internet to be passed. Network administrators are always one step behind hackers, who often change their attack patterns to constantly gain access to new services. For example, as soon as the dangerous removal administrator is about to come to TELNET, RLOGIN or FTP has been attacked. It was an armed race that had no stops, leading to the introduction of the 'Default Deny' firewall principle. Nothing will be allowed by default unless you define some exceptions.

Try looking at antivirus applications and you'll see that they need to update the virus signature constantly to identify which code should not run on the network computer. So why don't we reverse the process, define what to run and leave everything else behind. Such a situation is the same as with all software applications that run on every computer in the world today. Why do I have to run all the components in one software by default while most of us know exactly which applications need to boot in the environment? Why not introduce the principle of 'refusing to default all applications' on the client computer and give an exception to the default rule of the application the user wants to run?

The method of ' Rejecting all applications by default ' is also called Whitelisting (WL). When the SRP configuration in WL mode, Default Security Level is set to ' Disallowed ' (not allowed). After that, some additional rules with exceptions are created. This means that no files are executed on the computer unless you describe it in a policy.

If you want to use WL, you need a complete book of software that is allowed to use. And if you want to use the HASH hash function for the identity method, you need access to the executable file. If you prefer to use the certificate rule, you need either a certificate file ( .CER or. CRT ), or just access the marked executable file.

Blacklisting (BL) is the Default Security Level after enabling SRP, also known as 'unlimited model'. People liken BL as a "sandbar", a work that never ends and has no security level like WL. With a wide variety of different types of malicious code, it is difficult to remove all of them only through 'code signs' or using file names. Why maintain a list of millions of malware types - an ever-growing list - instead of being able to manage a list of only 50 to 100 essential applications within an organization?

When looking at management capabilities, BL is much easier to implement. But it simply can't have a good level of security like WL. BL is suitable for loose computer management. If you want to lock the system tightly so that your computer is highly restricted and secure, WL is the best option to date.

Gpdisable 'conceptual verification' tool created by Mark Russinovich a few years ago is a good example of why WL defeats BL. With Gpdisable or a similar tool, even limited users can remove group policies that are running on a Windows client (with SRP), unless the SRP is implemented using Whitelisting.

Only 'Default deny all application' will pass the time verification. Unfortunately, we still need to use anti-virus software to protect our computer against malicious code and executable files. Don't forget that the 'SRP' only prevents unwanted software from running on the local machine. It can still carry executable files to a hard drive or as an attachment in an email without encountering any policy conflicts.

Future

Hopefully, Microsoft will continue to create a new application acceptance program more easily in the coming years. It would be great to be able to 'enter' a SRP or hash value (HASH) for an application. This will require third-party software vendors to distribute a 'sample' SRP to their applications so that network administrators can easily import them, rather than having to manually create policies. . These 'templates' will include the hash value of all executables and require a dynamic link library (DDL).

Unfortunately, there are still too few software companies that use code marking technology. Hopefully they will use digital certificates for this technology more often in the future.

I want to share an idea to make WL administration easier. With hash function rules (HASH), the administrator must open the GPO (Group Policy Object) and lead the file . If the program is scripted and scheduled, the network administrator will have to set the actual file. Exam into a central 'approved' directory (NTFS permissions must be set appropriately). When the script runs, it creates an automatic hash value and adds the value to an 'unlimited' policy in a specific GPO. With certificates it can do the same, just place the certificate in the central directory, wait for the script or process to appear and then the software is approved on the network. Yes, that's just a dream. Hopefully someone will turn it into reality someday, maybe Microsoft is not known yet.

Conclude

Software Restriction Policy (SRP) has appeared and been in operation for approximately 6 years. However, it is still an 'unpopular' thing now, although it really can provide a very high level of security for both the client and server. When applied correctly, Software Restriction Policy will significantly enhance the integrity of the machine in your organization with costs even lower than the total cost of copyright for a long time.

In the next part of this series, we will look at how SRP is designed, deployed, and configured.

Default denies all applications (Part 2)