December 12, 2022
(Updated December 2022) It may seem like an obvious fix, but it’s overlooked more commonly than it should be.
Default credentials have been a consistent source of security risks for decades. In the past, attackers who knew the default login credentials built into device firmware could easily bypass security policies and compromise entire networks. Now, the same threat applies to cloud-based technology solutions and the Internet of Things.
The fact is that many operating systems, databases, and software solutions still come with preinstalled login credentials. The technological advance from legacy hardware to cloud-native infrastructure hasn’t changed that. In fact, it made those default configurations even more accessible.
According to a 2018 study, 61% of applications surveyed used a default or blank password. As organizations expand the complexity of their tech stack, maintaining rigid credential security gets harder.
Know Your Network: Identify Systems Running with Default Credentials
Not all technology vendors deploy the same set of default credentials across their entire product line-up. Many have adopted approaches that are far more secure – like requiring password change upon initialization or shipping individual devices with unique credentials. However, there are still many holdouts.
Cybersecurity leaders and systems administrators need to work together to identify and categorize these holdouts as quickly as possible. In a large organization with a complex tech stack, this can be a serious challenge. Nevertheless, it’s a necessary step on the path to operational security excellence.
Not All Credentials are Passwords
When conducting default credential discovery, keep in mind that passwords are just one type of credential. If you limit your search to username/password combinations, you may miss out on even more important kinds of credentials.
For example, most organizations use software that generates certificates or keys that link devices and applications together. This kind of functionality could link a fleet of IoT devices to a smartphone app or funnel automated customer queries through an API. If the software generates certificates and keys using default parameters, the entire system is vulnerable to attack. Anyone who is familiar with the default configuration can take control of the system.
How to Address Default Security Configurations
Developers, service vendors, and end-users need to work together to address default credential vulnerabilities. On the developer side, organizations that create cloud-based software and IoT devices need to integrate “firstboot” functionality into their products. This makes credential generation the first thing end-users do during setup. That ensures there is no default configuration to compromise.
Service vendors need to verify the technologies they use to ensure that default credentials are not in use. This may require customizing applications with scripts that check if the software has completed setup and changed its default security configuration.
End users also have a part to play. No organization should ever issue default credentials on a device-wide basis. This only gives users an opportunity to change their credentials to the provided default configuration, eliminating necessary security benefits for the sake of convenience. But the price of this convenience is too high.
Pay Close Attention to Cybersecurity Standard Compliance
CISA recommends applying multi-factor authentication on all privileged accounts, external-facing services, and VPN connections. It points specifically to the NIST SP 800-63B standard for guidance on vendor-supplied default usernames and passwords. Cybersecurity leaders can use this information to qualify their vendors’ approach to privileged access management best practices. NIST-compliant vendors should include the necessary policies and controls to ensure secure credential behavior.
Non-US compliance standards may also play a useful role. The European ETSI 303 645 standard is the first global cybersecurity policy developed exclusively for IoT products. It specifically prohibits hard-coded critical security parameters in device software source code. It follows that any vendor providing ETSI-compliant products and services should protect its customers from default configuration vulnerabilities.
Review Your Security Posture with Castra Expertise
Systematically reviewing your entire tech stack for default credential configurations can be a monumental task. Castra's expertise can help you identify ways to streamline this process and discover at-risk assets more efficiently.
Reach out to one of our specialists to find out how we can improve your security posture against default configuration risks.