Security category – 9.4. System and application access control
9.4.1. Information access restriction.
As discussed in previous controls; access to information should be decided based on the employee’s clearance level (are they authorized to view this information?) and their business need (do they need access to this data to do their job?). For this we need to define what the employee can do with the information (read, write, delete), their rights to access the application and even restricting what the user sees in their view to only what they have access to.
9.4.2. Secure log-on procedures.
The access to systems should be controlled with login procedures, such as secure login portals. This requires us to have clearly defined log-on processes and procedures that are easy to understand and use. They should not give information about the type of system being accessed, as this could aid an attacker in exploiting a service if they know the version for example, and it should be secured against unauthorized access.
9.4.3. Password management system.
The importance of password management cannot be overstated. Having an interactive password management system that forces users to log in, provides them with the capability to change their password and enforces your company’s password policy. This then provides applications that the user wishes to log into with a hash, key, ticket or similar without the application ever needing to have access to the user’s clear text password. This not only encourages good password practices for the user, but it also limits what systems house a user’s password reducing the impact of a system being compromised.
9.4.4. Use of privileged utility programs.
When an application on our home pc crashes many times we simply open task manager(ctrl-alt-del) and close that application. We can do this even for applications run by other users on the computer and for applications and tasks used to keep the operating system running. As you can imagine this opens the risk of causing system instability. Other utilities can allow us to alter the integrity of data or even override access controls among other, damaging actions. While they are useful for resolving some problems the use of these tools should be heavily restricted to prevent abuse. Audit trails should be maintained for the use of these and users should be required to authenticate.
9.4.5. Access to program source code.
Source code for any application should be protected as much as possible. There are many reasons for this but two good examples are; If a person has access to source code they can review it for potential exploitability or, for integrity, if we rely on tools for certain server operations when doing forensic investigating to find the cause and extent of a potential breach, we must be certain that those tools haven’t been tampered with, are accurate and are performing as intended. Changes to code, including for patching/updates should be done in a controlled and documented manner. This should include having a back out strategy and maintaining a log of any changes.
Adams In-Security 