<\/span><\/h2>\nAll of the names, as well as many of the details and situations in the anecdotes have been changed in order to protect the confidentiality of my customers and their businesses, as well as the people involved.<\/p>\n
In some cases, details from multiple incidents were “merged” in to a single anecdote, meant to be illustrative and not specific.<\/p>\n
You might read an anecdote, and think that I’m referring to YOU, or YOUR BUSINESS, or YOUR SITUATION.\u00a0 Lack of proper identity management, access control, and incomplete termination processes tend to precipitate the same type of problem, and many of these problems are quite common.<\/p>\n
In the anecdotes below, I am not referring to any actual person, company, or incident, and any similarity is purely coincidental.<\/strong><\/span><\/p>\n <\/p>\n
<\/span>Identity Management<\/span><\/h2>\nManaged, Central Identity is the basis for authentication and access control.<\/p>\n
Identity includes all attributes about an employee, such as their user name, “real” name, e-mail address, phone number, office location, and organizational hierarchy (their management chain and subordinates).<\/p>\n
All of this information is typically contained in a “directory”, which is an X.500 database that stores identity and credential information (“attributes”) for all employees.<\/p>\n
A directory, such as OpenLDAP or Microsoft Active Directory, can be used as a central authority for determining whether a person is a valid user of company resources, for authenticating users, and for access control.<\/p>\n
<\/p>\n
<\/p>\n
<\/span>Authentication vs. Access Control<\/span><\/h3>\nMany people discuss authentication and access control as if they were the same process, but they are separate.<\/p>\n
Authentication<\/strong><\/span> is the process of providing credentials to “prove” (authenticate) who you are, as a user of the system.<\/p>\nIn addition to your identity (such as a user ID), authentication uses one or more factors, consisting of secret information or physical objects, to help ascertain that you are who you claim to be.\u00a0 Here are some common factors used for authentication:<\/p>\n
\n- Password<\/strong> – This is the easiest and most prevalent form of authentication, but can also be one of the least secure.\u00a0 A password is some secret value that you enter when your identity is established (for example, when you create an account), and then you have to provide your password each time you authenticate.<\/li>\n
- Biometrics<\/strong> – Although currently very popular, this type of authentication is also highly-overrated, and can be fraught with problems.<\/li>\n
- Personal Identification Number (“PIN”)<\/strong> – A 4 to 8 digit “secret” number.\u00a0 Like a password, a PIN is meant to be kept secret.\u00a0 Anything with a 10-digit keypad, also known as a PIN pad, can be secured with a PIN.\u00a0 Examples include credit and debit card transactions, ATMs, voice mail, alarm systems, the lock code on your cell phone, and some door locks.\u00a0 Since a PIN only consists of numeric digits, PINs are much weaker than passwords.\u00a0 Also, people inherently tend to use the same PIN for everything, further weakening the system.<\/li>\n
- Certificate<\/strong> – Using a Public Key Infrastructure (PKI), each user is assigned a certificate which contains a cryptographic key that can be used to uniquely identify that person.\u00a0 Certificates might be installed on a company-owned laptop, or stored on a smart card or USB drive.\u00a0 Certificates are highly-secure, but can be easily copied or compromised, if not properly stored and handled.<\/li>\n
- Physical Token<\/strong> – A physical cryptographic device that displays a regularly-changing number.\u00a0 The number scheme is deterministic, and synchronized between the token device and the authentication server.\u00a0 The user enters the number along with a user ID and some other factor, such as a password.<\/li>\n
- Identity<\/strong> – Attributes such as your employee ID, work location, desk phone number, or other attributes can be used to support authentication.<\/li>\n
- Secret Questions<\/strong> – Creating secret questions and answers gives the server another method to authenticate you.<\/li>\n
- Public Data<\/strong> – Although intrusive and invasive (and thus, alienating), many companies have adopted a means for authenticating a user by asking questions that have been created based on public information, such as “What was your street address in 1992”.<\/li>\n
- RFID \/ Proximity<\/strong> – Using an RFID embedded in a badge, wristband, or fob allows for proximity-based authentication.<\/li>\n
- Text \/ E-mail Verification<\/strong> – Some systems send you a text message with a PIN, or an e-mail with a link, as a secondary validation factor.<\/li>\n<\/ul>\n
Once authenticated, Access Control<\/strong><\/span> determines who can access what, and who can perform which actions.<\/p>\nAccess Control is typically managed by role, and roles are typically mapped to group objects within the directory.<\/p>\n
Person –> Group –> Role –> Permissions<\/p>\n
<\/p>\n
<\/span>The Advantage of Centralized Identity Management<\/span><\/h3>\nCentralized identity management, using a directory containing user and group objects, that can be mapped by role to permissions, allows for one, central administration point for all entitlements (permissions and roles) for a given user.<\/p>\n
As an example, a database server might have a “System Administrator” role, allowing full access to the database instance and all databases within the instance.<\/p>\n
Perhaps “Sam” is a new database administrator.\u00a0 There might be several ways to grant access for “Sam”.<\/p>\n
\n- Create a local “Sam” user ID on the database server, and assign the SA role.<\/strong>\u00a0
Person –> Local User –> Server Role –> Permissions<\/em>
This is the worst option, because there are now multiple “Sam” accounts that do different things, depending on where they are, who created them, and what roles are assigned.\u00a0 Auditing is a nightmare, and disabling Sam’s access necessitates disabling a local account on every server where Sam has permissions.<\/li>\n- Create a global “Sam” user ID in the directory.\u00a0 Assign “global Sam” from the directory to the SA role on the database server.<\/strong>\u00a0
Person –> Directory User –> Server Role –> Permissions<\/em>
This is better, because there is now one “Sam” identity being leveraged multiple times.\u00a0 However, there is no central view of Sam’s roles.\u00a0 Although disabling Sam’s access can now be accomplished by simply disabling his directory user ID (thus preventing authentication), auditing or modifying permissions requires going to each database server to look at the SA role to see if “global Sam” is\u00a0 a member.<\/li>\n- Create a global “Sam” user ID in the directory.\u00a0 Create a “DBA” group in the directory.\u00a0 Assign Sam to the DBA group.\u00a0 Assign the “global DBA” group from the directory to the SA role on each database server.<\/strong>\u00a0
Person –> Directory User –> Directory Group –> Server Role –> Permissions<\/em>
From the directory, you can see that Sam is a member of the DBA group.\u00a0 You can remove Sam’s DBA privileges without disabling his user ID (the user ID is his ability to authenticate), by removing him from the global DBA group.\u00a0 Likewise, let’s say Sam is a DBA but his job function is to work ONLY on Accounting databases.\u00a0 Sam might be a member of DBA_Accounting, but NOT DBA_HR nor DBA_Marketing.\u00a0 Now, if Sam takes on greater responsibility, permissions can be assigned simply by adding him to those other groups, without modifying permissions on individual servers.\u00a0 In addition, the configuration of individual database servers is identical, making misconfiguration easier to detect.<\/li>\n<\/ul>\nCentralized identity and access management allows an employee to have one “user identity” that can be authenticated, and then seamlessly granted access for various resources and servers.<\/strong><\/p>\n <\/p>\n
<\/span>Access Control Best Practices<\/span><\/h2>\n <\/p>\n
<\/span>Create and Maintain an Access Inventory<\/span><\/h3>\nMaintain a master list (inventory) of all systems where an employee might have logical or physical access.<\/p>\n
The list should include the following information:<\/p>\n
\n- System name<\/strong><\/li>\n
- Description<\/strong> – what does this system do, or what can an employee access using this system?<\/li>\n
- Type of system<\/strong> – Physical, logical, internal, external, etc…<\/li>\n
- Risk Level<\/strong> – what damage could be done, if someone malicious gained access?<\/li>\n
- Owner<\/strong> – Every system needs an owner.\u00a0 We will cover this during the review process.<\/li>\n
- Backup Owner<\/strong> – It’s prudent to have a 2nd person who can make administrative decisions if the owner is unavailable<\/li>\n
- Vendor Contact<\/strong> – Vendor name, website, sales contact name and phone number.<\/li>\n
- Support Contact<\/strong> – Support website, phone number, plus account number or other pertinent information to open a support case (If you lose access, who do you contact to gain it back)<\/li>\n
- Authorized Contact List<\/strong> – Which employees are authorized by the vendor to make contact, open a support case, transfer a license, or the like.\u00a0 Critical company authentication information, such as phone numbers or e-mail addresses should be listed as well.\u00a0 For example, if e-mail confirmation is required to make account changes, that e-mail address should be listed here.<\/li>\n
- Mitigating Control<\/strong> – List any forms of access that preclude access to this system.\u00a0 For example, safe keys can’t be used unless the employee has either a key or badge access to the location where the safe is stored.\u00a0 Likewise, access to databases and\u00a0 other internal systems might be limited based on remote access to the network, and further gated by centralized authentication such as Active Directory.<\/li>\n<\/ul>\n
The purpose of the master list is as follows:<\/strong><\/p>\n\n- Ensure that there is a single point of authorization (the “Owner”) for approving access, and to review current access.\u00a0 This should NOT be the “administrator” – the administrator’s role is to actuate permission changes, NOT to review and approve them.<\/li>\n
- Ensure that all physical and logical systems are enumerated, to prevent inadvertently leaving access in place for a terminated employee.<\/li>\n
- Ensure that privileged access is identified, to ensure that the account can’t be hijacked by a disgruntled employee.<\/li>\n
- Ensure continuity in the event that a system administrator leaves or dies.<\/li>\n
- Serve as the basis for a periodic access review by the respective owners.<\/li>\n<\/ul>\n
For disaster recovery purposes, a printed copy of the list should be stored securely in a bank safe deposit box, or at a disaster recovery site.<\/p>\n
Building this list might require coordination across several departments, for example, Technology, Facilities, Office Admin, etc…\u00a0 It’s better to build one large list than maintain separate lists.<\/p>\n
<\/p>\n
<\/span>Establish a Key and Password Vault<\/span><\/h3>\nWhat do you do, if you have to fire your network administrator, or your network administrator quits, and refuses to disclose privileged passwords?<\/p>\n
What if that person dies unexpectedly?<\/p>\n
Rather than grant administrative access for an executive, who probably doesn’t understand how to properly administer the systems in question, a better approach is to create a “failsafe” administrative user with a unique password, seal the credentials in a labeled envelope, and store all of the envelopes in a safe or vault.<\/p>\n
Likewise, a copy of all physical master keys, badges, and other physical access tokens should be stored in the same safe or vault.<\/p>\n
Make sure the vault is physically secure – a locked filing cabinet is insufficient, as it can be easily picked, pried open, or destroyed in a fire.<\/p>\n
A fire safe is relatively inexpensive, and can be bolted to the floor.<\/p>\n
Another option is to use a bank safe deposit box.<\/p>\n
Assume that all passwords, including privileged passwords should be changed regularly, and plan to update the password vault accordingly.<\/p>\n
It goes without saying – the vault should be accessible by someone OTHER than the system administrator(s).\u00a0 Usually, this would be someone with a VP title or above.<\/p>\n
<\/p>\n
<\/span>What Goes in the Vault?<\/span><\/h4>\nIn short, everything on the Access Inventory list.<\/p>\n
Here are the highlights:<\/p>\n
\n- Physical master keys for facilities, filing cabinets, safes, storage, etc…<\/li>\n
- Master badges, fobs, and other physical tokens<\/li>\n
- Alarm system codes<\/li>\n
- Administrator user ID and password for Active Directory, and other enterprise-wide authentication systems<\/li>\n
- Administrator user ID and password for every server.\u00a0 Hopefully, your company has a standard or scheme.<\/li>\n
- Administrative user IDs and passwords for all Databases and Applications<\/li>\n
- URL, Administrator user ID and password for each application (internal and external)<\/li>\n
- Bank account information (Account Numbers, authorized users, passwords or PINs, wire transfer codes, safety deposit box numbers)<\/li>\n
- Vendor access information and credentials (such as authorized billing codes, account numbers, etc)<\/li>\n<\/ul>\n
<\/p>\n
<\/p>\n
<\/span>Anecdote: Deceased Administrator<\/span><\/h4>\nWhen I was a consultant, I was called in on an emergency basis on a Monday morning, to a small business where they had a couple of servers and maybe 50 employees.<\/em><\/p>\nThe network administrator had unfortunately passed away over the weekend, and no one else had access to do anything.<\/em><\/p>\nThey had been able to obtain access to some of their vendor accounts, but they also had a Novell server, a Windows server, and other internal systems, as well as external accounts that no one else could access.<\/em><\/p>\nWe were able to break in to the Novell and Windows servers to obtain administrative access, but there was a database platform that had to be rebuilt.\u00a0 Luckily, no data was lost, and we were able to gain access to everything, with only about one day of down time.<\/em><\/p>\nMany of the external accounts were tied to this person’s e-mail address, which required access to the specific e-mail account.\u00a0 Once we had administrative access, we were able to reset the deceased administrator’s password, and access their e-mail account in order to recover external account access.<\/em><\/p>\n