As you can see, application software can represent a pretty large attack surface.
This is especially true when it comes to
a large fleet of systems used throughout an organization.
So, it's important to have some kind of application policies in place.
These policies serve two purposes.
Not only do they defined boundaries of what applications are permitted or not,
but they also help educate folks on how to use software more securely.
We've seen the risks that software can pose because of security vulnerabilities.
It makes sense to have a policy around applying software updates in a timely way.
A common recommendation or even a requirement is to only support or
require the latest version of a piece of software. From the I.T.
support perspective, this is important because
software updates will often fix issues that someone may be encountering.
But from the security side of things,
making sure the latest version of the software will ensure that
all security patches have been applied and the most secure version is in use.
This should be clearly called out in a policy.
People tend to be pretty lazy about applying updates to software that they use a lot.
Lots of times, applying an update requires restarting the application,
which can feel inconvenient and disruptive to users.
It's generally a good idea to disallow risky classes of software by policy.
Things like file sharing software and
piracy-related software tend to be closely associated with malware infections.
They usually don't have a business use either.
Let's not even talk about the legal implications of this type of software.
Understanding what your users need to do their jobs
will help shape your approach to software policies and guidelines.
If there's a common use case for a certain type of software,
it would be helpful to select
a specific software implementation and require the use of that solution.
This lets to reevaluate the most secure solution
and benefit from a more uniform software installation.
Remember, the name of the game is to minimize attack surfaces.
Each piece of software that accomplishes the same thing represents
a different set of
potential attack surfaces that could have a vulnerability lurking inside.
Helping your users accomplish tasks by recommending or
supporting specific software makes for a more secure environment.
It also helps users by giving them clear solutions to accomplish tasks.
If you want to employ a binary white listing solution,
it's also important to define a policy around what type of software can be whitelisted.
So it's probably unnecessary to have video games whitelisted,
unless your company is a video game studio, of course.
These policies usually require some kind of business use case or
justification to avoid a lot of one off personal software requests.
Another class of software that you might want to have policies
defined for are browser extensions or add ons.
Since a lot of workflows live exclusively within the web browser now,
they represent a potential vector for malware that often gets overlooked.
Extensions that require full access to web sites visited can be
risky since the extension developer has the power to modify pages visited.
Some extensions may even send user input to a remote server.
This could potentially leak confidential information.
Clearly defining classifications of risky extensions and add
ons will help protect your systems and provide guidance to your users.
But, policies are usually not enough to arm users
with the information they need to make informed choices.
Their decisions can impact the security of your organization.
That's where education and training comes into play which,
we'll discuss in the next module.
We went over a lot of really dense information on security in these lessons.
Take time to review some of the videos so that it really sinks in.
Okay, awesome work.
Now, it's time for a project that will test what you learned about the system hardening,
then if you can believe it,
you'll move on to the last lesson of the last course of this program. Woohoo.
Google
