Reports required as part of the IT Audit process
- Password Aging
- User Privileges
- System Privileges
- Remote Access
- Consolidated Change Logs
- NTFS Permissions
- Role Permissions & Membership
- User Access
- Auditing Enabled
Job Roles and Responsibilities – SOX Audit
Depending on the size of an organization, responsibility may be divided into the following defined
roles. It is important that responsibility is apparent and is supported by management. To achieve
this, the accountable persons must actually assume their accountabilities (i.e. they have powers
necessary to make corresponding decisions and the experience/knowledge to make the right
decisions).
Management and Human Resources should ensure that the necessary roles are correctly
implemented.
- Board and Executives The Board of Directors and the managing director or CEO
(or equivalent) are ultimately responsible for security strategy and must make the necessary
resources available to combat business threats. This group is ultimately responsible for
disseminating strategy and establishing security-aware customs within the organization.
They have the mandate to protect and insure for continuity of the corporation and to
protect and insure for profitability of the corporation. Information Security plays a crucial
role in both of these aspects of senior management’s roles. - Business process / data / operation owner This person is directly responsible for a
particular process or business unit’s data and reports directly to top management. He/she
analyzes the impact of security failures and specifies classification and guidelines/processes
to ensure the security of the data for which he/she is responsible. There should not be any
influence on auditing. - Process Owner The process owner is responsible for the process design, not for the
performance of the process itself. The process owner is additionally responsible for the
metrics linked to the process feedback systems, the documentation of the process, and the
education of the process performers in its structure and performance. The process owner is
accountable for sustaining the development of the process and for identifying opportunities
to improve the process. The process owner is the individual ultimately accountable for
improving a process. - IT Security manager/director This person is responsible for the overall security
within the organization. The IT security manager(s) defines IT security guidelines
together with the process owner. He/she is also responsible for security awareness and
advising management correctly on security issues. He/she may also carry out risk analyses.
It is important that this person be up-to-date on the latest security problems/risks/
solutions. Coordination with partner companies, security organizations, and industry
groups is also important. - System supplier The system supplier installs and maintains systems. A service level
agreement should exist defining the customer/supplier roles and responsibilities. The
supplier may be, for example, an external contracting company or the internal datacenter
or System/Security administrator. This person is responsible for the correct use of security
mechanisms. - System designer The persons who develop a system have a key role in ensuring that
a system can be used securely. New development projects must consider security
requirements at an early stage. - Project Leaders These people ensure that Security guidelines are adhered to in projects.
- Line Managers These managers ensure that their personnel are fully aware of security
policies and do not provide objectives that conflict with policy. He/she enforces policy
and checks actual progress. - Users Users, or “information processors/operators,” are responsible for their actions.
They are aware of company security policy, understand what the consequences of their
actions are, and act accordingly. They have effective mechanisms at their disposal so that
they can operate with the desired level of security. Should users receive confidential
information that is not classified, they are responsible for the classifying and distribution
of this information. - Auditor The auditor is an independent person, within or outside the company, who
checks the status of IT security, much in the same way as a Financial Auditor verifies the
validity of accounting records. It is important that the Auditor be independent, not being
involved in security administration. Often external consultants fulfill this role, since they
can offer a more objective view of policies, processes, organizations, and mechanisms.
Strategies for Auditing
Auditing enables you to monitor events associated with specific users, groups, and services.
These events are recorded to the security log. The capability to monitor these events is not only
useful for troubleshooting, but also is an important tool for monitoring and managing security.
You learned how you can keep tabs on the actions of specific users or groups and monitor
attempts at unauthorized access to the system or its resources.
Although you could audit every event, doing so wouldn’t be practical because you’d place an
undue load on the system and either end up with an enormous log file or spend all your time
worrying about archiving the logs. The following sections examine some specific scenarios and
how you might employ auditing.
Leaving auditing off
One option is to leave auditing off altogether, which is not a bad option in some situations.
If you’re not concerned with security, you have no real reason to enable or perform auditing.
Turning off auditing reduces system overhead and helps simplify log management; most
organizations are (or should be) concerned with security at least to some degree, however, so
this option is unlikely to fit your needs.
Turning all auditing on
At the other end of the auditing spectrum is complete auditing. If you’re very concerned about
security or shooting for C2 security certification, this may be an option. Bear in mind, however,
that your system is likely to generate a huge number of events requiring very active management
of the security log. As an alternative to full logging, consider logging only failure events and not
success events.
Auditing problem users
Certain users, for one reason or another, can become an administrator’s worst nightmare. In
some cases, it’s through no fault of the user, but instead results from problems with the user’s
profile, account, and so on. In other cases, the user can be at fault, frequently using the wrong
password, incorrectly typing the account name, trying to log on during periods when they are
not allowed, or even trying to access resources for which they have no permissions (or need). In
these situations, you can monitor events associated with the given user. You may even need to
retain the information for counseling or termination purposes.
Which types of events you audit for a given user or group depends on the problem area. Audit
account logon events, for example, if the user has trouble logging on or attempts to log on during
unauthorized hours. Track object access to determine when a user or group is attempting to
access a given resource such as a folder or file. Tailor other auditing to specific tasks and events
generated by the user or group.
Auditing administrators
Auditing administrators is a good idea, not only to keep track of what administrators are doing,
but also to detect unauthorized use of administrative privileges. Keep in mind, however, that
auditing affects system performance. In particular, consider auditing account logon events,
account management, policy change, and privilege use of an administrator only if you suspect
an individual. Instead, control administrators by delegating through the wise use of groups and
organizational units.
Auditing critical files and folders
One very common use for auditing is to track access to important folders and files. In addition
to tracking simple access, you probably want to track when users make or attempt to make
specific types of changes to the object, such as Change Permissions and Take Ownership. This
helps you monitor changes to a folder or file that could affect security.
Recommended Active Directory Guidelines for SOX audit Part 1
Part 1
Administrative Accounts
Administrative accounts include that includes (Domain Admins, Enterprise Admins, and Administrators)
Must have recognizable username for auditing purposes.
Active Directory build in Administrator account must be renamed and password is known only to company IT director or other executive personal.
On annual base Administrative accounts should be reviewed by IT director.
Generic Accounts
Generic accounts are general user accounts in active directory.
And are aplyed by Default Domain Policy GPO ( See password Policy )
Service Accounts
Service accounts are accounts used to run application services that requires domain credentials in order to function for example Backup applications .
It is recommended that Service accounts will named by service name and their password set to “Never Expire”
On annual base those Service Account passwords should be changed by IT team.
Happens that service accounts are members of “Domain Admin group ” And they should be approved by IT director.
Every service account should have detailed description, of their purpose.
Contractors
It is recommended to put Contractors user and computer accounts in dedicate OU and apply more comprehensive security policies
Every Contractor account should have detailed description, of their purpose (Department and Project)
Guests
Recommendation is to not use guest accounts at all
Active Directory Password Policy for example
“Password policy” is a set of password protection rules that apply to all company users
- Password must be at least 8 characters long
- Password must contain:
- At least 1 upper case letter
- At least 1 special character or digit. Example (*&^%$#@?.|\~`,012345678+-*/)
- The password can’t contain part of username.
- Maximum password age should be 90 days. (Or less )
- Password will automatically expire after 90 days since last change.
- Reminder is emailed to user 15, 7 and 1 day before password expiration.
- Minimum password age is 7 days.
- User cannot change password in less than 7 days after previous password change occurred.
- The system remembers 24 previous passwords. User may not use these passwords.
- User account is locked for 30 min after 5 sequential bad logon attempts.
- Service Accounts password are changed on yearly basis each 15/Jan notification is sent to IT group
Delegation of Control
Delegation of user management tasks to users with specific set of permissions.
This responsibility should be assigned to a small number of Administration staff.
User Opening Policy
you should have policy that documents each new user
User Maintenance Policy
you should have policy that documents each change at user account security
User Termination Policy
you should have policy that documents each retired user
Backup
You must have Active directory backup policy