Justin A. Parr - Technologist

When an employee or contractor leaves the company, it’s best practice to immediately disable their access to company resources.

In the digital and online world, it’s easy to miss some forms of access, and remember off-hand every single system where the employee’s access should be revoked.

The level of risk increases when the employee separation occurs involuntarily, which might create a situation where the former employee is disgruntled, and increases exponentially if the employee has administrative privileges to sensitive systems.

In this article, I will attempt to outline best practices for a policies and processes around identity and  access management, enumerate specific forms of access, many of which might be overlooked, and share some anecdotes resulting from the failure to properly revoke a terminated employee’s privileges.

 

 

 

 

Disclaimer

All 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.

In some cases, details from multiple incidents were “merged” in to a single anecdote, meant to be illustrative and not specific.

You might read an anecdote, and think that I’m referring to YOU, or YOUR BUSINESS, or YOUR SITUATION.  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.

In the anecdotes below, I am not referring to any actual person, company, or incident, and any similarity is purely coincidental.

 

Identity Management

Managed, Central Identity is the basis for authentication and access control.

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).

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.

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.

 

 

Authentication vs. Access Control

Many people discuss authentication and access control as if they were the same process, but they are separate.

Authentication is the process of providing credentials to “prove” (authenticate) who you are, as a user of the system.

In 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.  Here are some common factors used for authentication:

• Password – This is the easiest and most prevalent form of authentication, but can also be one of the least secure.  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.
• Biometrics – Although currently very popular, this type of authentication is also highly-overrated, and can be fraught with problems.
• Personal Identification Number (“PIN”) – A 4 to 8 digit “secret” number.  Like a password, a PIN is meant to be kept secret.  Anything with a 10-digit keypad, also known as a PIN pad, can be secured with a PIN.  Examples include credit and debit card transactions, ATMs, voice mail, alarm systems, the lock code on your cell phone, and some door locks.  Since a PIN only consists of numeric digits, PINs are much weaker than passwords.  Also, people inherently tend to use the same PIN for everything, further weakening the system.
• Certificate – 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.  Certificates might be installed on a company-owned laptop, or stored on a smart card or USB drive.  Certificates are highly-secure, but can be easily copied or compromised, if not properly stored and handled.
• Physical Token – A physical cryptographic device that displays a regularly-changing number.  The number scheme is deterministic, and synchronized between the token device and the authentication server.  The user enters the number along with a user ID and some other factor, such as a password.
• Identity – Attributes such as your employee ID, work location, desk phone number, or other attributes can be used to support authentication.
• Secret Questions – Creating secret questions and answers gives the server another method to authenticate you.
• Public Data – 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”.
• RFID / Proximity – Using an RFID embedded in a badge, wristband, or fob allows for proximity-based authentication.
• Text / E-mail Verification – Some systems send you a text message with a PIN, or an e-mail with a link, as a secondary validation factor.

Once authenticated, Access Control determines who can access what, and who can perform which actions.

Access Control is typically managed by role, and roles are typically mapped to group objects within the directory.

Person –> Group –> Role –> Permissions

 

The Advantage of Centralized Identity Management

Centralized 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.

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.

Perhaps “Sam” is a new database administrator.  There might be several ways to grant access for “Sam”.

• Create a local “Sam” user ID on the database server, and assign the SA role. 
  Person –> Local User –> Server Role –> Permissions
  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.  Auditing is a nightmare, and disabling Sam’s access necessitates disabling a local account on every server where Sam has permissions.
• Create a global “Sam” user ID in the directory.  Assign “global Sam” from the directory to the SA role on the database server. 
  Person –> Directory User –> Server Role –> Permissions
  This is better, because there is now one “Sam” identity being leveraged multiple times.  However, there is no central view of Sam’s roles.  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  a member.
• Create a global “Sam” user ID in the directory.  Create a “DBA” group in the directory.  Assign Sam to the DBA group.  Assign the “global DBA” group from the directory to the SA role on each database server. 
  Person –> Directory User –> Directory Group –> Server Role –> Permissions
  From the directory, you can see that Sam is a member of the DBA group.  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.  Likewise, let’s say Sam is a DBA but his job function is to work ONLY on Accounting databases.  Sam might be a member of DBA_Accounting, but NOT DBA_HR nor DBA_Marketing.  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.  In addition, the configuration of individual database servers is identical, making misconfiguration easier to detect.

Centralized 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.

 

Access Control Best Practices

 

Create and Maintain an Access Inventory

Maintain a master list (inventory) of all systems where an employee might have logical or physical access.

The list should include the following information:

• System name
• Description – what does this system do, or what can an employee access using this system?
• Type of system – Physical, logical, internal, external, etc…
• Risk Level – what damage could be done, if someone malicious gained access?
• Owner – Every system needs an owner.  We will cover this during the review process.
• Backup Owner – It’s prudent to have a 2nd person who can make administrative decisions if the owner is unavailable
• Vendor Contact – Vendor name, website, sales contact name and phone number.
• Support Contact – 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)
• Authorized Contact List – Which employees are authorized by the vendor to make contact, open a support case, transfer a license, or the like.  Critical company authentication information, such as phone numbers or e-mail addresses should be listed as well.  For example, if e-mail confirmation is required to make account changes, that e-mail address should be listed here.
• Mitigating Control – List any forms of access that preclude access to this system.  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.  Likewise, access to databases and  other internal systems might be limited based on remote access to the network, and further gated by centralized authentication such as Active Directory.

The purpose of the master list is as follows:

• Ensure that there is a single point of authorization (the “Owner”) for approving access, and to review current access.  This should NOT be the “administrator” – the administrator’s role is to actuate permission changes, NOT to review and approve them.
• Ensure that all physical and logical systems are enumerated, to prevent inadvertently leaving access in place for a terminated employee.
• Ensure that privileged access is identified, to ensure that the account can’t be hijacked by a disgruntled employee.
• Ensure continuity in the event that a system administrator leaves or dies.
• Serve as the basis for a periodic access review by the respective owners.

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.

Building this list might require coordination across several departments, for example, Technology, Facilities, Office Admin, etc…  It’s better to build one large list than maintain separate lists.

 

Establish a Key and Password Vault

What do you do, if you have to fire your network administrator, or your network administrator quits, and refuses to disclose privileged passwords?

What if that person dies unexpectedly?

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.

Likewise, a copy of all physical master keys, badges, and other physical access tokens should be stored in the same safe or vault.

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.

A fire safe is relatively inexpensive, and can be bolted to the floor.

Another option is to use a bank safe deposit box.

Assume that all passwords, including privileged passwords should be changed regularly, and plan to update the password vault accordingly.

It goes without saying – the vault should be accessible by someone OTHER than the system administrator(s).  Usually, this would be someone with a VP title or above.

 

What Goes in the Vault?

In short, everything on the Access Inventory list.

Here are the highlights:

• Physical master keys for facilities, filing cabinets, safes, storage, etc…
• Master badges, fobs, and other physical tokens
• Alarm system codes
• Administrator user ID and password for Active Directory, and other enterprise-wide authentication systems
• Administrator user ID and password for every server.  Hopefully, your company has a standard or scheme.
• Administrative user IDs and passwords for all Databases and Applications
• URL, Administrator user ID and password for each application (internal and external)
• Bank account information (Account Numbers, authorized users, passwords or PINs, wire transfer codes, safety deposit box numbers)
• Vendor access information and credentials (such as authorized billing codes, account numbers, etc)

 

 

Anecdote: Deceased Administrator

When 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.

The network administrator had unfortunately passed away over the weekend, and no one else had access to do anything.

They 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.

We 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.  Luckily, no data was lost, and we were able to gain access to everything, with only about one day of down time.

Many of the external accounts were tied to this person’s e-mail address, which required access to the specific e-mail account.  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.

Moral of the story:

1. Always have a password vault
2. Make sure every person in a critical role has a backup.
3. Use a group or generic mailbox for external accounts and vendors.

 

Avoid “Key Man” Issues by Assigning a Backup

For critical functions, always ensure that there is another person in the organization with at least a basic knowledge, and appropriate permissions to act as a backup.

Sometimes, people think that being a “key man” is job security.  It’s also a prison.  You can’t take a personal day, you can’t take vacation, you can’t attend to family matters, or take a sick day, because you have to be available 24 x 7 to perform this critical function.  You will also never get promoted — if management promotes you, who will do YOUR job?

Having a backup means that you can take a day off.  They can call you for emergencies, or if an unfamiliar situation arises.

In smaller companies and organizations, the “backup” person doesn’t need to be dedicated – he or she can be someone who already has full-time or part-time responsibilities in other areas.  With as little as 4 hours per week and some cross-training, a person with the proper aptitude can quickly come up to speed as a proper backup to the “key man”.

Anecdote:  Held Hostage by the Network Admin

A friend of mine runs a small business, and became suspicious of his network administrator.  Some hardware purchases had been made, that didn’t show up in any inventory, and couldn’t be located in the office.  In addition, he had a suspicion that some of his servers weren’t being properly backed up, and there were some additional red flags.

I came in after hours to perform a lightweight audit / survey, just to figure out what was going on, and if things were being properly managed.

