Setting a user's account to have the least number of privileges
is a foundation in IT security.
If you're configuring a user's account,
they should have the ability to perform their job
and have no other rights and permissions beyond that.
This applies to all users in the organization.
You should configure all of the accounts
to only run exactly what is required
for the applications needed.
You never want to have users running
with administrative privileges.
An Administrator has access to all systems at all levels.
If you're running with a least privilege,
then that user would have a limited scope,
especially if there's malicious software which
tries to affect other parts of the organization.
Account management becomes very important
when you are on-boarding new users.
These could be new hires or transfers
from other parts of the organization.
There are usually internal IT agreements
that need to be signed.
These could be part of your employee handbook.
Or they could be a formal acceptable use policy
that everyone has to read and agree to.
The IT Department will then create the accounts,
and they will confirm that the user is provided with exactly
the right permissions and access by adding them
to the proper groups.
And the new user may be assigned a workstation, a laptop,
a tablet, and any other hardware that may be
required to perform their job.
While some people are joining the organization,
other people may be leaving the organization.
But this is not a process that should be a surprise.
You should have pre-planned for this occasion
and know exactly the steps you should
follow during the off-boarding process.
For example, there should be a formal process
to turn in hardware and confirm that the hardware has
been received.
And the user's data is also extremely important,
especially for the people that will still be here working
or the people that will be replacing this person.
In many organizations, the account information
is usually deactivated instead of being deleted.
Occasionally, there can be information lost
during the deletion process.
So by simply deactivating the account,
you can be assured that all of the data remains in place.
You've spent a lot of time creating formal policies
and making sure that people agree
to use those formal policies when
they're part of the network.
One way to be assured that they're
following those policies is to perform routine audits.
Although you may have already set up all
of these accounts and all of these permissions initially,
it's remarkable how things can change over time.
So by performing audits, you can be
assured that everything is exactly
the way it was designed to run from the very beginning.
Many types of these scheduled audits can even be automated.
So the process can be done without any type
of user intervention.
And you can simply receive a list
of alerts or a list of logs that shows you issues
that may need to be resolved.
One type of auditing is a permission auditing.
You want to be sure that every user has
exactly the correct permissions they
need for their particular role.
For example, there may be people that
have been provided Administrator access that really do not
need to have Administrator access on your network.
And usually this is a process where you can schedule
a recertification of this.
This is where you will be continually auditing
the users' permissions to make sure
that they're only able to access the information they need.
You might also perform usage auditing
to find out exactly how your resources are being used.
How are people storing information?
And where are they storing those files?
Are the systems and applications that are
in use configured to be secure?
You might also want to perform audits
to check on what's happening during the day.
Implementing time-of-day restrictions
can be a good way to provide security.
For example, no one needs to be in a particular location
in a lab at 3:00 in the morning performing
any type of functions.
And if someone is in the lab at 3:00 in the morning,
that may be something that you need to be aware of.
Every user is generally assigned a standard username.
This should be a unique name, something
that doesn't conflict with anyone
else in the organization.
And this person should use the same username
across all of the systems that they would ever
authenticate to.
Your naming convention should also be consistent.
If you use first name, middle initial,
and last name for one person, it should be that way
for everyone's username.
And to avoid any type of future conflicts,
you want to be sure to avoid describing any role
or status in a person's username,
because these could change over time.
The naming convention should also
require a persistent username.
The username that you get on your first day
in the organization should be exactly the same username
that you're using at the end of the organization.
You don't want someone's username changing sometime
during the duration of employment.
And the username should be memorable.
It should be something that the user can easily remember.
This doesn't necessarily mean that it
is a recognizable username.
Some organizations will use an employee ID number,
which is something that's very memorable for the user,
but something that's difficult to recognize
if a third party was to see that username.
This would mean that the standard user account
maintenance would start with the account creation, where your
provisioning the user and their access,
providing them with their password information,
and assigning them to the proper groups.
Then of course, you're going to provide constant password
updates to make sure that that password is always
changed at a regular period.
And you want to be sure to provide those audits to always
check for the permissions.
And when a person leaves the organization,
there will need to be a deprovisioning of this account
information.
The account would probably be disabled,
and all of the user documents and account information
would be archived.
Another standard part of account maintenance
is providing the right permissions for a user.
And these permissions can change over time.
Often users are added to a particular user group.
That user group is assigned permissions,
so it makes it easy.
As you add users to the group, they naturally
will use those particular permissions.
This often means that users are members of multiple groups.
And the permissions of those multiple groups may overlap.
It can become difficult to try to determine
what the effective or combined permissions are for someone who
is in these multiple groups.
And you don't want to run into problems
with implicit permissions, where one particular group denies
access to data and the other group allows access to data.
You would need to make sure that that user was
given the correct access for whatever job role they held.
An increasingly common policy to use for user permissions
is the location where that user happens to be.
GPS locations, for example, can provide very accurate
information on where a user is.
802.11 wireless gives you a more regional view.
And IP addresses can sometimes help you narrow down
where a user is.
But unfortunately, those can be wildly inaccurate
and would show someone in a completely different country
than where they happened to be.
You can use one or more of these location-based systems
to determine what policies should be set.
For example, someone may be able to access
a particular application or particular data
when they're in the office.
But if they are outside of the office,
they should have no access to any of those systems.
You commonly see this type of location-based policy applied
to firewalls.
For example, many firewalls allow
you to block entire countries based on an IP address block.
So you can define firewall rules that will automatically
block all traffic from certain parts of the globe,
because you know there's no one from that particular country
that would ever need access to your application.