Even if you find a solution to the first problem even if you have made sure that all programs that are
used in your enterprise are updated this does not automatically mean that you're secure.
As you've seen and one of the earlier modules even if a program itself is trustworthy you can't know
for sure whether at some point a malicious code was inserted to it or not either prior to or at Download
This strongly suggests that you shouldn't allow users to run any programs they want.
We can now observe a slow departure from a model of universally used computers.
This applies also to business machines that are expected to run anything in favor of a shift towards
thinking of computers as a tool to perform specified tasks and functions only.
How can you ensure this.
You should make it impossible for users to run programs that you know to be harmful but since no one
knows of all dangerous programs this has to be done in a different way.
How uses Should that be able to run any programs.
This would make a computer relatively secure.
But if it's also to be functional as well.
You'll need to create an exception list a whitelist programs that are listed on the waitlists can be
assumed to be secure.
You installed them yourself on playing computers.
They should be able to run on them.
Let's not think of how this can be achieved.
If you're using earlier editions of Windows Windows XP and Vista or equivalent software restrictions
policies might be a useful technology.
If you're using newer editions of Windows software restriction policies have evolved to a newer version
called application control policies software restriction policies were problematic in use setting them
up was relatively hard.
It wasn't a hugely difficult task to understand them but creating an exception list would take a lot
of time generalizing some rules was not possible.
Programs were identified based on their certificates their file hash functions paths or internet zones.
The less dubious idea was that if Internet Explorer was used to download a program information about
the source of the file local Internet Internet trusted sites would be written to the program file.
You could make decisions and identify a given code based on this.
The policies don't have a rule that would for example allow running the Office suite both in its 2007
and 2010 version.
We'd like to be able to create several rules or create path rules using wildcards this type of rule
specifies that you can run anything that is inside a folder or anything that is held in a given registry
key.
They're relatively dangerous to allow a program to be run.
You would only need to place it in an appropriate site.
We however want these software restriction policies to work in addition to control and authorization
mechanisms that were discussed earlier that can't be based on this mechanism.
There's no point in trying to create a list of native exceptions or in other words specifying programs
that shouldn't be run this wouldn't do much to secure your systems.
You have to change fixed thought patterns and determine that nothing is allowed except the code and
programs that are sure to be secure.
Let's now examine mechanisms used to implement this.
The first thing that is implemented in a real system that you will see there is a default security level
this is your starting point.
If you don't change any settings a default rule is that anything is allowed to be run.
You can run anything you want on each of your computers.
Then as we mentioned you have rules that identify a software.
You can then explicitly determine the identity of a program if a program is signed digitally.
It can be a certificate a file hash rule a hash function or hashing result an Internet zone or a path.
There are also extra settings that enable you to specify if this entire mechanism will also be applied
to dynamically libraries or executable files only.
Or if it should be applied to administrators or exempt them there is little point in exempting administrators
when you'll be configuring and enabling this.
I have one valuable piece of advice if something goes wrong and you block the ability to launch important
operating system elements you'll have problems for example logging onto the computer after restart the
Safe Mode is really useful in that case.
The mechanisms don't work in safe mode.
They're not run.
You can then log on reconfigure your settings and see if they work.
The order in which the rules are applied is known and well-documented start with the most detailed and
then with the most general one this allows you to create exceptions you can for example allow running
programs that are contained in a given folder except a file of a specified signature.
At the end a default security level rule is checked.
Let's say a few words about internal operating mechanisms after enabling software restriction policies
the following sort of methods for an application are controlled.
This protection applies to a Windows API function known as create process this mechanism is used to
run new programs software restriction policies are usually applied to this function.
Other elements that are controlled include NTD cello libraries the kernel loader in this case there's
a possibility to block the running of a part of an operating system.
This can produce adverse byproducts that we mentioned before
a command line interface environment is also controlled.
This is the S.M. de-program
control is also applied to all scripts orthis shell scripts in power shell scripts
an operating system will check the data contained in a registry key you can see
it contains information on policies set on a given computer before a code is run is checked if one of
the rules applies to the program.
If there's a match in action for a given rule will be used if there there's no match or default action
for all rules will be used.