I found some serious gaps, and we started talking through options.  Ultimately, due to the missing items, and some other sketchy things that had transpired, the owner felt that he could no longer trust the network administrator, and we developed a plan to replace him.

The network administrator either got wind of this plan, or sensed that his time was near, and secretly started removing access for anyone except himself.

The owner and I had interviewed and selected a new network administrator, and the plan was to let the current one go on Friday afternoon, bringing the new guy in on Monday morning.

When the time came, the owner called the administrator in to his office, and before anyone could say anything, the network admin said, “If you’re thinking of letting me go, I think you should know that I’ve locked everyone out, and I have the only admin account.”

The owner threatened to have him arrested, to which he replied, “there’s no law against doing the job that you’ve hired me to do, which is, to protect the company’s data.”

The owner threatened to sue him, to which he replied, “I’m sure it will take weeks to get this in front of a judge, and I’m sure I will have forgotten the password by then.  Can your business afford to be down for that long?”

This guy thought he had the owner over a barrel.

After some heated words, the network administrator was escorted off the property, with the parting words, “Call me on Monday, when you change your mind.”

Fortunately, we had pulled a backup tape out of rotation during my “survey” the week prior, and we were able to use that to restore the security database for the network, file permissions, other users’ admin access, as well as the original password for the “Administrator” account.

Instead of two weeks’ severance pay, the network admin ended up terminated with cause, and because the IT community at that time was very tight knit, he ended up blacklisted, as well.

Moral of the story:

1. Having the tape, which was basically a password vault, saved much time and effort.  Breaking in to the server still would have been possible, but it would have taken days to re-create user accounts, create a new permission scheme for files and other resources, restore access to files, resources, and e-mail, and fix various other problems.
2. If there had been a designated junior administrator, unless the two conspired, there would have been some forewarning about the network admin’s malicious actions.
3. Anything dealing with money should have dual authorization or dual control.  In this case, the network admin was authorized to order equipment, and the invoice went straight to accounting.  A better process is to have the network admin submit a purchase request to the office manager, who then places the order.  Once the equipment arrives, it should be added to a hardware inventory and the fixed asset list.
   
4. Carrying out what basically amounts to extortion is not the best career move.

 

Use Generic E-mail Addresses for Vendors and External Accounts

Most vendors require a technical, administrative, and accounting contact, or they let you set up as many points of contact as you want.

Have the vendor structure their communications as follows:

• Invoices should go to “invoices@yourcompany.com” or “accounting@yourcompany.com”
• Renewal and down time notices should go to “technical@yourcompany.com” or similar.

In turn, these e-mail addresses should either distribute to multiple people within the company, or should route to a shared mailbox that’s checked regularly – for example, the Help Desk is a perfect technical contact.  When they receive a renewal or down time notice, they can escalate to the appropriate person.

Anecdote:  Tim’s Domain

A person who we will call “Tim” worked at a medium-sized company, and was managing a team whose objective was to build and manage an ASP implementation of the software that the company produces and normally sells to customers, to run in their data centers, where the ASP would target the small-tier market who would not normally be able to make the capital investment for the software plus supporting hardware and infrastructure.

“Tim” registered a bunch of domain names for use by this ASP environment.  Rather than using an existing corporate account with a reputable vendor who already provided domain name and registration services for the company, “Tim” decided to save a buck, and go with another registrar.  “Tim” set himself up as the billing, technical, and administrative contact for the domains in question.

A few months later, “Tim” left the company, and eventually, the ASP implementation went live (obviously, without “Tim’s” help)

A year later, BAM, clients attempting to log in to the ASP website were greeted with a message indicating that the domain name registration has lapsed, and that the domain has been purchased, but was available for resale at a very “reasonable” price.

When “Tim” left the company, no one realized that every attempt by the registrar to contact the company went to “Tim’s” mailbox and phone number — the same mailbox and phone number that ceased to exist about a week after “Tim” left.

At the renewal mark, the registrar sent the company an e-mail,  that bounced.  After a few more unanswered e-mails and phone calls, the registrar sent a paper invoice, that, YOU GUESSED IT, went to “Tim”, and since “Tim” was no longer an employee, the paper invoice got tossed without ever being opened.

The registrar put the company’s account in to delinquent status, and after 3 more months, terminated the account, and released the domain registration.

Again, since “Tim” had an individual account with this registrar, rather than a corporate account with the company’s vendor of choice, no one noticed that anything was wrong, nor did the vendor have any other company contact information.

The minute the domain became available, it was snarfed up by domain squatters who look for exactly this type of opportunity to make a large sum of money by holding the domain hostage.

Now, the company looks like a bunch of idiots, because their ASP clients are staring at a web page (with misspelled words, I might add) indicating that the company can’t pay its bills on time.  Aside from the revenue impact, the reputational impact was beyond measure.

Moral of the story:

Obviously, you can’t fix the “Tim’s” of the world, who have a proclivity to run off in whatever random direction their brain manages to concoct, rather than do “that other thing” that I like to call “asking someone who knows”, but you CAN certainly mitigate “Tim-like” issues by conducting infrastructure reviews, and using generic e-mail addresses.  If “Tim” leaves the company, invoices should still go straight to accounting, and renewal notices should still go to the Help Desk.

 

Implement a Policy Requiring the use of Company-Owned Communication Resources

Vendor Access

If someone creates a vendor account on behalf of the company, but uses their personal e-mail and phone number, two problems could arise when they leave the company.

A disgruntled employee could disrupt critical services and infrastructure.  Here are some vendor-provided services that are particularly vulnerable.

• Domain name registration.  The employee could basically turn off access to your company’s website, e-mail, and any client-facing or B2B applications hosted on the web.  Maliciously, your company’s website could be redirected to, say, a porn site, or your company’s e-mail could be redirected to a competitor.
• SSL / TLS certificates.  If you conduct commerce on the internet, or allow your users to securely log in to your website, you probably use SSL / TLS to encrypt web traffic.  Certificates, issued from a third-party Public Key Infrastructure (PKI), such as Symantec / Verisign, are used to authenticate your server to the user, and to facilitate encryption key exchange.  A disgruntled employee could cancel your web site’s certificate, preventing secure access, or create a new certificate for a new,  malicious web server, that your customers think is your web site.
• Hosting Services.  If your website resides with a hosting provider, whoever has administrative access to the hosting service could shut off the website, or replace it with less flattering or malicious content.

The other big problem that could arise, occurs when an employee sets up a vendor account on behalf of the company using their own credentials and contact information, such as a personal cell phone and e-mail address, but the invoices go straight to accounting.

In this scenario, a disgruntled employee could order goods and services on behalf of the company, that could go undetected for quite some time.

For example, the disgruntled employee could purchase a server or hosting services, and set himself up in business, competing with YOUR company, and YOU would be paying for it!

If an employee owns the contact information used for a vendor account, THEY own the relationship, NOT the company.

Client Perspective

In addition to securing vendor / partner access, it’s important to protect your clients.

You might ask, “What’s the harm in allowing our sales guy to use his personal cell phone?  I don’t even have to pay for it, so he’s saving me money!”

YOUR CLIENTS CALL HIS PHONE NUMBER.

Unless you own that phone and the associated phone number, they are HIS clients, NOT yours.

I’ve seen many consultants and sales folks assert that “they already have a cell phone” that they prefer to use, or consultants who assert that “they already have a business line at home” – the ONLY correct answer is:

“You’re welcome to use your personal phone for personal use, but the ONLY phone number and e-mail address that’s going on your business card, are the ones I own.”

The same should be true for e-mail and other communication channels – any method that the client can use to contact the company should be owned by the company.

In addition, consider implementing a social media policy:

• Preclude using the company’s name in social media account names (prevent impersonation)
• Preclude discussing the company or its clients, as well as speaking on behalf of the company in social media
• Authorize the company’s Communication Manager to create and control all company-related social media accounts, and mandate that any social media needs should be addressed by the Communication Manager.

 

Anecdote:  The Displaced Support Engineer

I had a professional acquaintance who I’ll refer to as “Rob”, who worked as a Support Engineer for a large company, that we’ll call “XYZ” company.

“Rob” worked for “XYZ” for about 3 years as a support engineer, which at the time was about double the average employment term for someone in “Rob’s” profession.

“Rob” worked nights and weekends supporting his customers, and took calls at all times of the day and night.  “XYZ” corp didn’t provide “Rob” with a cell phone, but let him expense business calls made on his personal cell, so many of “Rob’s” customers had “Rob’s” personal cell phone number, so they could contact “Rob” for critical or urgent issues, without having to go through the normal escalation process.

“Rob’s” customers were always happy with his work, and “Rob” always got top marks from his clients.

One afternoon, I got a call from “Rob”, who informed me that he had been unexpectedly let go, and wanted to meet with me to get my perspective.  At the end of the day, I met “Rob” for drinks at a nearby establishment.

While we were talking, “Rob” got a call on his cell – one of his larger customers had an issue and needed “Rob’s” help.  “Rob”, the consummate professional, began the call by outlining the situation – he had been let go just that day, but he cared about his customers, and he wanted to make sure they got the help they needed.  “Rob” provided a few suggestions for them to try, and instructed the customer to call their “XYZ” rep, who would then be able to provide the contact information for a new Support Engineer.

