One of the challenges for a security professional
is assigning the right roles of people
to the correct resources.
We have so many different resources on our networks.
There are printers that people have certain permissions
and access to.
And certainly, files and folders that are on servers
have many different permissions and rights
depending on who needs access to those particular pieces.
We usually assign access to these resources
based on someone's role.
This is much easier than taking each individual person
and assigning individual rights and permissions
to all of those different resources.
Instead, it's so much easier to say
if you are in the marketing department then
you have this kind of access to this particular printer,
or this particular share on the network.
This makes it much easier, so that when somebody's
removed from the marketing department
then they would automatically lose access
to those particular resources.
We want to make these definitions
to be very specific to someone's role.
But we don't want to make it so specific
that it becomes cumbersome to manage.
So the marketing department might
have some global roles associated with it.
But you might need different roles
for the management of the marketing department
versus the rest of the marketing department.
And how you segment out and decide
what types of groups or types of roles you create
is going be based on the business
needs of those particular areas.
If you've then assigned different levels of access
to a resource-- one for the marketing department
and a different level of permissions for the marketing
managers-- then whatever system you're using,
or the resource itself, has to be
able to make a determination of what role to put you in.
Do we put you in the marketing manager's role?
Or do we put you in the more restrictive marketing role?
And the agreement over whether somebody
gets more permissions or less permissions
is generally based on the type of role system and permissions
that you are using in your environment.
A shared account is when more than one person
knows how to authenticate in as a particular username.
This is sometimes limitations based on the device
that you're using, maybe it only allows
for one particular username.
But generally, most of the systems that we are using
allow you to build separate account names
so that you don't have the situation where
you have shared accounts.
This is usually a best practice to avoid shared accounts,
although you'll find some organizations that
use the administrator account and is
sharing that across multiple users.
This is probably not the best idea.
But it's something that is allowed by the operating
system.
Just one of many reasons why this is a bad idea
can be based on the idea of auditing.
If something is changed or modified on a file server,
or on the network, it would be nice to know
who made that change and when they made that change.
But if multiple people are logging in as administrator,
for example, then all you know is that the administrator
user made a particular change.
And you have no idea exactly which user did this.
The concept of narrowing this down to a very specific person
is called non-repudiation.
We know that if we have a particular user's name
pop up then it really was that user.
But if everybody's sharing the same account
there's no way to have non-repudiation.
Shared accounts are also much more prone to be compromised.
When you have so many people that
know the username and password for an account
it's just that much more likely the that password
is going to get out.
And if we do need to change the password on the account
then we have to inform every person who
is sharing that account name that the password has changed.
And then we have to find a way to get
them that new password in a way that is secure.
The idea of shared accounts is something
that creates a lot of complexity on the security side.
And the best practice is to avoid it at all costs.
We want to be able to protect these login
credentials at all cost.
It is this username and password that
gains access inside of your network.
And we want to make sure that only the authorized people get
access to those particular resources.
One way to protect against somebody gaining access to this
is to protect both the username and the password.
At no time should you embed some of this information
within the application itself.
Sounds so easy, if you could just walk up to a machine
and it would automatically login for you.
But every time you're doing anything automatically
with credentials that means that that user
name and that password is being saved
in some way inside of your system.
If possible, we would like to store those only in your brain,
and not in any type of automated system.
We also want to be sure that if we're
sending that authentication information across the network
that it's also protected and encrypted.
Very early on in the world of computing
we were sending information across the network
in the clear.
But we found out very quickly that that is an easy way
to have your credentials stolen.
So if you are going to send a password over the network,
it's always best to send a hash, or some encrypted form of that,
to be sure that no one would be able to SNIP the network,
capture those packets, and then have access
to your login credentials.