Altering Termination Policy 1916



  • Not sure where this falls forum wise, if a mod sees fit, please move this to the more appropriate forum.%0AI work for a Fortune 1000 company and we currently run Oracle e-Business, with versions that vary from 10.7 all the way to the latest 11.5.10 (Db version varies as well, from 8i up to 10g). We have nearly 2,500 active users spread-out over 9 instances … 8 of which are production and 1 is currently being used for e-Procurement. Don’t ask me why my company decided to spin so many instances, they’re retarded, but this is my environment and it’s not going to change. :lol: :roll: %0ACurrently our termination policy is as follows:%0A1.) Report from payroll (off some DB) delivers HR the terminations for each day automatically.%0A2.) This terminated personnel report is sent to myself and others and it’s our responsibility to make sure each person has had their access terminated. %0AAs you can see, this creates a considerable amount of work for us … checking each of the 8-9 instances to see if the x-employee had access. Overall, typically 50% of terminated employees have access to some Oracle instance.%0AThat being said, our Director of IT recently decided that controller’s of each division (which, ironically has their own instance.) should be held accountable for making sure their x-employees are terminated from Oracle using an Access Form that we’ve created in a Lotus Notes DB (this DB is used to initially set-up these employees with Oracle access when they’re hired).%0AIt’s been 4 months and I’ve audited how successful our controller’s have been, but unfortunately, we have a 50% fail rate.%0AI’m interested to hear any suggestions? What occurs within your organization(s) that you work for or have audited?%0AI figured there must be a way to streamline the process …%0A - Employee is fired%0A - Something checks which instance the employee has access to%0A - An e-mail is automatically sent to his superior and informs him/her to fill-out an Access Form so the employees access to Oracle is revoked.%0A - Form routed to those parties to which it applies%0A - Users Oracle rights revoked%0AA paper trail exists for audit and the amount of work for all parties is minimized.%0AI’m very interested in what you have to say.%0AThis year, after I was hired, I had to go through an Excel list of 6 months worth of terminated employees (500+) … just to verify they have been removed from the system so they wouldn’t show-up in an external auditors sample.



  • Bump.
    Aw, c’mon guys, I know you have ideas.
    Here is the cliffs notes version …
    How does your organization or organizations that you audit … handle the removal of employees from IT systems once they’ve been terminated?



  • Hi - I’m thinking the move from a centralized approach to a decentralized one was a ‘step back’ as you loose control by spreading out the responsibilities to several areas. Some potential issues include:

    1. These individuals may or may not understand the process
    2. They may be in a remote location where there’s less emphasis on SOX and it may not be viewed as important
      An important task like employee terminations needs prompt attention and must be performed on the day of the employee leaving the company. For example, if a security admin is terminated without the proper attention, they can login, setup another account, and come back later potentially with their newly created account (i.e., although this should be very rare in the real world).
      Some design ideas include:
    3. Centralized design for all terminations to flow to a single area of responsibility
    4. Usually the security department handles these with a high priority as soon as an event occurs
    5. Ensure the workflow includes direct notifications by HR (email plus verbal in high profile cases, e.g., Executive, System Admin, etc)
    6. Remove email, network, and VPN access immediately
    7. Remove Oracle security permissions promptly (esp. write access)
    8. Maintain a history of terminated employees (in accordance to SOX requirements and the 7 years of email and other history needed)


  • Hi - I’m thinking the move from a centralized approach to a decentralized one was a ‘step back’ as you loose control by spreading out the responsibilities to several areas. Some potential issues include:

    1. These individuals may or may not understand the process
    2. They may be in a remote location where there’s less emphasis on SOX and it may not be viewed as important
      An important task like employee terminations needs prompt attention and must be performed on the day of the employee leaving the company. For example, if a security admin is terminated without the proper attention, they can login, setup another account, and come back later potentially with their newly created account (i.e., although this should be very rare in the real world).
      Some design ideas include:
    3. Centralized design for all terminations to flow to a single area of responsibility
    4. Usually the security department handles these with a high priority as soon as an event occurs
    5. Ensure the workflow includes direct notifications by HR (email plus verbal in high profile cases, e.g., Executive, System Admin, etc)
    6. Remove email, network, and VPN access immediately
    7. Remove Oracle security permissions promptly (esp. write access)
    8. Maintain a history of terminated employees (in accordance to SOX requirements and the 7 years of email and other history needed)
      Hi Harry,

    Thanks for your help / opinion. I never saw the way we handle terminations as a ‘step back’, but you make a good point. Additionally, I also agree that terminations should be handled more promptly.
    Since I’m a new employee, I’m hoping to develop something on my own to put me in the limelight. The problem is, the company is most likely NOT willing to allocate much funds to this project … because when it all boils down, I can get a term list daily and remove each user myself … it’s effective and occurs the day of the termination, but it sacrifices my time I could be spending else where.
    That being said and considering my current environment, I’m having some trouble conceptualizing a new process … I’ll have to give it more serious thought.
    edit: I just discovered we use ADP’s Enterprise System … has some good risk management abilities, I might use this to track employee access and such.



  • Does anyone have experience with this … and has used a framework or guideline as reference? Looking through COBIT 4.0 now.
    On another note, what type of repercussions can occur if terminated employees have access weeks after termination? Is this outline in SOX 404?



  • On another note, what type of repercussions can occur if terminated employees have access weeks after termination?
    While most ex-employees would probably never check access again, a few folks might become curious and could potentially try to login (e.g., if they had VPN software and access on their home PCs).
    Below are a couple of scenarios that are most likely rare in the real world. They are examples of what might happen with open remote access rights after termination:

    1. One of top folks in Sales who had existing VPN remote access, decides to move to another company. He had a great list of existing customers and forgot to take this with him on the way out 8O 8O 8O He then decides to check to see if his VPN account is still operative. To his surprise it is, and he quickly accesses the system to create a contact list of his former customers, that he will call upon as prospects in the new company. And as a top salesman, the former employer would start to loose business 😞
    2. A system or network ADMIN finds the system is still open and creates a user account, but with more of a System Process name than a user name and with ADMIN rights and even a non-expiring password. He can sereptiously visit whenever he likes until this backdoor is discovered.
      I could keep going here and even include examples of fraud … Failure to immediately terminate access rights for prior employees is a major IT audit concern .
      Is this outline in SOX 404?
      Removing or suspending system access for terminated employees is definitely a major checklist item of what auditors would look for in any SOX 404 (or any other non-SOX related review).
      Please cut/paste to browser and add ‘www’
      google.com/search?hl=en-and-q=sox 404 employee terminations


  • Thanks again Harry.



  • If employees use a single ID to access all the instances he has privileges in, then here is something off the top of my head.

    1. Once you receive the notification about termination of an employee instead of removal of privileges you change the account password (as an admin you must be able to do this) or disable the account. The employee will have privileges intact in instances but he can’t use the userid. Make a list of these user IDs and maintain it for a period. (List-1)
      By doing this the main risk of someone using the account even when they are terminated is reduced. The problem is that when the auditors’ pulls out a report he can still see the user ID of a terminated emp with all the privileges. Do this:
    2. Periodically review the userids in each instance and compare them with the list -1 and remove the userid privileges from instances. In between the reviews the userids/privileges can exist but they are disabled.
      You thus won’t have to go to each instance for each terminated userid everyday but you have to sit one time for each instance periodically. Of course this is possible only when one user has one userId for all instances. This is helpful also when you have good employee turnover.
      Just my two cents. Hope this helps.
      Calvin


  • Once you receive the notification about termination of an employee instead of removal of privileges you change the account password (as an admin you must be able to do this) or disable the account …
    Excellent suggestions … I also favor to suspend (lock) the account and not to delete all the access rights immediately. I definitely like the secondary control of changing the password 🙂
    One good reason for suspending rather than deleting access rights, is we’ve seen cases where an employee has changed their mind, and their former manager values them and allows them to return back to work. Also, as their replacement comes onboard, you could potentially model some of the access rights if needed.
    Using reporting tools, you can then get a list of terminated employees after ‘x’ number of days and delete all associated rights as time permits for the security team.
    It’s beneficial to compose an IT Termination procedure - This needs to be documented as a standard for the security team or admins performing the process, so they check everywhere (e.g., using a lengthy checklist in our case).



  • Once you receive the notification about termination of an employee instead of removal of privileges you change the account password (as an admin you must be able to do this) or disable the account …
    Excellent suggestions … I also favor to suspend (lock) the account and not to delete all the access rights immediately. I definitely like the secondary control of changing the password 🙂
    One good reason for suspending rather than deleting access rights, is we’ve seen cases where an employee has changed their mind, and their former manager values them and allows them to return back to work. Also, as their replacement comes onboard, you could potentially model some of the access rights if needed.
    Using reporting tools, you can then get a list of terminated employees after ‘x’ number of days and delete all associated rights as time permits for the security team.
    It’s beneficial to compose an IT Termination procedure - This needs to be documented as a standard for the security team or admins performing the process, so they check everywhere (e.g., using a lengthy checklist in our case).
    Thanks again for the information guys. When I said ‘terminate access’ I meant I end-date the former employees used ID and responsibilities.
    I spoke to my manager and director today, not much luck on re-engineering the termination process (or lack thereof) … I work for a manufacturing company so they’re not too interested in IT in general. As it stands today, I’ve been instructed to remove users from IT systems when I receive notice from payroll. It’s not the most efficient way, but it works.


Log in to reply