I called “Rob” a week later, to see how things were going, and he related to me the events that transpired after we met at the bar.

• His ad-hoc suggestion had, in fact, resolved the customer’s initial problem
• Following “Rob’s” prompting, the customer tried to call their rep to get a new SE contact, but couldn’t get a hold of their rep.
• Later that night, the client had another issue.  Out of respect for “Rob’s” situation, they avoided calling him.  They repeatedly reached out to the “XYZ” sales rep, as well as the main “XYZ” support numbers.  No one could help them fix the problem, and no one was familiar with their particular situation, necessitating many explanations, and time wasted with no results.
• The following morning, they called “Rob” on his cell (hey… they already had his cell number…) and offered him a job, $100k salary plus benefits, and a $5k signing bonus if he could start immediately.  As in, if he could start at 9 AM.
  

“XYZ” was charging $150/hr for “Rob’s” time, and he was only making $80k/yr – now the customer gets “Rob” for about $55/hr, and “XYZ” loses about $100K/yr in revenue.

Moral of the story:

• Grace, commitment, and integrity are an investment.
• The customer’s perception of value translates to revenue.
• Enforce company-owned communication channels.

Alternate Ending:  Rob is Out…Rick is In

Here is what might have played out for “XYZ” corp, if they had provided “Rob” a company-owned cell phone:

• At “Rob’s” termination, the manager retrieves the company-owned cell phone that “Rob” normally uses for support purposes.
• That night, the big, important customer calls “Rob’s” company-issued cell phone number, but “Rob’s” former manager answers.
• “Rob’s” former manager explains the situation, and engages “Rob’s” peer, “Rick”
• “Rick” isn’t 100% familiar with “big important customer”, but he works through their issue.
• The next day, the “XYZ” rep gets a scathing call from “big important customer”, and the “XYZ” rep offers a 30% services discount over the next 3 months, to ensure continuity and help build the customer’s perception of value in “XYZ” corp.
• “Rick” eventually comes up to speed, and “big important customer” is satisfied with “Rick”, even though he’s no “Rob”.

“Big important customer” continues to leverage “XYZ” support at $150/hr.  “XYZ” built good will, and demonstrated commitment to its customer, in light of a difficult situation.

Meanwhile, the folks at “big important customer” corp still sit around at break time, wondering, “What ever happened to ‘XYZ Rob’?  Man!  That guy was sharp!”

Alternate Ending:  Disgruntled Rob

It’s easy to give in to frustration.  Here is what might have happened if “Rob” was a little less graceful.

• “XYZ” lets “Rob” go, but he has been using his personal cell phone for customer support.
• “SomeBig” corp calls “Rob”, who spends 20 minutes filling their ear with a profanity-laced litany of every “XYZ” corp shortcoming.

Obviously, “Rob” isn’t going to parlay this experience in to a career.

On the other hand, at best, this sours the relationship slightly between “SomeBig” and “XYZ”.  Degraded trust might mean deferred future spending on “XYZ” products and services. 

At worst, “SomeBig” terminates their agreement with “XYZ”, citing all the dirty secrets revealed by “Rob”.

All this, over one cell phone.

 

Implement a Policy Requiring a Centralized Directory for Identity Management, Authentication, and Access Control

If your company is a Microsoft customer, Active Directory is a natural choice for the centralized directory, and all major platforms interoperate with Active Directory either through Windows security mechanics, or via another directory such as OpenLDAP.

If your company is not a Microsoft customer, implement one of several open source directory servers, including OpenLDAP or Apache Directory.

Policy Element	Purpose
Each employee should have a unique user ID in the enterprise directory	Ensure that each person is able to be uniquely identified and authenticated, and that permissions and entitlements can be applied individually.
The enterprise directory should enforce the following password policy: Minimum of 8 positions Require a letter, a number, and a symbol Maximum password age: 90 days Minimum password age: 10 days Can’t reuse the last 10 passwords	Ensure that passwords adhere to a minimum level of security. By requiring that passwords MUST be changed periodically, a compromised user ID would become secure. By remembering previous passwords, and establishing a minimum password age, you prevent “stubborn” users from cycling quickly through known passwords, in an attempt to keep their “familiar” password.
The “full name” of the user within the directory should directly match the name of the employee, as stored in HR records or HRIS / HCMIS (HR application). The employee’s proper name should be stored, in order to match HR records, in addition to any nickname.	Ensure that any user ID can be tied to a known employee of the company. Employment is a pre-requisite for access to company-owned systems. Contractors and vendors present an obvious issue – we will address that separately. Ensure that users who go by a nickname are correctly tied to the HRIS / HCMIS application.
Any new servers, databases, and applications should support enterprise authentication and access control using open protocols and standards, such as LDAP.	Ensure that single identity is leveraged for authentication. One user ID, multiple access.
All systems capable of supporting enterprise authentication must use the enterprise directory for user authentication.	Ensure that single identity is leveraged for access control. One user ID can be assigned to multiple groups, which map to various roles on various systems.
All systems capable of supporting enterprise access control must leverage groups within the enterprise directory, mapped to local roles, for permissions and entitlements.	Ensure that local systems do not bypass enterprise identity management.
Edge devices (routers, firewalls, and VPN) must use the enterprise directory for authentication, either through LDAP, or indirectly through RADIUS	Ensure that remote access to company-owned networks and network devices leverage single identity, and that only approved roles are authorized to connect to and / or manage these devices.
Systems that are NOT capable of supporting enterprise authentication must use local user IDs named identically to the enterprise directory.	Create an easy audit process, where each local user ID can be matched to the enterprise directory.
Systems that are NOT capable of supporting enterprise authentication must be configured with a system-enforced password policy that complies with enterprise standards.	Ensure consistent security controls across systems.
Systems that are NOT capable of supporting enterprise authentication must have a mitigating control, such as necessitating local network or VPN connectivity as a pre-requisite to direct system access.	Ensure that systems which can’t leverage centralized authentication, can’t be accessed directly (e.g. via the internet)

 

Anecdote:  Difficulties Matching Directories

• I had a large scale project at a large company, to collapse several NT domains.  The first step in a project like this is to clean up the directory – in this case, a Windows NT domain – that will be used for the “master record” for each user account.  This can take days, and is an iterative process, working with Human Resources to validate if “so and so” is still here at the company, and if so, what is their “actual” name.
  
  We got down to just a few mismatches, and we had two accounts that we couldn’t reconcile.  One, we’ll call “Timmy Stevens”, and the other we’ll call “Bobby Stevens”.  Usually, you can match two accounts because the phone number, office location, e-mail address, or their manager’s information will be the same between the two accounts.  In this case, these looked like two different people.
  
  We contacted HR, and there was a record of “Robert Stevens”, and we were able to match that to “Bobby”.  We called “Bobby” to ask if he knew “Timmy”.
  
  “Oh, that’s my old account.  I switched departments a few years back, and Thomas is my middle name, but I started going by Bobby because this department already has a Timmy, so they just set me up a new account.”  You can’t make this stuff up.
  
  
• I did a network audit for a medium-sized company.  I mapped out who all had administrative access, and most of the names made sense – the IT guys had admin access, the IT director had access, and a couple of folks who “had been” in IT but had moved to other departments, yet no one had removed their admin rights. 
  
  I also found an account called “Steve Kennedy”.  No one knew who “Steve Kennedy” was.  We looked at the security logs, and he mostly connected via RAS (the old Windows NT dial-up access – this is what people used before VPN was practical) or from a couple of very-critical, very-sensitive servers.  There was no record of who created the account, and it was set to never expire, with no password enforcement.
  
  It turned out that the previous Network Administrator had been let go about 6 months ago, and one of the reasons they brought me in, was because “suspicious” things had been happening – there were several instances that files got moved or deleted, or information had been updated.  When he got let go, they immediately disabled his account – just about the exact minute he left the building.
  
  What they didn’t know, is that the admin had surreptitiously created a second admin account with RAS and Admin access.  He had been dialing in for months, and intentionally causing little problems all over the network.  What he either didn’t know, or didn’t consider, is that his phone number had been recorded in the RAS server’s logs.  We disabled his account, and turned copies of all the logs over to the corporate attorney.
  
  
• I did some work for another medium-sized company, helping streamline their IT department.  The company had an HRIS (Human Resources Information System) that was managed by… Human Resources.  When a new employee started with the company, the HR folks would enter his/her information in to the HRIS.
  
  The HR folks would create a user ID for the HRIS based on their best guess about how the IT department was going to create the network ID – the idea was to make sure the user ID for the HRIS matched the network ID.  HR had the first step – setting up the new employee in the HRIS, which established their name, employee ID number, employment status, organization (management chain and list of subordinates), and other basic employee information.
  
  The next step in the process, was to forward all of the information over to IT, who would then create the network ID.  The problem occurred because the rules followed by IT to create the network ID would not always match the guess made by HR, so IT would then have to send the network ID information BACK to HR, who might have to adjust it in the HRIS.
  
  For example, if “Robert Thomas Stevens” is a new employee, and prefers to be called “Tom Stevens”, HR might create “tstevens”, but the IT group might create his network ID as “rstevens”, requiring HR to go back and update the HRIS ID to “rstevens”.
  
  We resolved this, and simplified the process by handing HR a few simple rules for user naming and resolving duplicate names, and placed the responsibility with HR for user ID naming.  Now, HR creates the user ID when they create the HRIS record, and IT uses the same ID.
  
  Later, we were able to link HRIS authentication to Active Directory through LDAP – the extra effort spent ensuring that the HRIS user ID matched the network user ID was an investment.
  

 

 

