Consider the following to support access restrictions
Menus provided should reflect user authorisation – don’t offer administration options to regular users. Data accessible should be determine by that users ID. Rights should be restricted – read/write/delete/execute. Output information should be limited – do let access to one chart make a whole file or folder become available. Highly classified information / systems should consider additional physical or logical controls to isolate them.
Secure log-on information
Secure log on should be able to substantiate the identity of the user. Where information classification requires it by policy, strong authentication should be consider above and beyond simple user ID and password. Log on procedure should not display system or application identifiers until log on has been successful – as an aside I’ve never visited a secure datacentre that has its name on the outside of the building, you have to know it is there to find it!
Systems should display warnings and not provide help messages that would aid unwelcome users. It should only validate a completed form and protect against multiple attempts “brute force” – think I am not a robot algorithms. IT should log unsuccessful attempts and make administrators aware of these. Upon successful logon should display a message of any unsuccessful attempts allowing the user to flag any unusual traffic.
Passwords should not be transmitted in an unencrypted format for obvious reasons. I’m no hacker, but this is easy meat for those who are.
Inactive sessions should be time dependent, logged off after a certain time, or a certain time inactive, whatever best suits the company policy. You should also consider times of day for application access – there aren’t so many employees working out of hours – should access policy reflect that?
Bear in mind that electronically, this is often your front door to the world. What you choose to store behind it, and the impact on its loss, or corruption, should guide you as to how strong that front door is.
Password management systems
In addition to password quality discussed above, management systems should enforce quality passwords, rejecting weak passwords, requiring confirmation and if issued with ID for passwords to be changed at the first logon. They should enforce password changes periodically, recording all passwords and refusing similar passwords previously used. Password storage should remain segregated from application systems.
Privileged utility programmes
Those programmes with override capabilities should be restricted and controlled. These should separately require authentication and be segregated from system applications. All activities should be logged. consideration should be given again to segregation of duties where practicable.
Access control to program source code
Source code should be protected with access restricted using source libraries. These should not be held with network applications. Logs should be maintained of check out and check in of code with audit trails of changes made to the code. Most developer tools carry this function. Development should be subject to a dry beta environment prior to release and migration to the live network.