In the fast-moving world of DevOps, security sometimes got left by the wayside on the way to the next iteration. But today's threat landscape is so perilous that developers need to have solid security top of mind as they design and build applications. This includes features like user authentication, digital signatures, and encryption.
Learning from Insecurity at Uber
Uber's operating procedures provide many cautionary tales, but this one gives a vivid description of why security is needed at every level and what can go wrong if it is not in place. An Uber software developer stored a service credential in application code to access sensitive information from the database. He then stored the code in a private repository in GitHub.
Including service credentials – a "shared secret" – inside software would, in itself, have been a violation of security best practices, since these can be compromised in many places besides the GitHub repository. This would include testing environments, staging machines and, of course, the production infrastructure itself.
Here's the rub: GitHub wanted software developers to protect their repositories from unauthorized access, so it had already implemented FIDO-based strong authentication. Despite the deployment of one of the strongest authentication protocols in the industry, GitHub neither encourages its users to sign up nor sign in with FIDO technology. Consequently, the Uber software developer used one or more shared secrets – username/password, one-time passcodes, etc. – to authenticate to the Uber repository.
But wait – there's more. Uber also automatically deployed its applications into Amazon Web Services (AWS) using yet another shared secret: an application programming interface (API) key with a secret key – in other words, a username and password.
The result was a perfect storm of insecure practices: using passwords to store software in a repository, containing passwords to access a protected database, using passwords to automatically deploy applications into the public cloud. It all eventually led to the compromise of sensitive data. Uber suffered a breach of 57 million passenger and driver records in 2016.
Security at the Application Level
This story included many security faux pas, but malicious actors only need to find one. FIDO's multiple uses make it an ideal security option. Though FIDO protocols were primarily designed to enable strong authentication to web applications, they can also support transaction authorization. Sadly, as noted above, organizations are apparently not using either feature in any consistent, meaningful way.
This leads to unnecessary losses. FIDO protocols not only have the potential to strengthen transaction security, but they eliminate the password nightmare that end-users go through while protecting them and web applications from many attacks on the internet.
Ransomware is a prime example of why organizations need application security. Such attacks work because applications allow authenticated users to modify files – encrypting them and deleting the original file – without secondary authentication and/or authorization. Consequently, malware executing on users' computers do so with full privileges of the user. FIDO digital signatures change that framework, leading to higher levels of security.
An additional security measure at this point is transaction-level authorization to not only deter transaction fraud but also to protect against ransomware. The protocols are available today; the tools are available now. All that is required is the resolve to implement these measures.
Laying a Secure Groundwork
One of the reasons bad actors continue their successful streak of data breaches is that organizations are still operating on the mistaken assumption that it is easier to deter "barbarians at the gate" than to protect sensitive data in the application. As a result, companies over-invest in network-based security tools – firewalls, anti-virus, malware detection, intrusion prevention, etc. – rather than also invest in the control mechanism that provides the highest level of data-protection: application-level encryption.
By adding application-level encryption from the ground up, software developers serve their users well. While some risk can be reduced by using FIDO-based strong authentication controls, reasonable data security requires multiple controls to deter attackers – a practice the security industry terms as "defense in depth."
The most secure data protection a company can hope to implement, without eliminating sensitive data from a system, involves encrypting and decrypting data within authorized applications (combined with a hardware-backed cryptographic key management system). Adding FIDO-based strong authentication creates a high level of risk mitigation. By building these security measures in from the start, DevSecOps professionals lay the groundwork for maximum-strength protection where it counts most.
Learn more: TLS: Too Little Security
ALSO SEEN IN: DEVOPSdigest
