failing to disable stale accounts in an application.

pma111
pma111 used Ask the Experts™
on
We have an internal application, whereby users are required to reset their passwords every 90 days. The application has its own security & accounts, and does not integrate with our AD domain in any way. The system itself stores fairly personal client records. If a user does not access the application in a period of time, the administrators do not seem very effective in disabling the users account which is what should happen (they are expected to manually review all active accounts every 8 weeks and disable any stale accounts, and query them with their line manager to determine if access is still appropriate or not), this what should happen – but a recent audit has identified this does not appear to be the case or working effectively.  

The application itself does not work in the same way as say Active Directory, as if a users password has expired (every 90 days is the current setting), the application does not simply prompt them to set a new password and then access can be achieved again, the administrator would have to reset the users password before access could be achieved. The admins are of the view that this is sufficient, e.g. if they have a list of 10 accounts who have not logged into the system in over 365 days, it doesn't really matter that they haven't disabled their accounts, as they cannot gain access to the data as their passwords will have expired. I am not overly comfortable with this approach, but I am struggling to find any real reasoning to counter their seemingly lax approach to access control. Can you think of any additional issues that would help build a case. There may be other reasons above and beyond data security why the current approach is bad practice that will also help build an argument.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
nociSoftware Engineer
Distinguished Expert 2018

Commented:
If you need Access security "like AD" and none is possible by the software there seem to be 2 basic options:
1) modify the application to integrate with AD
2) modify the application to mimick the way AD works.

the 2nd could be most simple:
Add a entry field with each record: Enabled/Disabled
Modify the login code to verify an account is enabled during password checking.
(not indicating why a check failed though: don't return errors like account disabled, wrong password etc...)
Provide administrators with a tool to enable/disable....
Auto disable after 91 days of non-access.

BTW:
I am not sure you should say "lax system administrators" unless you are on a path of war with them....  It won't help getting things done in the future.
System administration is about keeping everything up & running with the tools given....,
Business Administration can be considered lax because there is no priority for security (allocation of time,  money etc). or for not providing the right tools (like software that follows audit rules)to do the work.
The people selecting this sotware and the people that either approved it's purchase or that commisioned its build are the ones that need to do some explaining.
ste5anSenior Developer

Commented:
It seems like you need to go to a higher level in your organizational hierarchy. Cause:

1)
We have an internal application, whereby users are required to reset their passwords every 90 days.
This is no longer recommended, even by NIST ( NIST SP 800-63 Password Guidelines- link currently not available due to shut down). This rule should be removed.

2)
The application has its own security & accounts, and does not integrate with our AD domain in any way. The system itself stores fairly personal client records.

This raises compliance questions like auditing access in general.
If a user does not access the application in a period of time, the administrators do not seem very effective in disabling the users account which is what should happen.
This requires automation, not manual action. Thus you need budget to implement it in your application.

Just my 2¢.
Exec Consultant
Distinguished Expert 2018
Commented:
I am thinking there is need from strong governance and the company would have to comply with the IT security policies. If there are no policies in the first place then all such different practice and standard will keep recurring. If the wording is not strong or clear then it calls for changes otherwise the user will have to seek deviation on the specific policy clause. Importantly application and host accounts are still treated as accounts, and policy must mandate it clearly too.

Regardless, I added in the practice that is adopted widely and in specific it refers to CIS controls

The application itself does not work in the same way as say Active Directory, as if a users password has expired (every 90 days is the current setting), the application does not simply prompt them to set a new password and then access can be achieved again, the administrator would have to reset the users password before access could be achieved.

1#Practice - Ensure that all accounts have an expiration date that is monitored and enforced.

Notes: Having an expiration date is a need for and 90 days has been a good practice till NIST has started to advocate a long password or passphrase instead of maintaining a short expiry period. It is a balance of risk and security. Indeed if the password is no weak ones and not those easily brute force using dictionary and has account lockout, the expiry period can be longer.

That said, your current practice is still sound and it is a matter of balance for managing the operational overheads for legitimate user who is really locked out because their account is expired. It may create additional overhead for the help desk team but only if there are no prompt to user for early change done which seems like it is not taken up in your case. Expiry and prompt for change should go as one "pair" to reduce the overheads. Such standard of procedure is not new.

The admins are of the view that this is sufficient, e.g. if they have a list of 10 accounts who have not logged into the system in over 365 days, it doesn't really matter that they haven't disabled their accounts, as they cannot gain access to the data as their passwords will have expired.
2#Practice - Automatically disable dormant accounts after a set period of inactivity.

Notes: Unused accounts may not be monitored, so it’s best to remove them if they are not needed. Don’t forget that this also applies to third-party services such as Amazon Web Services. Any dormant account is point of weakness to gain unauthorised access and this is one of common point entry for privileged escalation especially when those account are of admin rights or has been test account but not removed. Data breach exploiting those account will not be surprise and subject company to face the serious aftermath.

3#Practice - Establish and follow an automated process for revoking system access by disabling accounts immediately upon termination or change of responsibilities of an employee or contractor. Disabling these accounts instead of deleting accounts allows preservation of audit trails.

Notes: Creating a process is as simple as documenting what needs to happen in order to revoke access. The technical details on how to follow through can be leveraged from existing frameworks like NIST or other regulatory bodies. But as mentioned disabled account can still be retained for audit purpose and normally the account are removed from all access rights in that retention case. These are stipulated in the policy too and a period like 5 days after the account get disable need to remove all rights if it is going to be retained otherwise account is removed.
Bootstrap 4: Exploring New Features

Learn how to use and navigate the new features included in Bootstrap 4, the most popular HTML, CSS, and JavaScript framework for developing responsive, mobile-first websites.

Shaun VermaakTechnical Specialist
Awarded 2017
Distinguished Expert 2018

Commented:
Does the application have a last logon time in its database?

I would use that and simply create a procedure that would disable/delete these users, probably hosted in a Windows Service
https://www.experts-exchange.com/articles/33372/NET-Windows-Service-Template-using-Timer-Topshelf-and-Log4Net.html

Alternatively, you can do automate this with an IDM solution.

Author

Commented:
Yes the system does capture last login information,  however, the database compionent of the application is a rather obscure platform, nothing like standard/ common such as MSSQL, Oracle, Access etc - so the admins only really have access to the application tier, the database is largely an unknown...
ste5anSenior Developer

Commented:
hmm, sounds like you should do a proper risk assessment and assign it a budget...

Cause this kind of rules should be handled automatically by the application. Not manually by administrators. When the budget is to low to automate it in the application, then you need at least the budget for your admins to do this job. Important part: you need business/application admins to do this, not the regular IT admins (separation of duty et al.).

In the end: you need to spend money to achieve your goals. But currently it sounds like you're trying to find a pragmatic solution, which is ruled out when your reasons for doing this is compliance.
btanExec Consultant
Distinguished Expert 2018

Commented:
Also if the said practice is across all the application implementation or specific to this case. The policy should set the baseline and if risk acceptance and waiver (if req) are done or missing then the system owner need to put forth for compliance. Proper governance workflow need to be in place such that if there are gaps, not only risk assessment is conducted, the owner is apprised and with views of security team to make an final informed decision.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial