There's an old security mantra that says "always change the defaults!" Although this seems like a good general rule, in fact it's true only for certain kinds of settings. Changing the defaults in other cases will just end up biting you in the end with little increased security to show for it.
A few months ago I was onsite at a favorite customer's of mine installing a big new software program that would be a mission-critical component of the security environment. I had installed this program hundreds of times over several decades. Occasionally, I've run into install errors or other issues that I had to troubleshoot. Rarely did it take more than a day to figure out the problem and move on.
But this particular issue was different. This time I was stumped. The error message being thrown was a common one, but nothing I had done before to resolve it worked. I brought in a team of people who wrote the code. They were stumped. We called on more advanced support. And they worked on the problem for days, moving tech support teams across the global "to follow the sun." The customer was upset with me and my company.
In the end, it turned out the error was caused by the customer having removed a default group membership from the local computer. Unknown to them, this default group was required for normal network authentication; without it, authentication broke.
After the issue was identified, it was discovered to be behind several other, seemingly unrelated problems the customer had experienced. And no one, at least at the time I was onsite, could say exactly why the default group membership had been removed. All anyone could remember was that it was done to eliminate a potential security issue that the customer was worried about. But in implementing the "solution" they had thrown the baby out with the bath water.
I understand why computer security defenders want to change the defaults to make a computer or network "more secure." Heck, it was the primary message of three of my eight books. I spent most of these books explaining the defaults and why they were not secure enough, and then suggested additional, custom tightening.
The problem is that I was wrong. Well, I was not exactly wrong at the time, because many of the defaults were in fact insecure. But this advice is certainly wrong for today's world. Even back then, it was probably rooted in too much paranoia and lacked sufficient respect for business and operational concerns. The difference today is that most software programs and operating systems have fairly secure defaults, and changing them to be more secure could hurt you operationally. So when should you change the defaults and when should you not?
Sign up for CIO Asia eNewsletters.