If you are an IT administrator then your employer is placing a lot of trust in you. You often have rights to go looking at data that really shouldn’t concern you. This is never more true then when you are a server administrator or even a domain administrator.
A survey by Cyber Ark Software in the UK that was reported on yesterday spells out the details:
- 33% of admins admit using their rights to access confidential data, e.g. salaries and read emails.
- 33% of admins admitted accessing computer networks via VPN even after leaving the company.
- 50% of users, including admins, keep passwords on post-it notes.
- 8% of admins admitted that application/appliance default passwords are never changed.
- 82% of admins said that if such passwords are changed then they store them in their head.
Auditing
Accessing confidential data is a major breach of trust. It’s this sort of behavior that has sparks an atmosphere of mistrust between IT and the security & internal audit departments. There are some steps that you can take to track this activity:
- Define some company policies: Clearly communicate (verbally and written word) that abusing your rights will lead to disciplinary action. Illicit behaviors should include accessing data outside the scope of work and the clearing of security logs.
- Enable auditing: You can either audit all or selectively audit files and folders. This will track user and/or admin activity.
- Collect security logs: I think the tool of choice for me right now in this market in the Microsoft world is Audit Collection Services which is included in Operations Manager 2007. If you have seen an audit trail in the Windows Security Log then you will know it is a collection of noise and impossible to track anything. The ACS agent will (in near real time) forward those log entries that Microsoft programmers know are important. These are stored in a central SQL 2005 database. There is a view in the database for reporting that provides a similar look and feel to event viewer. This database can be secured so that only security officers or auditors can access it.
- Management Support: None of this will work without management support.
Leaving Procedures
IT Helpdesk’s, auditors and security officers seem to have a common complaint in a lot of the sites I have visited. The complaint is that the HR department is (a) slow to tell IT when a person is joining the company and (b) often never tells the department when people leave. The latter is important because of mobility and remote access solutions that are usually in place. A person can leave a company but still have access to resources long afterwards. I’ve actually heard tell of a user in a site who was doing this for up to a year before they were found out … they were using file services, email, etc.
Procedures that include step by step instructions should exist for both when a person starts with and leaves the company. The leaving procedure should disable the account(s) for a defined period, maybe revoke some high privileges, e.g. domain admin, and then delete the account after X days.
Remembering Passwords
This is an old horse that apparently we haven’t whipped enough yet. For years, Microsoft has been preaching about ditching this old world password mentality of 8 characters changing every 30 days. The fact is that users don’t remember the passwords. I challenge you to walk around the floor to look for post-its on partition walls, on PC’s, under keyboards, etc. They will be plentiful, like a yellow, paper field of rapeseed-oil.
Microsoft believes the best solution is to adopt either PKI with smart cards or to adopt the use of passphrase’s. Smart cards are fine if you’re only using resources that can use them. Unfortunately, we all know of dodgy business application developers who can barely string together enough code to write a "Hello World" program and for some reason, our employers choose to buy critical applications from them.
The passphrase is a password but we think of it differently. It is usually a sentence, 14 or 15 characters long and because of the increased cryptographic strength we only need to change it every 6 months. Examples might be "I went to berkley university". That’s both strong and memorable. That’s the key … we need to make it memorable. Oh … what about sticking in digits and forcing capitals? Pfft! Old world! Think about it, hackers know that 1 = i and 0 = o. And forcing special characters, numbers and capitals only complicates the password for the user, making it forgettable and more easy to make mistakes, thus causing lockouts… it’d be like building your own denial of service routine directly into the network. Because the passphrase is so long, despite being memorable to the user, then it does not need to change very often. We can allow it to live maybe 6 or 12 months before forcing a change. You’ll have less post-its and less lockouts in no time.
Password Synchronisation
The number of passwords that we must remember is getting worse and worse. There are more systems out on the network that we have to secure. You can cut this down by synchronising passwords and user accounts across systems, e.g. MIIS. These gives a single sign-on like experience for users, e.g. 1 user & 1 passphrase across many systems. It would also help if application developers would learn to use the built in and secure Kerberos system of AD for user authentication and autorisation instead of building stupid SQL user account tables.
Change Default Passwords
This is a result of ineptitude or just pure negligence. Some employers only have themselves to blame for either hiring on the cheap or by creating a very negative working environment. But in the end, any capable admin should know that all passwords should be changed when a new application or appliance is installed.
In the past I deployed managed the following: We had 17 sites, each having network resources (servers and network devices). Each site had it’s own set of passwords, e.g. the server local admin account had it’s own password, the local desktop admin had it’s own password, network appliances had their own password, etc. These passwords were unique to each site.
Storing Passwords
You cannot store passwords in your head. Firstly there are too many of them. Secondly, what happens if you leave or forget one? The best solution is to securely store them in a way that is also readily accessible. One of the guys I worked with in the previously mentioned network build a Lotus Notes database that stored each password with an ACL. We could permission the passwords so that if a person from Munich went in, he could only see those Munich passwords that he had been granted access to. If a network admin went in then they would only see passwords for those network devices that they had been granted access to. It was quick and secure. There are third party solutions out there.
EDIT: My buddy, Declan Lynch, who wrote the Notes password database has decided to release it as an open source product.
Credit: Silicon Republic.