When I spoke at RSA Conference in San Francisco back in April, I discussed the burgeoning security debt that we all must contend with…and that soon, the bill will come due.
Security debt is the accumulation of the patches missed, the risks accepted, and the configurations misapplied. Over time, these grow and the interest is compounded from these risks. Case in point: the mismanagement of user accounts with an enterprise.
We have all experienced this at one time or another in the course of our careers, or, more troubling, have yet to encounter this issue in its entirety.
Many years ago, I was working for one technology firm that asked for an external third-party vulnerability assessment. While this was an activity that would be considered standard fare for many organizations, that wasn’t the case here. There had been no security team at the company for several years before our team was created.
The audit kicked off, and before the first day was done, they [the third-party team] had managed to breach the perimeter and compromised the routers and switches. Not just one or two, but all of them. My heart sank at how easily the testers carved up our network like a hot knife through a stick of butter. It was a humbling experience. We learned in short order the monster we had inherited from our long departed predecessors.
On the second day, they had taken control of the Microsoft Entra ID and managed to decipher almost all of the accounts. The scope of work that we would have to undertake based on this exercise continued to grow. I was going to require antacid at this rate.
Once the dust settled and the testers provided us with their extensive report, we parcelled out the work packages for the associated groups within the organization that would need to address them. The lion’s share of the work focused on user accounts.
My heart sank at how easily the testers carved up our network like a hot knife through a stick of butter.
We drilled down into the accounts that were popped and were disturbed to discover that almost 100 accounts were administrative-level access for people that were no longer with the company. For whatever reason, the add/remove process for staff had completely broken down. These accounts were still active, and in one case, the individual had left the company 10 years ago. To add insult to injury, that same user had also since passed away.
There was no good reason for these accounts to still be active, but there they were, staring back at me from the thick report. This is where the argument for zero trust gains significant traction. These accounts should have been linked into an automated function or process to ensure that these accounts are disabled when an individual leaves a company.
Back then accounts were limited to the use of static passwords, but the current landscape provides us with a view to a brighter future with multi-factor authentication. In addition to making it easier to secure account access, multi-factor authentication would help reduce the rates of incidents such as people calling the help desk to have their passwords reset as there will be self-service account management. This would thereby reduce the costs to the organization over time.
Security debt is the accumulation of the patches missed, the risks accepted, and the configurations misapplied.
Organizations that have been around for a length of time will more than likely find themselves in a similar situation if they do not have a defined and repeatable add/remove process for company personnel.
We were embarrassed at the extent of failures that we discovered as it pertained to user accounts in our environment as a result of the assessment, but those failures provided a valuable, teachable moment that we took to heart. We counted our lucky stars that a nefarious third-party had not discovered this as well, but that may well have been chalked up to blind luck.
Don’t rely on luck. Examine the access that currently exists within your environment before someone else does it for you.