Require Quarterly Reviews for All Access System

Once per quarter, a full access review should be conducted.

1. Starting with the central directory (such as OpenLDAP or Active Directory), compare a list of directory users to HR’s list of employees.  Excluding service accounts, any user ID that can’t be matched to a valid employee (or contractor) should be immediately disabled until the ID can be validated and properly documented, or deleted because it’s no longer needed.
2. Compare users within each access system to the central directory.  Any user ID that can’t be matched should be immediately disabled until it can be properly identified and documented, or deleted because it’s not needed.  By “Access System”, we mean every system utilizing access control, listed on the Access Inventory.
3. For each access system, the owner should review what users are assigned to each role (thereby assigning permissions), and make any necessary adjustments.  For example, if a particular employee switches departments, their ID might no longer need access to the accounting system, and should be removed, or, they might need to be changed to a different role within the accounting system.
4. Physical access systems should be reviewed, including lists of who has keys to the building or internal offices, badge access, safe keys, and access PINs.
5. External accounts should be reviewed by the owner, ensuring that users who no longer need access should be removed, and that all remaining users’ permissions are correct.  For example, who has purchasing authority with your hardware vendor?
6. Artifacts of the review process should be stored, including copies of the user lists, changes requested by each owner, and the person’s name who performed each review.

 

Anecdote:  Stale Users

When I was a consultant, it was quite common to perform an audit, and find user IDs for people who had been gone for years.

The user IDs were usually active, and some had administrative access!

In one case, the former CFO (who left the company over a year previously) still had an active user ID, with full access to the accounting system!  Someone could have logged in as him, and generated a check using the AP or payroll systems.

In another case, I was doing some work for a hospital, and we found active user IDs for doctors that had left.  The problem is that any of those user IDs could be used to generate a prescription for drugs that could then be picked up at the hospital’s dispensary!  A malicious employee could have modified a patient’s proscribed medication or treatment.

Fortunately, in these particular situations, no one did anything malicious, but the potential was certainly there!

Moral of the story:

• Promptly remove access for terminated employees
• Quarterly Access Reviews would have caught all of these problems.

 

 

 

Contractors and Vendors

Contractors and vendors represent a special set of challenges for identity management and access control.

 

Maintain a Master Contractor / Vendor List

Either HR (preferably) or Accounting should maintain a master list of contractors and vendors – named individuals who are allowed on company premises and to use company-owned equipment.

Depending on the situation, such as a long-term project, Contractors and Vendors might be issued keys or badge access to the facility.  If not, they should be escorted by an employee at all times.

 

Equipment

Prior to 2007, one of the “IRS 20 factors” when determining a person’s status as “employee” versus “independent contractor” was that an employee would be provided work equipment, while a contractor is expected to procure their own equipment.

This created a conflict between HR and IT:

• IT wants everyone to use company-owned equipment, in the interest of protecting the company from stolen data, viruses, and other security problems.
• HR wants contractors to bring and use their own equipment, to protect the company from having contractors mis-classified as employees.

As of 2007, the IRS now uses 3 factors, based on the level of behavioral and financial control, as well as the type of relationship (e.g. contracts or agreements in place between the parties).

Because the use of company-supplied / company-owned equipment is no longer an issue, enforce a policy requiring contractors and vendors to use company-owned equipment when accessing company-owned information systems.

 

Anecdote:  Buggy Contractor Laptop

As a consultant, I was doing some work for a medium-sized company.

At about 8:30 AM, the help desk started getting widespread calls of people getting disconnected from the network, or having intermittent connectivity issues.

The IT group trusted me, and asked me to help take a look at the problem – this was potentially a huge issue, if everyone in the company was essentially unable to work.

We tracked down a person who was having the problem, and observed what was happening.  There was no log entry or other indication, so we loaded a packet capture tool, and looked at the underlying network traffic.  We observed a specific type of network broadcast that seemed to be causing the network client to disconnect from the network because the broadcast was triggering a re-negotiation.

Using the information in the broadcast packet, we eventually traced the “rogue” broadcast packet down to a particular switch port.  We shut down the switch port, and sent a team to go trace the port to a specific network jack, so that we could figure out who was connected and what they were doing.  The minute I disabled the switch port, the problem stopped!  10 minutes later, it started again.  I began the process of tracing down the rogue broadcast packet again, and found that it was originating from another port on the same switch, so we shut that one down, as well.

We got a call from the team we had sent out to trace the connection…  They had found the rogue machine and disconnected it from the network, so I grabbed my cell phone and headed toward them.

What happened?

The Marketing department had hired a contractor, who had brought his own laptop with him, and plugged it in to the network. It had taken us about an hour to find the problem and disable his switch port.  When his connection “stopped working”, he moved to an adjacent empty cubicle, and plugged in to that network connection – explaining why the problem appeared to “move”.

He had worked for quite a few companies, and had usually used his own laptop.

This person, who we will refer to as “Stan” considered himself an IT expert and power user, and when we tried to talk to him about his laptop, he got very defensive, and insisted that “he was an expert”, and therefore couldn’t be responsible for taking the network down.

After some verbal argument between “Stan” and the IT guys, I stepped in, told him that, “expert” or not, we had proof that his laptop was disrupting the network, and therefore we were taking it.  He could either give us the laptop, or security would be happy to escort him from the premises. 

After confiscating his laptop, we took it back to the IT lab, and here is what we found:

• His laptop had come with 1 free year of Norton antivirus.  Even though it popped up, prompting him to renew every time he logged in, his subscription had expired over a year ago, and he had just never noticed.
• He had two different viruses – this event pre-dated the age of adware and “PUPs” (Potentially-Unwanted Programs).
• At each company where he had done some work, the local IT guys had obviously tweaked it or installed various network client software on his laptop, allowing him to connect to their networks.  Therefore, his laptop was a hodge-podge of software, most of which was not necessary but running.
• He was running unlicensed copies of several graphics packages.

The problem turned out to be with one of the network client software packages, loaded by the IT guys at some other company, long ago.  It was misconfigured, and kept sending out broadcasts in an attempt to determine the proper configuration, and these broadcasts were causing all sorts of network problems.

I went back to “Stan the expert”, reviewed my findings, and gave him two options.  Either the IT staff would wipe his laptop, restoring it back to factory defaults, or he could remove his laptop from the premises and use a company-owned desktop to do his work.

Moral of the story:

Require contractors and vendors to use company-owned equipment

 

Use Web Conferencing for Vendor Access

Web conferencing, such as WebEx (www.webex.com) or Go to My PC ( gotomypc.com ) can be used to “share out” a desktop or server, allowing the vendor to connect to and “share” a session with one of the company’s authorized administrators for that system.

This allows a trusted company employee to monitor all actions performed by the vendor, and has the added benefit of having the employee be able to observe, and therefore learn, corrective actions taken by the vendor to administer or repair the system in question.

Vendors usually have a very limited scope, making web conferencing an excellent option for them to connect to specific systems, without having to create an identity and set up access – they are proxying the employee’s already-authorized access.

This option does NOT work well for contractors, who are expected to work independently.

 

Identity and Access

HR should maintain a list of contractors or vendors who have long-term access requirements.

These types of contractors and vendors should have an entry in the central directory, and their account should be set to expire either at a specified contract end-date, or if the service is open-ended, set the expiry for 30 days.

Every contractor or vendor should have an assigned “manager”, an employee who “owns” the relationship and can authorize, request, or extend access to network resources on their behalf.

The contractor’s status should be reviewed and confirmed with the manager every 30 days.

HR should be notified of all new contractors, as well as changes in status, and exiting contractors.

Considerations:

• A contractor working in the company’s facility could get injured, and the company is liable.  There needs to be a clear understanding of who is / is not authorized to work in a company facility.
• Equipment.  Contractors must be required to surrender company-owned assets upon exit.
• Contractor IDs should be immediately disabled upon exit – this requires coordination with HR and IT.
• Accounting should be made aware of changes in status for active contracts.
• Facility access should be revoked – Contractors must surrender keys and badges upon exit.

 

Identify and Mitigate Liability

The company’s liability to the contractor revolves around payment for services rendered, but additional situations may exist, where the company is liable if the contractor is injured in a company-owned facility.

A regular employee would be able to leverage Workman’s Compensation insurance – a product designed to limit and manage the company’s exposure to workplace injuries – but a contractor would not.

An employment agreement or employment contract spells out items that are in the company’s interest.  Any agreement with an independent contractor should include similar protections:

