<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: On the other side of privilege removal in Career Discussions</title>
    <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41061#M3010</link>
    <description>&lt;P&gt;One of the ways I have handled this is to have a "check out sheet" that shows where I turned in my key fobs, badges, vpn tokens, etc. to. It was usually signed off by a responsible person in each area. BEFORE I turned it in to the final person I made a copy for my records so that I would have proof that I turned everything in.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hopefully your place had good policies around this. I do not allow generic accounts where I work except for in very rare cricumstances and have good procedures around them. If someone needs access they should have their own access (not talking about service accounts). If I have to perform an investigation I do not want people to use the "shared" account or shared password excuse.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;If you have concerns that someone might use your accounts because it is easier, then ensure you close any loopholes you can. If they are not willing to lock your account, lock it yourself through 3 failed login attempts. Only do this if it would not cause any problems. By doing this you should know that your account was locked at the time of departure. Unless of course if your account has some running process or other business process that it would cause havoc by locking it then don't do it, but then again they shouldn't be running the business this way. They would be able to unlock it of course, but then there should be a log of that happening, which you shouldn't have had access to anymore after you leave.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;In the end if they do not terminate your account and someone does continue to use it, there is not much you can do except to ensure that there are no remnants hanging around on your personal devices like an email login, ensure you delete any apps you installed on your phone for MFA/2FA or other business processes. Remove any vpn software used for company business if you had to work from home and used your own equipment (and yes I do realize this does happen).&amp;nbsp; Remove any favorites/bookmarks to company sites from your browsers. If you are still worried then keep good records of your termination/exit process. And I will add this caveat for others as I don't expect you would try this, but DO NOT try to login after you leave to check and see if they have terminated your accounts! I have heard of horror stories of ex-employees that thought they would check up and see if their former company was doing the right things in regards to terminated accounts and then have it go very badly for them when they brought up the failure to terminate their old accounts with their FORMER employer. At that point you are effectively hacking your former employer, which is frowned upon by the courts.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Luckily most places I have worked had a company issued smart id card that was tied to my login. Once I turned that in, I no longer had any access.&lt;/P&gt;</description>
    <pubDate>Wed, 25 Nov 2020 16:08:41 GMT</pubDate>
    <dc:creator>CISOScott</dc:creator>
    <dc:date>2020-11-25T16:08:41Z</dc:date>
    <item>
      <title>On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41023#M3002</link>
      <description>&lt;P&gt;&lt;SPAN&gt;I'm about to amicably leave my current employer.&amp;nbsp; My accounts are tied to several resources.&amp;nbsp; I would prefer to be locked out of &lt;STRONG&gt;everything&lt;/STRONG&gt; upon separation, but this is unrealistic.&amp;nbsp; I would be satisfied to be locked out of all external connectivity.&lt;BR /&gt;&lt;BR /&gt;&lt;/SPAN&gt;For reasons I cannot explain easily, I'm certain this will not occur on my request.&amp;nbsp; But I feel like I am entitled to the nonrepudiation which a lockout would provide.&amp;nbsp; Have any of you faced the desire of remaining blame-free upon separation?&amp;nbsp; How did you convey this importance when leaving&lt;SPAN&gt;?&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 24 Nov 2020 16:41:51 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41023#M3002</guid>
      <dc:creator>ericgeater</dc:creator>
      <dc:date>2020-11-24T16:41:51Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41028#M3004</link>
      <description>&lt;P&gt;Absolutely. In the places I've left amicably, I made sure that any and all of my privileged access was removed or transferred to others so that my accounts could be wiped completely.&lt;/P&gt;</description>
      <pubDate>Tue, 24 Nov 2020 18:13:53 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41028#M3004</guid>
      <dc:creator>Xenophore</dc:creator>
      <dc:date>2020-11-24T18:13:53Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41030#M3005</link>
      <description>Change the passwords to a random string that you don't keep a record of, and let them know that.</description>
      <pubDate>Tue, 24 Nov 2020 18:34:39 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41030#M3005</guid>
      <dc:creator>gidyn</dc:creator>
      <dc:date>2020-11-24T18:34:39Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41031#M3006</link>
      <description>&lt;P&gt;I will not be changing anything any more.&amp;nbsp; It is not my responsibility to change anything any more.&lt;/P&gt;</description>
      <pubDate>Tue, 24 Nov 2020 18:37:07 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41031#M3006</guid>
      <dc:creator>ericgeater</dc:creator>
      <dc:date>2020-11-24T18:37:07Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41039#M3007</link>
      <description>&lt;P&gt;&amp;nbsp;Double edge sword this one.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;If it is amicable do you have reason to believe they will come after you?&amp;nbsp; If, ask them for a document stating that you are not responsible as you have notified them of all the accounts and that you have requested all remote access be terminated (That is of course unless one of these accounts has remote access).&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;This is why I tell my staff to create generic accounts for all application(S) or re-use the generic account.&amp;nbsp; Also that the password should be set by the admins (Not you) and put into a firecall process (the password is only used for emergencies and immediately changed after use).&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;However, if you believe things will be okay (have they been hacked, can they be hacked, are they in a target group), then cross your fingers nothing happens between your leaving and the next time the password is reset (huge assumption that there is a policy to change all passwords in x days).&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Enjoy the new job and try not to worry about what may be.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;d&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 24 Nov 2020 19:20:00 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41039#M3007</guid>
      <dc:creator>dcontesti</dc:creator>
      <dc:date>2020-11-24T19:20:00Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41056#M3009</link>
      <description>&lt;P&gt;I encountered a similar issue, with having to ensure all my accounts were removed on my last day with an employer and all my IT equipment and documentation returned.&amp;nbsp; Now it was supposed to be my line managers responsibility, but I ended up planning doing it myself so I'd have an audit trail of the actions I'd taken and positive confirmation.&amp;nbsp;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 25 Nov 2020 09:42:41 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41056#M3009</guid>
      <dc:creator>Steve-Wilme</dc:creator>
      <dc:date>2020-11-25T09:42:41Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41061#M3010</link>
      <description>&lt;P&gt;One of the ways I have handled this is to have a "check out sheet" that shows where I turned in my key fobs, badges, vpn tokens, etc. to. It was usually signed off by a responsible person in each area. BEFORE I turned it in to the final person I made a copy for my records so that I would have proof that I turned everything in.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hopefully your place had good policies around this. I do not allow generic accounts where I work except for in very rare cricumstances and have good procedures around them. If someone needs access they should have their own access (not talking about service accounts). If I have to perform an investigation I do not want people to use the "shared" account or shared password excuse.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;If you have concerns that someone might use your accounts because it is easier, then ensure you close any loopholes you can. If they are not willing to lock your account, lock it yourself through 3 failed login attempts. Only do this if it would not cause any problems. By doing this you should know that your account was locked at the time of departure. Unless of course if your account has some running process or other business process that it would cause havoc by locking it then don't do it, but then again they shouldn't be running the business this way. They would be able to unlock it of course, but then there should be a log of that happening, which you shouldn't have had access to anymore after you leave.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;In the end if they do not terminate your account and someone does continue to use it, there is not much you can do except to ensure that there are no remnants hanging around on your personal devices like an email login, ensure you delete any apps you installed on your phone for MFA/2FA or other business processes. Remove any vpn software used for company business if you had to work from home and used your own equipment (and yes I do realize this does happen).&amp;nbsp; Remove any favorites/bookmarks to company sites from your browsers. If you are still worried then keep good records of your termination/exit process. And I will add this caveat for others as I don't expect you would try this, but DO NOT try to login after you leave to check and see if they have terminated your accounts! I have heard of horror stories of ex-employees that thought they would check up and see if their former company was doing the right things in regards to terminated accounts and then have it go very badly for them when they brought up the failure to terminate their old accounts with their FORMER employer. At that point you are effectively hacking your former employer, which is frowned upon by the courts.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Luckily most places I have worked had a company issued smart id card that was tied to my login. Once I turned that in, I no longer had any access.&lt;/P&gt;</description>
      <pubDate>Wed, 25 Nov 2020 16:08:41 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41061#M3010</guid>
      <dc:creator>CISOScott</dc:creator>
      <dc:date>2020-11-25T16:08:41Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41077#M3011</link>
      <description>&lt;P&gt;&lt;a href="https://community.isc2.org/t5/user/viewprofilepage/user-id/1602421967"&gt;@CISOScott&lt;/a&gt;&amp;nbsp;Yes the organisation had good policies/practices around leavers, including a checklist to be signed off by line managers when a member of staff left, because I'd put them in place as Security Manager, however the CIO had told the rest of IT and HR to ignore established practice.&amp;nbsp;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 26 Nov 2020 09:52:38 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41077#M3011</guid>
      <dc:creator>Steve-Wilme</dc:creator>
      <dc:date>2020-11-26T09:52:38Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41108#M3012</link>
      <description>&lt;P&gt;Any time an executive instructed me not to follow policies, I asked for it in writing. If they denied it to me in writing then I kept up the established process. I also followed it up with a nicely worded email that asked for clarification of the issue if they felt the policy should not be followed. If they feel strong enough to avoid doing it, then they should be able to put it in writing. I also tried to understand the "Why" behind why they didn't want to follow procedures so I could see if it was something I could help remedy.&lt;/P&gt;</description>
      <pubDate>Mon, 30 Nov 2020 14:25:45 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41108#M3012</guid>
      <dc:creator>CISOScott</dc:creator>
      <dc:date>2020-11-30T14:25:45Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41134#M3013</link>
      <description>&amp;gt; CISOScott (Community Champion) posted a new reply in Career on 11-30-2020 09:25 AM in the (ISC)Â² Community :&lt;BR /&gt;&lt;BR /&gt;&amp;gt; I also followed it up with a nicely worded email that&lt;BR /&gt;&amp;gt; asked for clarification of the issue if they felt the policy should not be&lt;BR /&gt;&amp;gt; followed.&lt;BR /&gt;&lt;BR /&gt;*Any* policy should have a policy (and a procedure) for documenting any&lt;BR /&gt;deviations from the policy.&lt;BR /&gt;&lt;BR /&gt;====================== (quote inserted randomly by Pegasus Mailer)&lt;BR /&gt;rslade@gmail.com rmslade@outlook.com rslade@computercrime.org&lt;BR /&gt;Science is an edged tool, with which men play like children, and&lt;BR /&gt;cut their own fingers. - Arthur Eddington&lt;BR /&gt;victoria.tc.ca/techrev/rms.htm &lt;A href="http://twitter.com/rslade" target="_blank"&gt;http://twitter.com/rslade&lt;/A&gt;&lt;BR /&gt;&lt;A href="http://blogs.securiteam.com/index.php/archives/author/p1/" target="_blank"&gt;http://blogs.securiteam.com/index.php/archives/author/p1/&lt;/A&gt;&lt;BR /&gt;&lt;A href="https://community.isc2.org/t5/forums/recentpostspage/user-id/1324864413" target="_blank"&gt;https://community.isc2.org/t5/forums/recentpostspage/user-id/1324864413&lt;/A&gt;</description>
      <pubDate>Mon, 30 Nov 2020 18:56:15 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41134#M3013</guid>
      <dc:creator>rslade</dc:creator>
      <dc:date>2020-11-30T18:56:15Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41149#M3014</link>
      <description>&lt;P&gt;All those things were in place, however our new CIO took the unfortunate view that everything to do with security was "absolutely delusional" and could therefore simply be ignored; a bit like staying within the IT budget (also ignored) and regulatory compliance (also ignored).&amp;nbsp; When you get to the point where half the IT department leaves in a 3 month period and isn't replaced due to a CIO, the problem probably is beyond fixing.&lt;/P&gt;</description>
      <pubDate>Tue, 01 Dec 2020 08:47:21 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41149#M3014</guid>
      <dc:creator>Steve-Wilme</dc:creator>
      <dc:date>2020-12-01T08:47:21Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41153#M3015</link>
      <description>&lt;P&gt;When you have a toxic CIO like that, you need to cover your rear. That is why I like to send emails that "recap our earlier conversation"&amp;nbsp; to make sure I "understood your intent".&amp;nbsp; Then if they try to throw it back in your face I can refer to our previous conversation that "I emailed you about". As the system owner the CIO has every right to "accept the risk" of any decision they want to make and as the CISO I have the right and responsibility to ensure that any "risk they are willing to accept" is fully documented in a risk acceptance document. It is also my duty to fully inform the CIO/Senior management of the risks of their decisions and if they (CIO) or senior management is willing to accept the known risks I have presented to them, I document it and get them to sign it. I make sure I have emailed it to them to sign and return to me.&amp;nbsp;If they refuse to sign it, I send a couple of follow up emails so that I have it documented that I made every reasonable attempt to get them to sign it. That way I am as protected as I can be.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;If senior management is OK with a toxic CIO, I then ensure my resume is up to date and I start looking for jobs with intense focus.&lt;/P&gt;</description>
      <pubDate>Thu, 03 Dec 2020 11:58:20 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41153#M3015</guid>
      <dc:creator>CISOScott</dc:creator>
      <dc:date>2020-12-03T11:58:20Z</dc:date>
    </item>
    <item>
      <title>Re: On the other side of privilege removal</title>
      <link>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41182#M3016</link>
      <description>&lt;P&gt;After 9 months of doing as you suggested I took the latter option and found another job.&amp;nbsp; Once you've lost a critical mass of staff you're not going to make headway anyhow.&lt;/P&gt;</description>
      <pubDate>Wed, 02 Dec 2020 13:47:22 GMT</pubDate>
      <guid>https://community.isc2.org/t5/Career-Discussions/On-the-other-side-of-privilege-removal/m-p/41182#M3016</guid>
      <dc:creator>Steve-Wilme</dc:creator>
      <dc:date>2020-12-02T13:47:22Z</dc:date>
    </item>
  </channel>
</rss>

