Re: Opinions about lack of security control

Deyan · ‎01-11-2018

Hello Sec Pros,

I could really use someone's input around this. I am trying to craft a risk statement around lack of a security control for a system. The system processes sensitive data. After review of the system I identified that it lacks specific security control - it does not have a mechanism or the capability to automatically disable or notify about accounts that have been inactive for certain period of time. I am really having hard time imagining a scenario where a risk could materialize from the lack of this control. The accounts' passwords expire at a certain period of time which partially compensates the lack of this control however I..... I guess it all comes down to what can be the risk of an account being inactive for 30-40 days for example .... - obviously it is questionable why, however security-wise - what could happen? Hope that makes sense and would really appreciate your thoughts....

CISOScott · ‎01-11-2018

@Deyan wrote:
Hello Sec Pros,

1) I am trying to craft a risk statement around lack of a security control for a system.
2) The system processes sensitive data.
3) It does not have a mechanism or the capability to automatically disable or notify about accounts that have been inactive for certain period of time.
4) I am really having hard time imagining a scenario where a risk could materialize from the lack of this control.
5) The accounts' passwords expire at a certain period of time which partially compensates the lack of this control
6) What can be the risk of an account being inactive for 30-40 days for example .... - obviously it is questionable why, however security-wise - what could happen?

So I broke your post down to several points:

In order to answer #1 we have to look at #2. What are your agency's rules around protection of sensitive data?

#3 Is your problem just there is no automated way to tell of an account's inactivity or is the system unable to tell whether an account has been active or inactive?

#4 Read Cliff Stoll's book The Cuckoo's Egg to see what can happen with accounts that are not disabled due to inactivity. Basically hackers used dormant accounts of professors who went on sabbaticals (lengthy stays away from work) to move around the network.

#5 that can be worded into your risk acceptance statement .

#6 dormant accounts can easily be activated through social engineering of your help desk personnel. People naturally want to help and can easily be social engineered to resetting passwords. What could someone do if they were able to find an inactive account and get the password reset?

Here would be my first stab at a risk statement based on what I know:

There currently is no way to auto detect the accounts that have gone into an inactive status. Our current policy defines an inactive account as one that has not been used in 30 days. Account passwords are set to expire every 60 days; so the dwell time, or time that we would be exposed, is 30 days. We currently have good identity proofing in our helpdesk procedures to ensure that anyone requesting a password reset is appropriately verified. Due to these compensating controls we advise that we:

1) Accept the risk as is. 30 days is an acceptable risk tolerance.

2) Propose reducing the password expiration date to 30 days to eliminate the risk.

3) Invest in tools to be able to monitor the activity status of accounts.

4) Manually monitor the account activity.

You would have to choose 1 of the 4 options. I just listed all that I could think of right now.

Does this help or get you started down that path?

Early_Adopter · ‎01-11-2018

Agree with everything that @CISOScott stated.

I'd add that you can think of the possible personas of your most likely attacker, I know very little about your organization but the one that jumps out is disgruntled terminated employee. Not having automatic account lockout tied into HR systems via some sort directory services is a red flag for me on terminations. Of course, there might be a process to do this but is missed or it doesn't fire in time our bad could get back on site, go to a branch office or even phone a friend to steal data, damage the integrity of a system etc.

One next thing to do if you define what you think are personas that might attack is to build some attack trees for the asset:

https://www.schneier.com/academic/archives/1999/12/attack_trees.html

I find these to be most productive and fun in groups of 2-4, and don't worry so much about the formal I mostly take this to mean 'thought about and written down/recorded'.

Deyan · ‎01-12-2018

Thank you both for your thoughts. So, assuming I am not able to read the mentioned book - I guess what I would like to know is a scenario where the risk of inactive, not disabled account materializes.

The risk statement I mentioned is a way for me to explain why the lack of this control (auto disabling of account inactive accounts) poses risk - I would like to put aside for a minute the policy stuff and just think of scenarios of what can happen in the time period between the password expiration and the inactivity disabling trigger. The risk treatment decisions mentioned above (acceptance; remediation etc.) should be made based on a clear risk statement I believe - in order for me to decide whether to accept the risk of this control - missing, I would like to know what can happen - how likely it is. So.... I really have a hard time putting into a statement - a scenario of inactive account being compromised as opposed to a regular account - any thoughts?

Early_Adopter · ‎01-12-2018