• Non-compete:  Can’t work for a competitor during, nor 6 months following the end or termination of the contract.
• Non-disclosure:  Can’t reveal any proprietary or confidential information to any third party.  The term of non-disclosure should be specified, and relevant to the value of proprietary information that the contractor might obtain.  For example, a client list or marketing strategy should be protected from disclosure for perhaps 1 year, but a proprietary algorithm or process should be protected for perhaps 10 years or even perpetuity.  The Colonel’s herb’s and spices are proprietary to this day.

Unlike an employee, a contractor should also agree to indemnify or insure the company and their customers against harm – usually through negligence or disclosure on the part of the contractor.

With a regular employee, the company has 100% liability for actions taken by the employee on behalf of the company.  The company directs the employees actions, and controls the employee financially, and with the threat of termination.  If an employee deletes a customer’s file, or discloses information, they can be terminated, and if their actions involve criminal behavior, they could be subject to prosecution, but the company maintains the liability with respect to its customers.

With a contractor, any protections for either party have to be specified within the contract, which needs to ensure that potential liability is appropriately maintained with the contractor.

As a contractor, most people don’t have extensive personal assets that could be recovered in a civil suit, in the event that the contractor creates or exposes a liability.  In addition, any individual can declare personal bankruptcy, which protects their home, vehicles, “tools of the trade” used to make money, retirement funds and certain other personal assets, which could severely limit the extent of what can be recovered.

As they say, you can’t get blood out of a turnip.

Further, some contractors do business as a Limited Liability Company (LLC) or Limited Liability Partnership (LLP), which separates the assets of their company from their personal assets.  In this situation, the contractor’s “company” might not have any assets that could be recovered in a civil suit, but any assets owned by the individual would be fully protected.  In this case, the contractor could (intentionally or otherwise) cause a problem that costs your company or its customers a lot of money, but they get to walk away without any financial impact – they simply fold their LLC / LLP and walk away, but they get to keep their bank accounts, speed boat, and collection of sports memorabilia.

For these reasons, contractors should be able to provide some form of liability protection – either a bond or insurance that would mitigate any direct liability to the company.

In order to gauge the level of liability protection required, the company needs to fully understand both the value and the impact due to down time or disclosure for all of its information assets, but specifically in the context of any damage that a contractor could cause.

Contractors should be vetted in order to protect the company and its customers:

• Criminal background check – theft, fraud, or embezzlement could all be significant red flags.  Someone with drug connections might be involved in money laundering.
• Financial background check – Although filing for bankruptcy isn’t a crime, a contractor is basically their own business.  Your company might prefer not to do business with a contractor who can’t manage their finances.  Bankruptcy can also be a way to shield themselves from financial debt or previous liability.
• As part of the background check process, look for association with LLCs or LLPs that have recently declared bankruptcy, which could be used to hide debt  or previous liability, and could be a red flag.
• Licenses and Accreditation – All professional / trade licenses and accreditation should be current.  Membership with any applicable trade associations should be current and in good standing.
• Insurance – If applicable, the contractor should be able to show proof of liability and other applicable forms of insurance.

 

A Tale of Three Contractors

Anecdote: The Missing Contractor

Consulting with a medium-sized company, we came across a network ID that we couldn’t validate as an active employee.  We finally tracked him down, and the “owning” manager indicated that he had been an employee at one point, but retired, and they had hired him back as a contractor.  The manager indicated that “he does work for us, from time to time” and that they still pull him in for “special projects”.

Three months went by, and during a user access review, we noted that the account hadn’t been active, as far as we can tell, for two years – dating back to the creation of the NT domain where the ID existed.  We reached out to the manager, who confirmed that the person “is still a contractor, and we still use his services from time to time”.

Through three more user access reviews, his last-login time had not changed, and the manager in question kept insisting that “we still use his services”.

After a year of this, I contacted accounting, who had no record of any invoices in the last 24 months.  In fact, they couldn’t determine the last invoice they had processed for this person.  I called the phone number listed under his user ID, and had an interesting conversation.  I introduced myself, and asked about his current business relationship with the company.  He indicated that, he HAD been employed there about four years ago, but that he had retired.  I asked about his ongoing assistance with special projects, and he was not aware of any such involvement, and refuted that he’d done any work at all, since retiring 4 years ago.  I thanked him for his time, and disabled his user ID.

The manager in question had always meant to bring him back as a contractor, and just never had!  When he left the company, the company was using Novell for directory and access management.  Someone had migrated his user ID to NT almost 3 years prior (at that point), and he had never used it!

Moral of the story:

We should have just disabled his access during the first user access review, and then deleted it after 90 days.

 

Anecdote: The Double-Dipping Contractor

One day, accounting contacted me, to see if we had a user ID for a person we’ll call “Steve”.  “Steve the contractor” had done some work for the company, but had exited nearly a year ago.  Fortunately, we had a record of terminating his access and receiving his laptop upon his exit date.

The accounting admin shared with me, that the company had been processing invoices for this person on a monthly basis, averaging about 20 hours per week.  She asked if there was any way he could be performing the services in question without network access.  My assertion was “no, but let’s talk to his manager.”

We called his manager in to a meeting to discuss this person’s status with the company, and review the invoices.  The manager related that he had done some work for his department, but they had terminated his contract about a year ago.  The manager also asserted that, without network access, there’s now way he could have been performing any kind of service for the company.

Apparently, when this guy got let go, he just decided that he’d keep billing the company for almost a year, for services he was never performing.

Moral of the story:

Accounting should have the cost center manager verify all invoices prior to paying them.

 

Anecdote: Free Laptop and Tech Support

I had recently implemented a policy requiring that, upon contacting the Help Desk, they should look the person up in Active Directory, and confirm their contractor ID or employee ID, or confirm some other relevant information, in order to verify their identity.

One of the Help Desk staff called me one afternoon, and asked to see me in my office, after which, he related to me that a guy showed up, asking for tech support for his laptop.  That’s not unusual – at that time we were closing 100 cases per day.  The support analyst had tried to find his user ID in Active Directory, and couldn’t find it, but the man, who we will call “Ralph”, indicated that he was a contractor for the company.

I went down to meet with “Ralph” – I instructed the Help Desk staff to go ahead and start working on his laptop, and pulled “Ralph” in to my office.  I told him that we couldn’t locate his network ID, but that we would go ahead and start working on fixing his issue – he and I could clear up the paperwork.  I called HR to see if they had any record of him, which they did not.  HR would have had a list of at least 7 years of employment records, and up to 3 years of contractor history, so we should have a record of him.

I asked who his manager is, and he told me a name I didn’t recognize.  I called HR back, to see if they had any record of the manager, and they indicated that the manager HAD been an employee, but had left the company about 4 years ago.  I called the current manager over that department, to see if they recognized “Ralph”.  The current manager related that “Ralph” had done some work for the company a long time ago, but didn’t think he had done any work recently.

This was getting interesting…

Again, I asked “Ralph” when he had worked for the company, and he confirmed that it had been a “been a while” but that he had a blanket contract with the company.

Taking another tact, I called the Support Analyst, to see how the laptop was progressing, but also to get his laptop’s model number and asset ID information.  While talking with him, the Support Analyst told me that the laptop was definitely ours, had client data on it, and seemed to have a bunch of software installed (more than average).  I called Accounting, to get the Fixed Asset information for the laptop.  It had been assigned, new, about a year ago, and the depreciation was assigned to the department for whom “Ralph” claimed he worked.

He was well dressed.  He had an access badge for the facility.  I asked “Ralph” how long he had his laptop, and he said, “about a year”.  So all of that matches.  How could he have a 1-year-old company-issued laptop if he hadn’t worked for us in 4 years?  At this point, I was rather suspicious.

I asked Ralph how he obtained his current laptop, and he responded that we (the company) had swapped out his old one when it died, about a year ago.  He had had the old one for about 3 years.  “Ralph” said that whenever he has a problem, he drops by, since we are close to his house, so that we can fix his laptop.  I asked “Ralph” the last time he had submitted an invoice, and he responded that it had “been a while” since he had submitted an invoice, and come to think of it, he should probably go through his records and submit one.

I gave him one more chance – I asked him who at the company he’d dealt with, in the last year, and he replied that he had dealt with my staff (the Help Desk) for tech support, and he had also needed a new cell phone, also probably about a year ago, so he had spoken to the office coordinator to get a new one.  I asked him, other than my staff and the office coordinator, who he had spoken to or worked with in the last year.  At this point he became a little flustered.

I used a little deception.  I asked to see his badge, since I was sure that would clear things up.  I pretended to type something in to my computer, while looking at the badge.  I asked if he had any other badges, and he said that was the only badge he had ever been issued.  I did NOT hand his badge back.

Instead, I told him that we would absolutely go ahead and fix his laptop, but that we were going to retain it, along with his badge, until he could prove his relationship to the company.  At this point, he got really mad.  I stood up, and informed him that I would be escorting him to the elevator.  He could go home, or wherever he wanted, and look through his documentation, and if he could produce a recent invoice, a contract, or any documentation linking him to the company, we’d be happy to return the laptop and submit the proper paperwork.

He shouted at me, “HOW am I supposed to do my work??”

To which I replied, “What work is that?”

“Well, I have several important clients waiting on my work, and I need the data that’s on my laptop!”

