391
Appendix N
User ID Administration
The objective of the user ID administration checklist is to determine whether access
to the IT resources and information assets of a company is properly controlled.
Access control is the first line of defense in information security. Good access control
can significantly enhance the overall security posture of a company. The basic
principle used when providing access is the “least privilege” rule, which is allowing
personnel only the level of access needed to do their jobs.
When reviewing user ID administration, it is important to remember that differ-
ent levels of access exist, including network, application, and remote access. The
principle of least privilege should be applied to all types of access.
In controlling access this way, there needs to be a balance between providing
the right level of access and the ongoing administration required to maintain multiple
levels of access. In some cases, strict access control may be warranted; in others,
however, it may not. The more granular and user-specific the access control, the
more time that will be required on administration.
This questionnaire focuses on the user ID administration process, which includes
providing, maintaining, and revoking access. The checklist also covers areas such
as privileged access and password rules. As with the other questionnaires in this
book, this checklist focuses on process and references technology at a conceptual
level. When conducting a security assessment, it may be important to bring in
resources with technical expertise to do a technical review of access controls on
specific systems. As with the other questionnaires, this one should be modified based
on the client’s specific business requirements.
QUESTIONS
1. Is a user ID administration policy in place? Has it been communicated
and is it readily accessible to all employees?
Guidance:
A policy for user ID administration is essential for effective ac-
cess control. The policy, like other security policies, communicates man-
agement’s expectations and also provides the means for enforcing good ID
administration practices.
Risk:
The risks associated with not having a policy include:
AU1706_book.fm Page 391 Wednesday, July 28, 2004 11:06 AM
392
A Practical Guide to Security Assessments
• Users do not know the user ID requirements.
• Ensuring user ID administration is being done correctly requires sig-
nificant enforcement and audit efforts, which are more difficult if no
policy can be used to enforce them.
Client Response:
2. Are procedures in place for the various aspects of ID administration —
e.g., gaining initial access, changes in access, termination?
Guidance:
Procedures should be in place to provide guidance to personnel
on user ID administration processes. Although the user ID administration
policy states the requirements, the procedures provide the step-by-step in-
structions on how these policies are implemented. Procedures also help
promote consistent processes across a company. Some typical procedures
that should exist include:
• Obtaining initial access
•Termination
• Obtaining privileged access
The basic elements of these procedures involve having someone in a man-
agerial role approving access and documentation of what access is re-
quired for employees to do their jobs. When reviewing procedures, keep in
mind that they are very dependent on how the organization is set up (cen-
tralized vs. decentralized information technology [IT] organization, num-
ber of personnel, etc.). Ideally, access should be given out based on the role
of the person.
Risk:
The risk associated with not having procedures is that access might
not be given properly resulting in users potentially having too much access
or too little access. The result is that you may have irate users who do not
have the right level of access; others, however, might have unnecessary ac-
cess to sensitive information. In the case of terminations, the risk is more
significant (this is discussed in detail in the termination checklist).
Client Response:
3. Does the policy or procedure clearly define roles and responsibilities
relative to access control?
Guidance:
Roles and responsibilities are critical elements in the policies
and procedures. Clearly defined roles and responsibilities establish owner-
AU1706_book.fm Page 392 Wednesday, July 28, 2004 11:06 AM
Appendix N
393
ship and accountability for the various tasks. Policies might have higher-
level roles, such as at the department level, whereas procedures define
roles more specifically by their job titles. Some of the roles that should be
defined include:
• Who provides access
• Who approves access
• Who tracks what access a person has
• Who owns the termination process
With ID administration, ownership is critical. In many companies, owner-
ship is not clear, and personnel have different ideas about who does what.
This situation can become chaotic depending on the number of personnel
and the level of turnover. It is very important that these roles and respon-
sibilities are not defined for specific people but for actual roles. This results
in less maintenance and it makes it easier to allocate specific responsibili-
ties to others if needed.
Risk:
Without clearly defined roles and responsibilities, there is no own-
ership or accountability. A risk exists that user ID administration processes
will not be completed properly or performed consistently. Taking it one
step further, enforcement is also difficult because there is no formal process.
Client Response:
4. Is access to IT resources provided based on what is needed for a particular
job and is it approved by a management-level employee?
Guidance:
Typically, when new employees join a company, access is giv-
en to certain IT resources so they can do their jobs. The purpose of this
question is to determine how this access is given and whether it is based
on a person’s job description. There is a balance here that should be con-
sidered. The more granular a level someone’s access is granted, the more
administration effort will be required. Ideally, job descriptions should cor-
respond to certain roles, which should correspond to certain access. For
example, a profile should exist for the position of accounts receivable clerk
that provides certain access, perhaps including edit access to the accounts
receivable transactions, read access to other financial information, and oth-
er general access such as e-mail and the Internet. Another consideration
when reviewing how access is granted is regulatory concerns. For example,
access to view consolidated financial information in publicly traded com-
panies should be restricted, as this is sensitive information that can be used
for insider trading. In addition, special thought should be given when
granting access to sensitive information (e.g., employee salary informa-
tion, research and development data) or privileged access.
AU1706_book.fm Page 393 Wednesday, July 28, 2004 11:06 AM
394
A Practical Guide to Security Assessments
Risk:
The risk associated with not granting access based on job descrip-
tions is users having inappropriate access to potentially sensitive areas of
the company and to sensitive information, which can be used for malicious
purposes.
Client Response:
5. Are user IDs unique? Are there any cases where IDs are shared?
Guidance:
User IDs should be unique and the system should validate that
if possible. With unique IDs, users are accountable for their actions. There
may be some cases where IDs are shared by necessity. One example of this
is certain manufacturing processes that are controlled by applications.
With these applications, if new users had to log on during the production
process, the disruption would cause production schedules to slip and ulti-
mately cost the company significant money. In these cases, shared IDs are
necessary. However, in most cases, unique IDs should be used. This is espe-
cially critical with privileged access, where users have full rights on a system.
Risk:
The risk associated with sharing IDs is the lack of accountability if
an incident (security or otherwise) occurs.
Client Response:
6. Do user IDs provide any indication of the access level that an employee
has?
Guidance:
Ideally, the user ID should not provide any information about
what type of access a person might have. For example, the user ID of a vice
president should not contain the official level of the individual or the letters
“vp,” which indicate vice president. Not having this information makes it
a little more difficult for users with malicious intent to determine which
user IDs are worth going after and which are not.
Risk:
The risk of having IDs that indicate the level of a person is that cer-
tain IDs become targets for hackers to use for gaining unauthorized access
to the company’s IT resources.
Client Response:
AU1706_book.fm Page 394 Wednesday, July 28, 2004 11:06 AM
Appendix N
395
7. Are IDs disabled after a certain period of inactivity?
Guidance:
Disabling IDs after a certain period of inactivity helps mitigate
any risks associated with user IDs that have no formal disposition. In some
cases, individuals may require access for short periods of time throughout
the year. Ideally, this access should be disabled once the user no longer re-
quires it. If the ID administrator failed to disable the ID, this feature auto-
matically disables it. This process is also a mitigating control if the
termination process is not being performed effectively. If a terminated
employee’s access was not revoked, this process at least disables it so it
cannot be used.
Risk:
The risk associated with not using this feature is that it increases the
possibility of having unused accounts that can be used to gain unautho-
rized access to IT resources.
Client Response:
8. How are password resets handled? Are reset passwords given to employ-
ees in a secure manner?
Guidance:
Password resets are one of the common methods used by social
engineers to obtain unauthorized access to a company’s systems. Password
resets must be handled in a secure manner where users are properly au-
thenticated before being given reset passwords. When reviewing this pro-
cess, look for documented procedures that help-desk or support personnel
must follow when resetting passwords. Ideally, support personnel should
authenticate the person by asking for some piece of personal information.
Reset passwords can be given after authenticating the person by leaving it
on an authenticated system such as voice mail where users can retrieve it
after putting in a password.
Risk:
The risk of not properly authenticating users when resetting pass-
words is that it can allow individuals to gain unauthorized access to IT re-
sources, which can lead to accessing potentially sensitive information such
as an executives’ e-mail, sensitive product information, or competitive data.
Client Response:
AU1706_book.fm Page 395 Wednesday, July 28, 2004 11:06 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.