I think that you are in the realm of creating attack trees, these basically allow you to create steps to attack your system so you can work out how to defend it. The scenarios you can create can go into your risk assessment/treatment. A big problem here is in not knowing your system, and people do not like to share their attack trees or other types of threat modeling for good reasons.

So aside from the disgruntled employee/attacker coming back within the time frame of the password's validity(assuming they can't just reset it). They can always create the account and then it will still be there for a future actor to use.

It would seem to me that attacks being(or at least center around) an attacker creating/not deleting an account deliberately, or understanding the risk and exploiting an account that hasn't been locked by inactivity. So I'd start there.

So from a planned or an opportunistic conjecture(you can list out how this is possible), you should then think about what an attacker could do with the account, how much impact it would have, and who wants it. Once very big challenge in just asking for scenarios is that no one here knows your system, and this means that our brainstorming will deviate from reality very quickly.

Are you working with anyone else on this, or do you have someone you can bring in as a foil/sparing partner?

Deyan · ‎01-12-2018

Thanks for your answer. No, I am working myself on that - I think I see better now how I can justify the remediation request - something like "lack of account inactivity disabling trigger could lead to accounts, being deliberately created and later used by disgruntled employees... like a backdoor"..... or similar. However what do you think in the scenario where the account auto-disabling trigger is equal to the password expiration period - do you think that it would be a redundant control not bringing much value if the period threshold is equal to the one when passwords expire?

Early_Adopter · ‎01-12-2018

Depends - is password expiration equal to the account being disabled? Can the password be reset? Do you have other controls to compensate? It really depends on the system, it's attributes and any other pertinent considerations...

Deyan · ‎01-12-2018

Particularly comparing these 2 controls and how they compensate each other:

1) Account being inactivated after 90 days

2) Account password expire after 90 days

Question is whether they are both needed for one system. I think that control 2 compensates control 1 and if control 1 is gone - risk is not higher due to control 2 (At least in this example - having equal period) - agree?

CISOScott · ‎01-12-2018

Also do not just think of disgruntled employees as the only insider threat. Do you have procedures that require 2 people to complete a transaction (i.e. One person to create an award and another person to validate the award before it gets paid out)? I have seen scenarios where one employee was able to circumvent the 2 person create/approve process by learning the other person's password and logging in to their account to approve the award they generated. Here's a scenario:

Sally, the HR payroll person gets fired. She is normally the one who inputs the pay rate for all employees who are hired, get promoted, etc. Obviously the system is set up to not let an employee update their own record. So Mary, who has learned that Sally is getting fired is able to get Sally's account reset. Mary logs into the payroll system as Sally and updates Mary's salary, giving herself a nice pay raise. If there are not other controls to catch this, Mary probably gets away with it. If she gets caught she just blames it on Sally as being incompetent. You could have the same scenario of an inactive account if Sally went on a 2 week cruise or went on maternity leave for several months.

The danger is not always external, you have to be cognizant of insider threat as well. Maybe this will give you some ideas about building out your threat trees.

CISOScott · ‎01-12-2018

@Deyan wrote:
Particularly comparing these 2 controls and how they compensate each other:
1) Account being inactivated after 90 days
2) Account password expire after 90 days

Question is whether they are both needed for one system. I think that control 2 compensates control 1 and if control 1 is gone - risk is not higher due to control 2 (At least in this example - having equal period) - agree?

Control 2 only decreases the risk for current employees. You would still run the risk of a disgruntled employee either getting back in or giving their account information to a current employee for theft reasons, unless you had a vigorous account termination policy upon employment termination.

Also if I change my password manually does that reset the timer for control 2? If so, then just having Control 2 does not eliminate Control 1. You also have to look at the reasons for each control:

Control 1 is designed to ensure that only employees that actively use the system retain access to the system. If you do not use it on a consistent basis, then you do not need continual access to the system.

Control 2 is designed to limit the impact of a compromised account by forcing a password reset every 90 days. If an account was compromised (and they did not reset the password during the 90 days) then the maximum period of compromise would theoretically be 90 days. If users are being given warnings from the system that their password expires in XX number of days, then theoretically a compromised account would be notified and be given the potential to maintain access, thereby defeating the control's objective. Unless of course the person was using another users account and by changing the password would alert the original account owner of the compromise. So this control is only effective in it's objective if the compromised attacker does not know they are about to lose access. If they are warned and are the sole user of the account, the ability to change the password themselves eliminates the control's objective.

So it is not always black and white that one control eliminates another.