When it Comes to Visibility, Seeing is Believing

Everyone knows that you can’t solve the problems you don’t see. Seeing a problem itself doesn’t necessarily solve it, but if we can’t see the problems in the first place, then without our knowledge hidden potential ones can become visible with all kinds of consequences – see “Sony Pictures Inc.”. I was working with a couple of clients at the end of last year and ran into issues that make the same point, although a lot less spectacularly.

For the first client, we were in early stages of a Proof of Concept, running some collections designed to highlight the AD landscape. The customer taps his monitor and says to me: “You guys have a bug here, it’s showing way too many users in this group – it shows 23, it should be 3.”

Now, when a customer tells you that your product has a bug during a POC, things aren’t usually going too well. In this case, though, I was pretty sure it wasn’t us, so I played along. “Really?” I asked. “OK, let’s take a look at the group, and see where we went wrong.” Up comes ADUC, we look for the group, open it up…. 23 members. In the domain admin group of one of his resource domains. The client turns a bit green, says “excuse me for a minute,” and walks away.

So, I’m sitting at his desk waiting for him to come back and a couple of minutes later he reappears. “Can I get a screenshot of your report please?” he asks. Of course, you can, happy to help – he sends it off to his boss’ boss, chuckling ruefully and shaking his head. He tells me later: “We outsource the file servers in that resource domain to a third party that provides storage. They should know better, now we get to have a chat with them. Thank you.” Mission accomplished – our tool provided much-needed visibility to a security problem, the client gets to look like a hero for finding it during a POC. All good.

The second client was also doing an eval, this time looking for sensitive data in their file systems. As part of the POC we had picked one of their production NetApp filers, looking for a range of data governance challenges. The scan completes, and we start looking at the results. The client jabs his finger at the screen, “What’s that? Can you tell me what’s in it and who has access to it?” Of course, we can, that’s our job. Let’s take a look.

First: The filename is “passwords.txt” and, according to the summary on the screen, it contains 233 instances of usernames and passwords.

Second: Sitting on an open share, readable by anyone.

After we dig a bit deeper, it turned out to be exactly what you’d think – a password file that contains admin passwords for a range of member servers, the domain admin passwords for two of their domains, other gems. And over the previous 4 days, 12 people opened the file and took a look at the contents. Terrifying stuff – a huge vulnerability, and without visibility into the contents and the activity around the file, a problem that could lead to embarrassing leaks down the line. Customer exports the result data and sends it off to his colleagues to get it fixed, we’re looking pretty good again.

Now, it would be reassuring if I could say that these issues were uncommon, that I had to search through hundreds of experiences across all of my time using our tools to find these examples, but that’s just not the case. Files like passwords.txt, SalesCreditCards.xlsx, OurFinancials.doc, ClientInfo.pdf – these are the documents we come across all the time, sitting out there on networks available to be read by all kinds of folks. The two examples I listed? Back to back weeks in October during some on-site meetings.

So, visibility saves the day. In this case, two high-priority issues that rapidly got fixed once they knew they were there, we looked good, and we made them look good too.

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

Name

Email*