“Well, then you can tell me who you’re working with.  Tell me the Account Executive’s name, and I’ll call them, and clear this up.”

Silence.

I just-short-of-forcefully escorted him to the elevator, and repeated my assertion that he should find some documentation to clear this up.  He shouted at me a few more times, and left.

What happened?

After asking Accounting to do a deep dive, we DID finally find some evidence that he worked for the company as a contractor… about 4 years ago.  He had worked on two or three short-term assignments, over about a 6 month period of time, during which, he had been issued a company-owned laptop and cell phone.

I have no idea what was discussed between “Ralph” and the company at that point, but obviously he kept the laptop, cell phone, and badge, with some expectation that he was on retainer, “waiting” for new projects.  Looking at his laptop, he HAD been doing work, just not for us!  He had actually been doing work for a competitor, and had THEIR clients data on OUR laptop.  Whenever he needed tech support, he had a badge, so he just “showed up” and convinced whoever was at the desk to help him.  When his old laptop died, the Support Analyst assumed that because he had a company-issued laptop and a company-issued badge, that he was an employee, and assigned him a brand new laptop out of inventory.

Moral of the story

• Badge access reviews would have identified that “Ralph” was no longer associated with the company, and his badge should be revoked or disabled
• Any internal or external support desk should have a process in place for verifying the caller’s identity and association with the company as a current employee or contractor.
• All employees should receive basic training against social engineering.  If someone is a client or employee, they should have no problem being able to verify that fact.  If someone asks you to do something outside the ordinary, take steps to authenticate the person, and validate if you are authorized to perform the requested task.

 

Exit Process Checklist

These are items that should be conducted during the exit process – in other words, as the employee is leaving.  Some of these items will overlap the more thorough access termination checklist, but this is designed to be a guide for HR and IT, regarding actions that should be taken prior to the employee leaving the facility.

Company Assets

Upon exit, the employee should surrender company assets and equipment

• Laptop
• Corporate Card
• Cell Phone
• ID Badge
• Electronic Badge (if not the same as the ID badge)
• Office Keys
• Offsite Storage Keys
• Bin / Desk / File Drawer Keys
• VPN token
• Parking Pass

 

Logical Access

• Disable central directory access / user identity – LDAP or Active Directory
• Disable VPN credentials

 

 

Access Termination Checklist

Access to company resources should be immediately revoked, upon employment / contract termination.  Waiting leaves potentially critical systems exposed.

The best practice is:

• Immediately disable any system that is WITHOUT a mitigating control
• Systems WITH a mitigating control should be disabled within 24 hours
• Maintain a log of all forms of access, who terminated each, and on what date

I will attempt to enumerate as many forms of access that should be considered during termination, as possible.

 

 

Physical Controls

Facility

• Building keys should be surrendered
• Office keys should be surrendered
• Master keys should be surrendered

Storage

• Safe keys should be surrendered
• Safe combinations should be disclosed
• Safe combinations should be changed
• Filing cabinet / desk / bin keys should be surrendered
• Keys to shared filing areas should be surrendered
• Combinations to locked, shared filing areas should be changed
• Keys to offsite storage should be surrendered
• Combinations to locked, offsite storage should be changed
• Revoke access to Safe Deposit boxes with the bank, and update contact information.  Consider changing to a new safe deposit box, if ultra-sensitive.
• Keys to Safe Deposit boxes should be surrendered.

Electronic Access

• PINs should be set to explicitly deny.  If PIN pad authentication systems don’t support a “deny” list, the PINs should be deleted.
• Badges should be surrendered
• Badges should be explicitly disabled (Even if you have possession of a physical access device, it should be stored, disabled until reused)
• Biometrics signatures should be set to explicitly deny.  If biometric systems don’t support a “deny” list, or if local laws prevent long-term storage of biometric signatures due to privacy laws, signatures should be deleted.
  • Retina patterns
  • Finger prints
  • Palm signatures
  • Facial signatures
• Fobs and other tokens should be surrendered
• Fobs and other tokens should be explicitly disabled (don’t store active fobs or other tokens)
• Electronic safe PINs should be disclosed
• Electronic safe PINs should be changed
• Alarm System – PIN codes and biometrics should be set to explicitly deny, or if not feasible, deleted
• Alarm System – Shared or well-known access codes should be changed

 

Anecdote:  My OTHER Badge

Circumstances are what they are, and it’s never pleasant, but I had to let one of my Network Administrators go – not with cause, but due to down-sizing.

Let’s call him “Jay”

I called “Jay” in to a conference room with his HR rep, we let him go, it wasn’t pleasant, but he understood. 

“Jay” surrendered his keys and badge, signed his affirmation of company policy, including non-compete and non-disclosure.

I solemnly walked “Jay” to the elevator, and we parted amicably.

The next day, I saw “Jay” in the hallway visiting with a small group of people.

I walked up to him, and he greeted me, very friendly, and I asked him how he got in to a secure floor, of a secure facility.

He answered that he still had his “guest badge” in his car.

I gave him “the look”, and he handed it to me.

What happened?

“Jay” forgot his badge one day, and got a visitor badge.  He had called the office manager and asked them to assign all of his permissions to the guest badge, so that he could use it as a backup.

So, his “guest badge” had access to the facility as well as secured floors, and secured areas such as the SERVER ROOM, so that if he left his badge at home, he had a backup.

Moral of the story:

• Conduct regular badge access reviews.
• Ensure that all guest / visitor badges are accounted for.
• Ensure that each person only has ONE badge assignment.
• Disable all badges that can’t be accounted for.
• What if someone had broken in to “Jay’s” car and stolen the badge?  That person could use “Jay’s” personal information to figure out where he works, and based on his job description, a clever criminal could infer that his badge has special access to a secure room on a secure floor, in a secure facility, and use his badge to steal very expensive equipment.  DO NOT LEAVE YOUR BADGE IN YOUR CAR.

 

Anecdote:  My Badge Allowed It

In spite of camera systems, I always assign at least one person to keep an eye on the server room door, which was magnetically locked, and required special badge access to gain entry.

One day, I got a call, “you’d better get down here”

The analyst related that a regular employee, who we will call “Tim” just badged himself in to the server room, and brought a small group of people with him.

I entered the server room, just as “Tim” was finishing his “tour”.  I took “Tim” aside, and asked how he had gained access to the server room, obviously a sensitive and therefore RESTRICTED area.

His response?

“My badge had access, so I just assumed I was allowed.”

I informed “Tim” that if he ever entered this room again, unescorted by someone on my staff, he would be collecting unemployment.

What happened?

“Tim” had gotten a badge when he joined the company, several months ago.

The badge had formerly belonged to a member of my staff, who had quit.

“The people in charge of badges” gave “Tim” the ADMIN badge without checking to see where it had access.

After a few weeks at the company, “Tim” randomly swiped his badge on the server room door, and it let him in!

“Tim” just assumed he had been granted some special access to the server room.  “Tim” told his friends about his “special access”, and he decided, on his own authority, to give a “tour” for a group of unauthorized people, to the most sensitive room in the company.

Moral of the story:

• Upon recovery, badges should be disabled, and all access permissions should be removed.  Upon reassignment, the badge should be granted specific access.
• Regular access reviews would have caught an active badge assigned to a non-administrative employee, with access to a sensitive area.

 

Anecdote:  The Permanent Safe

I worked for a medium-sized company, whose employees were largely remote, and traveled frequently to customer sites.

We did so much business with the travel agency, that we had our own on-site travel office, with a few reps, and equipment.

After rolling out the self-service travel portal, our need for onsite help dramatically decreased, and eventually, we had just a single rep.

That person was relocated from a 6 person bull pen, so that the space could be reclaimed for other uses.

In the process, they moved the travel rep in to the office next to me – he dealt with confidential information and had access to sensitive documents, so it made sense.

They also moved a fairly bulky safe from the old travel area in to his office, and it was bolted to the floor such that you had to have access to the INSIDE of the safe to unbolt it from the floor.  The safe was used to store blank airline tickets and travel vouchers that had real monetary value, so the safe was a necessity.

Eventually, the one remaining travel rep moved back to his company’s offices, and vacated his office in our facility.

The office he was using sat empty for a while, but eventually got reassigned.  The first question from the new occupant:  “What is that thing in the corner, and how can I get rid of it?”

No one knew the safe combination.

The travel rep had left the company, and no one had any contact information for him.

The travel company did not know the safe combination.

As far as I know, that safe is still in that office, to this day.

Moral of the story:

Someone probably should have asked for that safe combination at some point… More important, no one knows it, and therefore it can’t be changed, and no one knows exactly what’s in there.  That was 7 years ago.

 

 

Vendor Accounts

Web Hosting / External Vendors

• Domain Registrar – revoke access, and update contact information
• DNS Provider – revoke access, and update contact information
• Certificate / Trust provider – revoke access, and update contact information
• Hosting provider – revoke access, and update contact information
• Cloud vendor – revoke access, and update contact information
• FTP / File sharing – revoke access, and update contact information
• Web Conferencing – revoke access, and update contact information.  Some web conferencing sites can be automatically configured to automatically log in to a customer’s system, for the purpose of providing “unattended” vendor support.  This is a special type of risk that must be explicitly managed.
• Instant Messenger – Make sure to revoke administrative access for hosted / federated instant messenger access.
• Hosted Fax Service – YES, Fax!  Many companies still use fax for purchase orders and signed contracts.  Make sure to revoke administrative access to hosted fax services.

