Inactive - but disabled user accounts?

Hello all-

My brain just spun-locked on this one. We are auditing a group that has over 9,000 accounts, but over 6,000 of those accounts are labeled "inactive" and are disabled - no login/shell access. Now going over our User Account Policies and Standards we find that this is a still no-no - as avenues - such as Social Engineering can be deployed to activate those accounts again, among other avenues of attack; however IT is battling back with some of the following reasons:

1. Project data needs to be kept under project IDs per project retention requirements
2. Expired user is still an active employee and have not indicated that they want account removed
3. Samba accounts are locked upon setup
4. Default System accounts are required but can be locked

I can see their logic for some of the above - but 6,000+ plus accounts - more than double that of their active accounts? Before I go off and club them with the policies and standards, yet again, I wanted to get some opinions from the ever-wise group me'ah. Thoughts please.

Thank you!

This is really a business decision.

If the clients can provide a business case to show why these accounts need to be retained then you can assess that business case against the perceived risks of leaving those accounts there but disabled also if they can document the reasons maybe you can provide them with another alternative rather then leaving 6000 accounts active, and it might give you a better idea of what the requirements actually are and what is driving the requirements.

We leave accounts in a disabled state for a set period after a user leaves just in-case we need to access to some document(s) they have created and locked down to just them. I can't remember a time we have had to use this (and there is other ways to do it anyway) but it is a precaution we take. We see the risk of social engineering to gain access to disabled accounts to be quite low in our environment but yours may be completely different.

So basically:

Depends on your risk assessment of disabled accounts V's business case for leaving them disabled

Is the process for reactivating an account more or less secure than the process for creating a new account? If more secure (as is often the case...) don't worr about it.

1. Project data needs to be kept under project IDs per project retention requirements
Projects must be transferred to a new owner. It makes no sense to have an active project that isn't owned by anyone.

Quote:

---

2. Expired user is still an active employee and have not indicated that they want account removed

---

Why would current employees have disabled accounts?

Quote:

---

3. Samba accounts are locked upon setup

---

Even if this were true, a one time spring cleaning might be in order, if hat requires a reinitialization, so be it.

Quote:

---

4. Default System accounts are required but can be locked

---

An account that isn't tied to a shell, but it still used should not be counted as a disabled account. If the account is disabled, no reason to keep it.

Back up all the dead user accounts and dump them. 6000 is excessive and just asking for problems.

cheers,

catch

We have current employees with disabled user accounts because if a user is going on leave for longer then 12 weeks we make them go through the separation procedures which includes disabling their account.

I don't really understand:
"1. Project data needs to be kept under project IDs per project retention requirements"
To me a project document shouldn't really be under a personal ID it should be under a project role. For example if I am project manager and then I move on and catch becomes project manager then catch is really the owner of any documents created as part of that project manager role.

I don't think the Security risks are real significant of leaving them there but from a management perspective surely these a pain in the proverbial.

I'm with catch, unless there is a significant business reason to keep an account - get rid of it but as I said before only you and your clients can really decide if they are needed for the functionality of your organisation.

cabby80 and catch - thanks much for the responses. My brain spun-unlocked after reading your replies - ok - so I and my fellow auditor are not going nuts - it is sound advice that you both provide and confirms what we believe, along with the policy and standards governing this area. We will review the policy and standards with the client and impress upon them, based on risk to the organization versus what they need to keep, that any accounts that can be removed, remove them; of course after backing them up.

Additionally, and TH13 has mentioned this to me before, along with catch in other threads - but conducting a risk assessment - we do it every year in auditing - and review/revise it six months into that year, however I am wondering if IT is doing a risk assessment? Catch/cabby80 - have you seen IT do risks assessements? Should they? It seems logical that they should...

No organization should ever be trusted to manage its own risks. Risk assessments must be done by the InfoSec department which may be under the InfoSec department (CISO) or security/risk management department (CSO).

Otherwise you have a self governening situation... kind of like removing the legal system in this country and putting everyone on the honor system.

cheers,

catch

It would be great if the IT areas did regular risk assessments, unfortunately though it is just not going to happen, that is what they bring in the auditors to do.

In a previous life I was an IT auditor for an accounting firm and that was our standard work, risk reviews basically.
Generally IT areas see this as something that they don't have time for (and not a priority). The other thing is that by bringing in someone external (from the IT department - it may be external company or an area of the org responsible for auditing) you will get a much more indepenent review of the risks. At times the IT department have an interest in understating risks (or they may not fully understand them) because the higher the risk generally the more work there is for IT to mitigate it.

Now in my IT Security role what we do is for new systems we get the business owners (corporate clients with assistance from IT developers and Admins) to put together a threat risk assessment of the system. We then get them to send it to us in IT security where we go over it to make sure that (in our opinion) it is complete and the ratings are accurate (and we suggest additional controls where applicable). If we are happy with it and there are no glaring holes we then forward it back to the business owners (corporate clients) for signoff because as the "owners" of the system and its data it is really up to them to sign off that they are aware of the residual risks and are happy to accept them.

