Don’t Be a Victim of Misconfiguration

With the constant stream of breaking news headlines about the latest security breach, it often sounds as though every attack is extremely sophisticated, similar to Stuxnet. Reality tells us though that many breaches are due to simple and completely avoidable human error.

Consider the recent data breach of healthcare.gov. An official at the US Department of Health and Human Services said the server had a low security setting as it was never meant to be connected to the internet. Compounding the problem, this server was guarded by the default password which doesn’t even meet minimum security standards. While every breach is not this simple, it does make you think about the need for a structured process and basic password management rules. What measures does your organization take to avoid security breaches like the one I describe from healthcare.gov?

For my initial IdeaXchange post, I’m sharing a list of 10 things I have seen many organizations implement to ensure they are not a victim of misconfiguration. I’m curious to know which practices your organization employs. Are there other measures you use that I should add to my list? 

Acknowledge the insider threat. Many of the serious security attacks come from people inside the organization or from privileged accounts that have been compromised. Any accounts not explicitly tied to a person (shared accounts) should be automatically managed, and no user(s) should retain long-term knowledge of the credentials.

Rename the built-in super user account. While this is not possible on all systems, when an option, you should consider renaming the built-in administrative accounts.  This ensures someone with knowledge of systems you use is not given a logon name to attempt a breach.

Change the built-in super user password. Changing default passwords on built-in privileged accounts is probably an obvious security step that most administrators take. Security breaches due to default passwords on these accounts, however, are one of the top reasons servers become compromised. One of my customers has a policy that once the device is accessible, the default password is changed.  This applies to test, development, pre-production staging, and production systems. The point of the policy is to change the password immediately.

Implement strong authentication. For shared, super-user, and other types of privileged accounts, strongly consider implementing two-factor authentication. Passwords alone are never sufficient to protect accounts with privileged access to sensitive systems and/or data.

Insist on automatic and frequent password changes. Remove the human element, and offload password management to a trusted system.  This will ensure passwords are changed on a frequent and scheduled basis. More importantly, no user should know the password until they move through a password management system to retrieve the password, which creates an audited event. Additionally, all password management solutions should automatically change passwords once the request duration has expired.

Use Complex Passwords. When a password cracking engine has access to hundreds of millions of user generated passwords, this eliminates the idea a user will come up with a password scheme that is not present in these freely available databases. Let a password manager handle the random password generation. Use long, 25+ character, complex passwords that are a mixture of numbers, uppercase letters, lowercase letter, and symbols. If you need to better understand the risk read "Why passwords have never been weaker—and crackers have never been stronger" by Dan Goodin.

Implement least privileged access. If your organization is serious about security, then users are not admins on their desktops and even administrators only have rights to what is needed to perform their job. Reduce the number and type of privileged user accounts, where possible.

Record all access to sensitive systems. When a system is part of a sensitive element of the business process, any logons and privileged activities should be recorded. This process helps maintain compliance and ensures an easily reviewable audit trail exists. More advanced techniques also include session recording, keystroke logging and behavior analytics enhance audit processes, and improves prioritization and responsiveness to potential threats.

Restrict logon locations. Using firewalls restricts what IP addresses are authorized to perform RDP or SSH type connections. Some companies go as far to restrict administrative accounts to doing console-only logons.

Use bastion host and jump servers - The concept of jump servers or bastion hosts are common in many organizations. In the jump server scenario, it is the only host permitted to connect to a number of hosts over specific ports. A bastion host is a bridge between a corporate network and a secure enclave. Users can only connect/communicate with systems in a secure enclave by connecting to a bastion host.

What do you do to avoid making basic security mistakes?