Once upon a time around 1995, the well-known American agency, the National Security Agency (NSA), decided that there was no computer operating system that was adequately secure for their needs. In analyzing the risks, they found that while UNIX was the most secure, they needed additional protection. They looked at the industry of anti-virus protection, at problems with Trojan software, at the problem of keeping up with virus authors, and at the requirement for government level security to prevent a corrupted module from secretly penetrating their operating or business system environment. Their conclusion was that “anti-virus blacklisting” is ineffective and isn’t worth a pinch of dung.
Eight years ago, in 2000, the NSA produced a kernel extension called Selinux for UNIX and also for Linux. What this extension did was to manage a catalog of permissions for files and processes. The way it generally works is as follows:
An operating system-owned rule database consisting of a set of permissions (i.e., a “whitelist”) is generated, and every executable (be it operating system or user program) is assigned permissions according to its functionality. A module not in the permissions database is not allowed to execute. Modules with matching rules in the database are limited to permissions determined by the rules. The restrictions may include other then execution privileges such as not being allowed to do things that the module was not designed to do. For example, a video driver is not allowed to write to a file. A second example is that of a “user program” rule which allows the module to write to a subset of of all public data directories. Digital signatures are used to certify each module and to ensure that a replacement module is blocked from execution until a new certification rules/signature for it is registered.
Selinux has been a great success, and as a result, it is used in many Unix versions and in Red Hat Linux since 2000 and in SUSE Linux since 2005. Whitelisting is proven.
More recently (2008), this capability is still not present in Microsoft operating systems. As a result, third-party vendors are looking at the Linux successes and asking “Why not?” Several competing vendors have recognized that if Linux systems can do it, then so can they do it for the Microsoft platforms. Several companies have brought their whitelist product to market. Each has developed its own whitelisting facility, sold to compliment the traditional anti-virus software for Microsoft platforms. Whitelisting for other platforms works in a similar manner to Selinux. Rather then block bad applications that it recognizes by signature, it allows execution of those applications and processes that match the security rules and internal certificates. Again, for example, a video driver is only allowed to be a video driver, and nothing else. In the same vein, a program may be allowed to write to a file, but not to use video, or be allowed to trap keystrokes. In effect, like Selinux, whitelisting builds good fences around all modules, and makes for a very secure system.
Where whitelisting comes into play big time is in the protection of database systems. All database systems are in need of protection from module replacement or from modules that misbehave. Whitelisting builds and manages the permission “fences.”
A reasonably good article about whitelisting, for Microsoft Platforms, written by Jason Brooks “Toward A More Idiotproof Internet”, was published in eWeek on October 1st, 2008. Selinux information is available from the National Security Agency (NSA).
Eight years ago, in 2000, the NSA produced a kernel extension called Selinux for UNIX and also for Linux. What this extension did was to manage a catalog of permissions for files and processes. The way it generally works is as follows:
An operating system-owned rule database consisting of a set of permissions (i.e., a “whitelist”) is generated, and every executable (be it operating system or user program) is assigned permissions according to its functionality. A module not in the permissions database is not allowed to execute. Modules with matching rules in the database are limited to permissions determined by the rules. The restrictions may include other then execution privileges such as not being allowed to do things that the module was not designed to do. For example, a video driver is not allowed to write to a file. A second example is that of a “user program” rule which allows the module to write to a subset of of all public data directories. Digital signatures are used to certify each module and to ensure that a replacement module is blocked from execution until a new certification rules/signature for it is registered.
Selinux has been a great success, and as a result, it is used in many Unix versions and in Red Hat Linux since 2000 and in SUSE Linux since 2005. Whitelisting is proven.
More recently (2008), this capability is still not present in Microsoft operating systems. As a result, third-party vendors are looking at the Linux successes and asking “Why not?” Several competing vendors have recognized that if Linux systems can do it, then so can they do it for the Microsoft platforms. Several companies have brought their whitelist product to market. Each has developed its own whitelisting facility, sold to compliment the traditional anti-virus software for Microsoft platforms. Whitelisting for other platforms works in a similar manner to Selinux. Rather then block bad applications that it recognizes by signature, it allows execution of those applications and processes that match the security rules and internal certificates. Again, for example, a video driver is only allowed to be a video driver, and nothing else. In the same vein, a program may be allowed to write to a file, but not to use video, or be allowed to trap keystrokes. In effect, like Selinux, whitelisting builds good fences around all modules, and makes for a very secure system.
Where whitelisting comes into play big time is in the protection of database systems. All database systems are in need of protection from module replacement or from modules that misbehave. Whitelisting builds and manages the permission “fences.”
A reasonably good article about whitelisting, for Microsoft Platforms, written by Jason Brooks “Toward A More Idiotproof Internet”, was published in eWeek on October 1st, 2008. Selinux information is available from the National Security Agency (NSA).
No comments:
Post a Comment