Financial

• Bank access – revoke access, change authentication codewords, approval codes, or other credentials
• Payroll vendor – If your company uses a 3rd party payroll vendor, be sure to revoke access as appropriate, both for online viewing (regular employee access), as well as possible administrative access (e.g. if the employee was a payroll administrator).
• Cloud-based ERP – Disable the user account, and remove access to time entry and create expense reports.  Remove any possible administrative access, for example, the ability to approve time sheets and expense reports.
• Travel Portal – Disable access to company travel portal and company-owned travel website accounts, to prevent booking travel.
• Corporate Card – Company-issued credit card(s) should be surrendered, including any kind of voucher cards, parking vouchers, travel vouchers, gas cards, meal vouchers, and the like (example, cafeteria cards).  All company-issued payment instruments should be disabled, so that they can’t be stolen and reused.
• Supplier purchasing accounts – Disable access to all supplier accounts authorized to make purchases on behalf of the company, such as computer equipment, office supplies, or food.

 

Redirect Contact Information

• E-mail – Make sure e-mail is forwarded to the manager (or appropriate contact), and then go back and provide e-mail archives.  E-mail archives could include copies of contracts, agreements, fragments of discussions, and other information necessary to continuing a client relationship.
• Cell phone – You required the use of a company-issued cell phone, and confiscated it during the exit process.
  • Make sure the number hasn’t been forwarded to a personal number
  • Disable the employee’s access to the cell phone’s voicemail.  This might be via a PIN code entered after dialing the phone number, or perhaps via a website with the employee’s login.
  • Forward the cell number to an accountable manager or employee who can receive calls and answer client requests / concerns.
  • Provide manager access to the cell phone’s voice mail repository, to ensure continuity for customers who may have called and left a message.
• Desk Phone – In the age of IP telephony, make sure to disable IP (“station”) access by changing the employee’s PBX password.  Forward the employee’s DID (direct line) to a manager or designated employee who can address client / vendor requests and concerns.  Provide manager access to voicemail archives for continuity.
• Fax – YES, Fax is still in use, especially for purchase orders and contracts.  Some companies use online fax services, such as those provided by eFax, while others use a “fax gateway”, integrated with the company PBX.  In either case, make sure to disable access to the Fax mailbox (should be limited by disabling network access), and make sure to forward the fax number to a manager or designated employee.  Providing access to the employee’s fax mailbox ensures continuity — sometimes, SIGNED (executed) copies of contracts and other critical artifacts can be found in an employee’s fax archive.
• Instant Messaging – This one is counter-intuitive, but many companies use external or federated instant messaging to communicate with clients and vendors.  Your goal is to ensure that whoever reaches out via IM reaches a company employee who can assist them appropriately.  Change IM passwords, and forward IM access to the manager or an appropriate employee.

 

Data and Telecommunications

• Datacom and private circuit vendors (Wide-Area Networks) – Verizon, AT&T, and the like.  Revoke access and update contact information
• ISP (Internet Service Provider) – Revoke access and update contact information
• Telecom (Local telecom lines) – Revoke access and update contact information
• Telecom (Long distance lines) – Revoke access and update contact information.  Often, long distance and local access are managed by two different vendors, or might be two different accounts under the same vendor.  The goal is to make sure all telecom accounts are updated.
• PBX (Phone system) Vendor and Maintenance – Revoke access and update contact information.
• Cloud VoIP Vendor – Skype or other external communication channels
• Audio Conferencing – Disable personal conference bridge line
• Audio Conferencing – Consider changing well-known conference bridge information for regular meetings.

 

Warnings about Conferencing

Beware of regular conference calls

Let’s say “Steven”, the VP of Marketing for “QRS Corp”, exits the company in a less-than-amicable fashion.

As an employee of “QRS”, “Steven” had attended the Monday morning Marketing strategy call.

A few weeks later, “Steven” works for a competitor, “XYZ”.

Knowing that his old company, “QRS”, conducts Monday morning Marketing strategy calls at 9 AM, and knowing the conference bridge line, he buys a disposable cell phone, and surreptitiously dials in each week for several months.

He dials in at the top of the hour, puts his disposable phone on mute, and simply collects information.

“QRS” steadily loses clients, and can’t figure out how “XYZ” is always one step ahead.

Best Practice:  Establish a regular cycle, such as 60 or 90 days, where conference bridge information for recurring meetings (especially sensitive ones) will be changed.  Distribute the new conference bridge information to current participants, and cease using the old bridge information on a specified date.

If your audio conference vendor allows it, identify all attendees for sensitive meetings, and disconnect unidentified connections.

 

Web Conferencing

Beware information leakage and eavesdropping.

For the above, I did the following Google search:

site:webex.com  SomeCompany

“QLD” is Queensland, and “SOW” is Scope of Work (a definition of work to be performed for a client).

Each meeting has a 9-digit code and a password.

Every link in the list above includes the meeting number, and with VERY little social engineering, you could obtain the password.

If SomeCompany was YOUR company, an ex-employee or a competitor could easily gain access to a web conference, to view client presentations, sales and marketing strategies, design sessions, and the like.

Make all meetings “private” so that they can’t be browsed.

 

Anecdote:  PC Spending Spree

A friend of mine owned a small business.

After a few arguments with his office manager, “Stephanie”, who had worked for him for several years, he decided to let her go.

He generously gave “Stephanie” 4 weeks of severance, and stated that he’d be happy to provide her with a reference.

About 6 weeks later, he got an invoice for just under $10,000 from his computer supplier – $10,000 was his credit limit with that particular vendor.

Someone had ordered three computers, monitors, and other equipment on his account, and he got the bill two weeks later.

Looking at the invoice, the shipping address was his office address, but he certainly didn’t order the equipment, none of his employees ordered the equipment, and he didn’t receive any of the equipment.

Looking at the invoice history, “Stephanie” had logged in to the vendor’s website, about 4 weeks after she had been let go, since her account had never been disabled.  She knew the company’s credit limit was $10K, so she ordered just enough equipment to total just under that limit, including tax and shipping.  She knew no one would be at the office on Saturday, so she specified Saturday delivery.  The office itself was located inside a building whose front door lock utilized a common access code that never changed.  The delivery guy used the access code to enter the building and drop off the equipment in the hallway just outside of the owner’s office suite – the delivery guy didn’t have a master key, and since the building itself was locked, he assumed the boxes were secure. 

Checking the building’s surveillance footage, “Stephanie’s” husband entered the front door a short time after the delivery – everyone knows the common access code that never changes – and then proceeded to remove all of the boxes that had just been delivered, taking 3 trips in the process.  Very few people are in the building on a Saturday, and no one questioned him because he looked official, and had the front door access code.  A smile and a wave seals the deal.

I guess “Stephanie” thought she needed some additional severance!

Instead of an employment reference of her work history, professional skills, and loyal service, she got a criminal reference outlining her fraud and theft.

Moral of the story:

• The owner retrieved “Stephanie’s” office key upon termination, but the building’s common, never-changing access code presents a real problem.  Ideally, each user should have their own PIN code.  If the building is unwilling to spring for newer equipment that supports this feature, they should at least change the access code monthly, or ideally, weekly.
• “Stephanie’s” vendor account was still active 4 weeks after she was let go, allowing her to charge $10k in equipment on behalf of the company.  Having a detailed termination checklist would have resulted in her account being disabled.
  
• Dual authorization workflow would have necessitated the owner’s authorization to make the purchase.  He would have received an e-mail with a link to approve or deny the order, at which time he could have cancelled the order (and disabled “Stephanie’s” account).
• Two weeks is a long time to go, between the time the equipment was stolen, and the time the theft was noticed.  Luckily, the building kept plenty of tapes (back then, before digital, cameras recorded to VHS tapes), and were able to show who stole the equipment.  Reviewing a weekly report from the vendor would have caught the fake order, which could have been cancelled or intercepted.  Most suppliers are happy to offer this type of reporting, and can usually provide regular reports via e-mail.
• Buildings should have a secure “mail drop” area, where mail and other packages can be dropped off when the recipient is out of office, rather than allowing deliveries in common areas such as hallways.

 

Anecdote:  DNS-Jacked!

A start-up, Company “Z” had a well-established infrastructure, and a very secure network.  Hosting a small-but-growing, public-facing application, Company “Z” also hosted their own DNS.

During the post-Enron crash, Company “Z” lost some of its funding, and had to let some folks go.

Unfortunately, they didn’t remove one of their network administrators from having access to their domain registrar.

An external vendor account, the registrar is responsible for creating the “registration” record for a domain name, which includes basic information about the company who owns the domain name, and includes “pointers” to the DNS servers that “own” the domain.

Registrar –> Domain Registration –> DNS –> Website

Even though the Company “Z” DNS servers were highly-secure, the rogue admin was able to change the registration to point to another DNS server, bypassing the data center!  Without entering the building physically or logically, he was able to hijack the entire hosted application by simply logging in to a registrar account that had not been updated to remove his access!