As for existing systems rather then doing formal regular risk reviews we do more a compliance checking program. We (IT security) have set of "risks" that we want to cover off as part of our control compliance testing and we run that program year round on a schedule - basically this is an audit program.
The other control that helps is that we have a VERY stringent change management process where most changes to the IT environment need to go through our change management comittee where IT Security have a representative. EVERY single change doesn't need to go through change management comittee approval there are standing authorisations (which are approved by Security) that alot of changes can be made under.

Quote:

---

Originally posted here by genXer
I am wondering if IT is doing a risk assessment? Catch/cabby80 - have you seen IT do risks assessements? Should they? It seems logical that they should...

---

Not impossible, just hard to implement. I work in a large organisation that is currently looking at a self assessment program for certain aspects of ICT operations. However, the program also comes with well developed policy and is supplemented by assessment and auditing by a governing security authority. So realistically a hybrib between the two.

Quote:

---

No organization should ever be trusted to manage its own risks. Risk assessments must be done by the InfoSec department which may be under the InfoSec department (CISO) or security/risk management department (CSO).

Otherwise you have a self governening situation... kind of like removing the legal system in this country and putting everyone on the honor system.

---

catch - agreed - however we would presume that there is such a department. Well here there is, or something like it called Corporate Security and also IT Security. However, IT Security is still reporting through IT here and Corporate Security, unfortunately, does not know what IT seems to be doing for the most part - we are working to change that so we can work better to protect our assets; and again unfortunately, I believe politics is coming into play as some responsibilities may be consolidated or certain empires hindered in their growth.

cabby80 - yes - it seems those are the lines we should be going against - as mentioned above, that is still being "battled" - part of this corporate culture in IT it seems.

TechGrunt - yes - just takes a lot of time, "selling" the idea of risk assessments - if not doing them in IT Security - at least listening to Auditing.

So thanks again for the input, and I feel we in Auditing are on the right track with risk assessments, we need to ensure we are covering all pertinent areas for coverage and then working/communicating our assessments with IT and Corporate Security.

Quote:

---

catch - agreed - however we would presume that there is such a department. Well here there is, or something like it called Corporate Security and also IT Security. However, IT Security is still reporting through IT here and Corporate Security, unfortunately, does not know what IT seems to be doing for the most part - we are working to change that so we can work better to protect our assets; and again unfortunately, I believe politics is coming into play as some responsibilities may be consolidated or certain empires hindered in their growth.

---

I have seen this arrangement go back and forth since Rome formed its first legion. IT wants to have IT security because they are afraid (with some justification) that security pukes will interfere with getting work done and security wants IT security (with some justification) to ensure that there actually is some IT security. It can work either way, but my experience is that the temptation to yield to users is often too strong in the production environment to allow for adequate security. It seems to be a fashion thing, sort of like wide ties. It might be useful to discuss experiences in one model or the other, upsides, downsides, etc.

My Experiences....

Both Physical and IT Security Operate within the IT divison, reporting directly to the division head rather then within the infrastructure or applications branches.

Originally Physical (corporate) security was part of a different divison - corporate division but they were brought together because of the reasons Gandalf mentioned about having the two security teams together so they can use each others knowledge.

This works well for us, we are independent enough of the IT branches to be considered independent but we are close enough to have our fingers of the pulse of what is going on and what the IT areas are doing (I am in IT Security) which I think is important.

My organisation is small enough to not have an audit/compliance department which IMHO is a good thing because IT Security would logically go in that bucket which would keep us away from IT and make it harder for us to know what is going on.

Quote:

---

Originally posted here by cabby80

This works well for us, we are independent enough of the IT branches to be considered independent but we are close enough to have our fingers of the pulse of what is going on and what the IT areas are doing (I am in IT Security) which I think is important.

---

Cabby80 has a good point here. I think independance is important. You need to be separate from the business process, because ultimately security is something that will detract from business. Often there is a good reason for it, and often if it wasn't there, the business would suffer anyway

Quote:

---

Originally posted here by GandalfTheGray[/i]

It can work either way, but my experience is that the temptation to yield to users is often too strong in the production environment to allow for adequate security. It seems to be a fashion thing, sort of like wide ties. It might be useful to discuss experiences in one model or the other, upsides, downsides, etc.

---

Often cases I find this is a pendulum swing. If an incident occurs, there is suddenly a renewed interest in security and budgets go up. If there hasn't been an incident (which you could say means that security is doing its job) it is something that is suddenly becomes a burden and a likely cost saving area.

My $0.02 on the matter anyway. Just about to move into the security arena in my organisation. Be careful what you wish for comes to mind!

TG

To return to the original question quickly the problem is more one of procedure than anything else. As is often the case in large oragnisations there is a procedure for the creation of user accounts but there is none for the deleation of accounts when the employee leaves. The IT departement is right in saying that for them the person is still in the company as they have not recieved a demand to delete the account. Of course it is up to the IT departement in to decide on how is wants to managed its user base. As for the reasons giving for keeping the accounts that just translates into :
"We are too lazy to tidy up our mess."
I have seen in a couple of places a risk managment departement. Normally it deals with all the different types of security risks in the Corporation from IT security to phsyical risks to fraud. Normally it is not only independant but also placed on a higher level on the organigrame than most other departements.