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?
When to change the defaults
You certainly want to change any default passwords or passwords given to you by a vendor or anyone else, especially if it's non-unique and written down in documentation. This describes most default logon passwords for network devices, wireless access points, and other common consumer computer devices.
Some network devices use their unique MAC address (or some variation of it) for the default password. This is better than sharing a non-unique, documented, default password -- but only slightly better. The MAC addresses on those devices are almost always transmitted wirelessly in the clear, where any attacker can sniff them up. Make sure to change any of these sorts of passwords.
Change default wireless SSIDs and SSID passwords or keys. Wireless SSIDs really aren't that risky to leave unchanged, but leaving them at the default SSID value has caused issues in the past (such as unwanted auto-connections) and could be a sign to attackers that the owner isn't overly sophisticated and should be scrutinized more. SSID password keys should definitely be changed to something long and unique.
There is also some value in changing default storage paths if the storage paths might allow an attacker to fill up the available free space and crash the system. For this reason, many installers make sure that storage paths lead to big storage areas that would be hard to fill up, or at least point them to areas not shared by the operating system.
When not to change the defaults
In general, most popular operating systems (Windows, MacOS, Linux, BSD, iOS, Android, etc.) have fairly strong default settings. Certainly they have a nice balance of security and operational considerations deployed. Further, you'll invariably find that the vendors or organizations behind these operating systems have recommendations regarding which defaults you should change.
For example, Microsoft Security Compliance Manager has been relied upon by millions of users to see what the defaults are and what Microsoft recommends be changed if you're worried about security. It contains hundreds and hundreds of settings. In most cases the operating system's defaults are adequate. In some areas, Microsoft recommends more secure settings, such as increasing the minimum password size from 6 to 12 characters.
The leading vendors are so good at picking good defaults (notice I say good, not perfect) that if I wrote a book today about tightening operating system settings it would contain just a few words: "Don't muck it up!" That's because when you change a default, you are often making a change you don't fully understand. Anything you don't understand is insecure, even if some well-known and respected group has told you to make the change.
You'd be surprise how many trusted security configuration guides have settings that have never been tried or implemented. These people are telling you to enable or configure something that could cause harm or issues in most environments. I've seen trusted security guides make suggestions that would literally turn off critical security settings with absolutely no benefit. In fact, they would make you less secure.
Don't change default service or daemon run settings. Most people who turn off default services don't understand the full repercussions of what they are doing, and usually there is little benefit to doing so. The conventional wisdom is that any service running that doesn't need to be is just an additional target the hackers can attack. And this is true. But as long as you don't change the default settings and you stay fully patched, usually it's very difficult for the attackers to gain a foothold, especially without tricking the end-user into doing something first. Truly remote buffer overflows are rare today.
As my anecdote at the beginning of this article showed, don't mess with the default group memberships if you don't have to. The biggest problems I see with group membership changes is people putting far too many users into elevated groups that should have few if any permanent group memberships. Removing a default group membership is almost always a bad thing.
Here is an oldie-but-goodie blog entry on the subject of defaults that I often send to customers. It's written by Microsoft's Aaron Margosis, who has the technical smarts, wisdom, and experience to give authoritative security advice.
The decision of when to change defaults should be led by whether or not the change would stop a likely critical threat and not cause too many operational issues. Too many people make changes for theoretical threats they will likely never face, and do so without understanding the long-term operational consequences. When in doubt, chicken out, and go with the vendor's defaults or recommendations.