Fighting a loosing battle

Image from Pixabay

 My search yielded 359 documents. Admittedly, a few of them were about research into and lamentations about the phenomenon sought. But that still leaves about 350 documents in which colleagues had written it down without batting an eyelid: Welcome01.

In the past, if you had forgotten your password after the holidays, you had to call the helpdesk. You would often get Welcome01 as a new password. I went to talk to them and explained that that wasn't such a good idea. After all, everyone got the same password. The thought behind it was probably: this is easy for the user and after logging in for the first time, they have to set a new password anyway. But hey, if I have bad intentions and know in advance what someone else's new password will be, I can use that. The helpdesk came to its senses and switched to generated - and therefore unpredictable - passwords. This service was automated away years ago and that put an end to Welcome01.

But not really, judging by the results of my search. Incidentally, I knew in advance what I would find, because it remains a loosing battle. We are an organization where applications and infrastructure are built. Of course, those things have to be tested. That’s often an automated process or at least a team effort. For testing, you need valid credentials. And precisely because testing is not a solitary activity, all team members who are involved must have the passwords of the test accounts. I get that. Two other things I do not understand: the password that is chosen, and the fact that I can find out about it.

Let's start with the first one: come on people, Welcome01! Can't you think of anything better? Yeah okay, it has a capital letter and no less than two numbers. Phew. The big weakness is of course the predictability of the password. There is a snicker when this password is mentioned, because we all know that it is used in so many places. Effectively it means that I know your password. And many others with me. You know that this is not what we want.

My second sneer is for the fact that I got hundreds of hits on my query. I don't have any special magic that gives me access to all information. That means that all those internal pages, where teams explain how and with what you can test all sorts of things, are not protected. And that anyone can access them. You're putting your house key under the flower pot, dear colleague.

Oh, they're just test accounts, you sigh. We would never do that in production! So why do it in test? It's a small effort to (a) have a decent password generated and (b) properly protect that password. It all comes down to attitude and behavior. Just as I'm convinced that secure behavior in your private environment radiates to work, I'm also convinced that your behavior in one environment influences your behavior in another; laxity on the left side easily leads to an "I'll just do it the same way on the right side" attitude when something needs to be fixed quickly. And when the problem is solved, everyone forgets that something still needed to be fixed.

In the past, it may not have been that bad. Back then, there was a strict separation between development and operations. With the advent of devops, that boundary has blurred: in many teams, all employees perform all activities – so both development and operations. And so they have to be able to access everything. Right through all DTAP streets. These are separate environments for development, testing, acceptance and production. But if you can access everything, then you can copy behavior from the 'less exciting' environments to the environment where it does matter. That makes us vulnerable.

The myth says that production data is only in the production environment. Yes, in the past we used test files that consisted of purely fictitious data. After a functional adjustment, the test data was adjusted or expanded. Nowadays, this is considered too laborious. And so (anonymized) production data is used. But it’s still production data. Combine that with the other myth that all employees are super reliable, and there’s your recipe for disaster. We like to look the other way when it comes to insider threat, but statistically speaking, every organization is entitled to a certain percentage of black sheep. Don't make it too easy for them. Let's agree that all those simple passwords will be replaced by something decent and that next week, I will no longer be able to access all those pages with passwords that I have open now.

 

And in the big bad world…

• This new ENISA threat report cannot report anything on insider threats because too few reports are made public.
• Insider threat doesn't stop when someone leaves the organization.
• the new version of macOS breaks several security tools.
• Russian AI is interfering in US election battle. (The article is a gift from the newspaper, hence the long link.)
• a hacking contest is not intended for real attacks.
• the FBI took down a Chinese IoT botnet.
• maybe your equipment is also part of that botnet. [DUTCH]
• The Dutch Data Protection Authority is receiving too little funding, according to the DDP. [DUTCH]
• Some people think that AI cameras will be a boon to humanity.