He set up a fake web site, mocking “Company Z”, and used HIS DNS to point “www.CompanyZ.com” to the fake web site.

By the time calls started pouring in, it was already too late.  As a final insult, he had changed his password, and removed all other users’ access to the registrar’s website, necessitating a lengthy negotiation process with the registrar to prove rightful ownership of the account, and eventually unlock it.

Moral of the Story:

• Maintain an access inventory that includes EXTERNAL as well as internal accounts and access.
• Disable vendor accounts immediately upon termination.
• Conduct regular access reviews of EXTERNAL as well as internal accounts and access.

 

Logical Access

Remote Access

• VPN access should be disabled.   Each factor should be individually disabled:
  • If leveraging central identity, the directory account should be disabled, and the VPN access role should be removed.  For example, if there is a “VPN access” group, the user should be removed from the group, on top of being disabled.
  • Certificates should be revoked.
  • Tokens should be surrendered and also disabled.
  • Biometric signatures should be set to “deny”, or deleted if “deny access” is not possible.
• Dial-up modem access should be disabled.  Don’t laugh… some companies still use Remote Access Service (RAS) as an out-of band admin access strategy, in case their internet connection drops.
• Serial line / terminal access should be disabled.  Again, many companies have older mainframes, storage, and other systems that are directly connected to a phone line, allowing vendor or administrative access.  Best practice:
  • If your PBX can route an analog line, connect it to your PBX, then assign an extension.
  • The analog’s DID (Direct number) will now route to the PBX, necessitating 3 or 4 additional digits (the extension) to get to the mainframe or storage device.
  • The extension should be changed on a regular basis, such as monthly or quarterly.
  • A “war dialing” attacker  (dialing each number in a block of numbers, looking for a modem) will fail to find anything, because the analog line routes to the PBX attendant.
  • This is also an excellent way to prevent against Fax Spam.
• Managed VPN – Some companies utilize a cloud-based VPN service.  Employee access to VPN should be disabled immediately upon termination.
• Internet-facing Applications – Access to internet-facing applications should be revoked.  These might include:
  • E-mail
  • Sharepoint or E-Room
  • FTP / File sharing
  • ERP (time sheets, expense reports)
  • Corporate Intranet / Portal (prevent leakage of sensitive documents and information)
  • CRM (customer contact / management tool)
  • Support website (especially for software companies, you don’t want a former employee downloading full copies of your software)
• Web Conferencing – I already mentioned this, but to emphasize, some web conferencing systems can be configured for unattended access to specific systems for the purpose of providing vendor support.  A worst-case scenario, you don’t want a disgruntled support engineer to shut down your systems, nor your customers’ systems.

 

Control Systems

Everything is remotely-manageable these days.  Where feasible, all control systems should leverage central identity and access control, and management should be restricted to an authorized management console.

Control systems are the infrastructure to your infrastructure, and must be protected.

Here are some control system elements to review for access upon employee termination:

• Power control – you don’t want a rogue employee to shut down your servers and network gear!
• UPS Systems – Batteries buffer line and generator power in the event of a power failure.
• Air handlers / chillers / AC – computer equipment will rapidly overheat if the air handlers are shut off
• Telecom / datacom termination – Often called a “smart jack”, some datacom / telecom termination blocks can be remotely administered or monitored.
• Door Locks – You don’t want a former employee giving themselves access to your data center
• Alarm Systems – Some alarm systems can be remotely controlled and monitored
• Camera Systems – The epitome of hacking as depicted in TV and movies, a rogue employee can erase evidence or shut down camera systems in order to prevent leaving a trace.

There are many other “control” systems that might be embedded within your infrastructure – you should conduct a walk-through to identify these systems, and add them to the Access Inventory.

 

A Brief Word on RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a protocol designed specifically to manage and broker authentication and access control for edge devices.

LDAP authentication simply presents a user ID and password, and perhaps looks for specific group membership or other directory attributes.

In contrast, RADIUS brokers authentication, while implementing complex access control rules based on each “edge device”, or groups of edge devices, allowing multiple criteria based on WHERE a user connects, the connection SOURCE, or specific access methods, and back-end directory attributes.

RADIUS also provides information back to the edge device, to manage the connection, such as IP address information, VLAN information, or other parameters.

Where LDAP provides a simple “YES / NO”, RADIUS provides “yes/no” based on conditional parameters, and also returns connection-specific information that the edge device should use to manage the user.

 

Infrastructure Devices – Best Practices

• YOUR INTERNET ROUTER – That one goes in all caps, because it’s the MOST LIKELY to have unaudited, unauthorized-but-active user accounts.  Typically, your company’s internet router is accessible by your ISP or your own staff, or both!  Because it sits outside the firewall, you definitely don’t m,want your internet router to have access to the internal network for the purpose of authentication!  The best strategy is to define a very few system-level accounts, with extremely complex passwords, that are changed monthly or quarterly.  If an administrative user is terminated, the internet router passwords should be changed immediately.  Management access to your internet router should be limited to a few specified IP addresses.
• Firewalls – Firewalls should leverage RADIUS authentication.  Secondary authentication should exist for emergencies, using a local account that’s changed quarterly or more frequently.  Any employee with local access to a firewall should have their access removed upon termination.
• Secure Management Access – Routers, Switches, Firewalls, and other network devices should not have management points that are accessible from outside the company’s network, and ideally, there should be a “secure VLAN” with specified access for only a few IP addresses.
• Switches and Routers – Switches, Routers, and other network devices should be configured to leverage RADIUS authentication, which in turn, leverages a central directory-based identity.

 

List of Infrastructure Devices

• Internet Router – Change passwords for well-known accounts;  Remove local access
• Firewalls – Review / Remove access
• Routers – Review / Remove access
• Switches – Review / Remove access
• Intrusion Detection / Prevention Systems – Review / Remove access
• Network Tap / Bypass – Review / Remove access

 

Central Directory – Best Practices

• Before removing a user from the directory, or modifying a user object, it’s helpful to make a backup copy of the object, including all attributes (specifically, group membership and other entitlements) for three reasons.
  • First, assume that the person leaving will be replaced.  If “Bob” leaves or gets terminated, “Bob’s” boss might hire “Frank” a couple of weeks later, and ask for the same permissions and entitlements for “Frank”, that “Bob” had.  Having a complete record of “Bob’s” account makes that request a very simple one.
  • Second, “Bob” might come back.  It happens more often than you might think – contractors come and go (and often come back!), and sometimes, employees that leave or retire come back as contractors or consultants.
  • Third, “Bob’s” account might get accidentally corrupted or deleted.
• In addition to a basic LDAP command line query, there are many tools that will import and export either a single object or the entire directory to LDIF (LDAP file format), CSV (text), or XML.  Having the ability to rapidly back up or restore a single user, group, or the entire directory, quickly, will pay for itself, the first time someone accidentally deletes a user, or worse, deletes a group object.
• Recovering a corrupt directory, especially in Microsoft Active Directory, can be a long and complicated process, and depending on the situation (for example, in a disaster recovery event), starting with a blank directory and importing all of the objects might be faster.
• Using these tools, it’s a good idea to perform a “full export” on a nightly or weekly basis, to an administrative (locked down) share.  In addition to being able to quickly reference or restore an object, this is a good way to go back in time to look for changes, and can also be used as a baseline to audit for unauthorized changes, such as users who have been recently granted admin access.

 

Servers and Applications

• Central Directory User Object / Primary Identity
  • Make a backup of the user object – Useful as a point of reference
  • Disable the user object – Prevent authentication
  • Remove all entitlements and privileges (for example, group membership) – Prevent someone from enabling and using the user object
• Servers – Audit all servers that leverage local users
  • Document user access
  • Disable local user accounts
  • Revoke user privileges and entitlements
• Databases – For each database instance, document, disable the account, and remove access
• Applications – For each internal application, document, disable the account, and remove access

 

Task-specific Servers

Review, document, and revoke access to all of the following:

• SCADA Servers
• Task Servers
• Controller Servers
• Tape / Media Controllers
• PBX (Phone System)
• Time Clock System

 

Home Office Equipment

Home office assets should be shipped back to the company:

• Monitor
• Docking Station
• VoIP Phone
• Router
• Printer

 

Termination Checklist Template

Download the termination checklist template in ODF (Open Document Format) XLS (Microsoft Excel) or PDF (Portable Document Format):

ODF:  SampleTerminationChecklist.ods    (Opens in LibreOffice)

XLS:  SampleTerminationChecklist.xls   (Opens in Microsoft Excel)

PDF:  SampleTerminationChecklist.pdf   (Printable Version)

 

 

Summary

• Maintain an Access Inventory, and make sure to keep a current, corresponding Termination Checklist
• Failure to appropriately identify and maintain access to company-owned systems can result in unintended consequences, especially if a terminated employee still has access!
• Think outside the box, and make sure you identify internal, external, hosted, and physical forms of access.
• Manage contractors and contractor access in order to minimize risk to your business
• Use the provided template as a starting point for your own inventory / termination checklist.

If you think I’ve missed anything, or if you have an amusing story to share, please do so in the comments.