The truth about application security is that it's not really about application security. Secure coding practices are a good thing—please sanitize your inputs people. But actually, that's possibly the smallest piece of a much larger cybersecurity puzzle.
The basic goals of application security is that you don't want to get hacked and you don't want your application(s) to be down.
Unfortunately, an incredibly large amount of people for one reason or another want to hack you and bring your systems down. And isn't even personal. It's their job. They are paid for it. And their bosses don't want to spend their time needlessly.
Like every good professional, these hackers automate.
You don't need to be special to be a target. You don't need to have a billion in the bank. And you can't hide in the crowd. Computers are fast. Often faster than we intuitively imagine. Even if you have something hidden behind a billion permutations, it takes less than a second for a computer to try every one.
I love this joke: a few tourists are walking around in the jungle when they spot a beautiful, hungry looking tiger. "Run for your lives!" someone cries. And all, except one, start running. He stops, takes out running shoes from his backpack and puts them on. Another one of his comrades, still running, cries to him, "But are you mad?! Do you think you can outrun a tiger?!" - he responds "I don’t need to outrun the tiger, I only need to outrun you."
This joke has been used to explain to people they shouldn't be “soft targets” - you should make yourself look strong enough so the hungry tiger passes on to the next delicious target.
But, as you might know, the great killer of the forests is not the awesome tiger. It's the mosquitos that get you. There are enough targets for all the thirsty mosquitos and enough mosquitos to sting anyone who is not covered.
And while evidently some systems are more important than others, and merit more protection - not every computer system on earth has nuclear launch codes on them - all need some. It's not if you are getting attacked, it's when. And when is mostly all the time and a few minutes after your system went live (and possibly even before, we will get to that).
Let's take it as a given that you are a serious software developer and that you apply secure-coding practices. You sanitize your inputs like your parents told you to. You minimize the surface. You create defense in depth. You build your system to use ephemeral secrets (so evidently they are not lying around on hard disks anyway).
The problem is that software by itself doesn't do much. Or anything at all. In order to do useful things it actually needs a whole lot more. A way to build it - including its dependencies. Somewhere to build it. Configuration. Sometimes with secrets (because while you only do ephemeral ones - the API you are using might want a static API key). Underlying operating systems with a network stack - that hopefully only exposes it, as it wanted to be exposed. Databases. Message Queues. Caches. There is also data. Data that can be a vector (usernames and passwords are data too).
Actually when you look at it, if you look at a trivial system and the number of lines of code that run, all could have a security issue hidden in them. Let's imagine a typical Ruby on Rails application:
- Typical Rails application: 15,443 lines of code.
- Ruby on Rails: 338,728 lines of code.
- Ruby on Rails's default dependencies: 1,161,724 lines of code.
- Postgres: 1,491,985 lines of code.
- Linux: 34,279,868 lines of code.
The tiny green square is your code. In a real picture you wouldn’t be able to see it. This is without SystemD: add 1.3M lines just for that one. And that is without a distribution. Without openssl etc –and before we consider all of the other code that is going to be in the loop for deploying and running your application. Your observability stack. Your orchestration tooling.
Source: https://xkcd.com/2347/
You know XKCD 2347 … this is somewhat of a similar situation - but the other way around. And think that if we mesh both pictures together - the truth is that most of the application hasn’t been written by you - it’s going to have a deficiency somewhere. And even that is kind of a static view of things. The actual surface is different.
People are the Weakest Link
The most secure software can be undermined by a single person making a mistake or being successfully targeted by social engineering. Educating users about security best practices is just as important, if not more so, than the software's built-in security features.
Infrastructure Matters
Even if an application is secure, the infrastructure it runs on must also be secure. This includes the servers, the network, and even the physical facilities housing the hardware. A breach in any of these areas can undermine application security.
Holistic Security Approach
A truly secure environment considers not only application security but also network security, endpoint security, identity and access management, data security, and more. They all work together.
It’s About Risk Management
Absolute security is impossible. It's about understanding risks, prioritizing them, and managing them effectively. This includes regular security assessments, monitoring, and a proactive approach to potential vulnerabilities.
Continuous Process
Security isn’t a one-time thing. New vulnerabilities are discovered every day, and threat actors are continuously evolving their techniques. Regular updates, patches, and monitoring are essential to ensure that security measures are always up-to-date.
Privacy Considerations
A secure application also respects user privacy. Sometimes, the lines between security and privacy can blur. For instance, while collecting user data might enhance security measures, it can also infringe on users' privacy rights.
Compliance and Regulations
Application security also involves adhering to various regulations and standards, which may vary by industry and region. This can include GDPR for data protection, PCI DSS for payment card security, HIPAA for health information, and more.
Vendor and Third-party Risks
An application may be secure, but if it integrates with third-party services or vendors that aren't, the entire system becomes vulnerable. This means that securing an application also involves ensuring that all its connections and integrations are secure.
The harsh reality is this tangled web of risks and concerns are largely unavoidable in modern application delivery. We can’t be experts in everything, or monitor all of these pieces changing around us all the time.
In the end, we’ll be better off the sooner we accept it, and choosing a security-focused Cloud application platform like Upsun makes doing that that much easier. Upsun provides expertise in securing infrastructure, relying on explicit definitions to define access control, and managing services continuously behind the scenes to mitigate risks to always remain compliant, even for the most sensitive data.
Protecting the code you don’t write yourself is tough – for many different reasons. Learn what you can, and keep yourself and your team as educated as is possible on best practices. Otherwise, accept that we all can’t be experts, control what you can as strictly as you can, and consider that when it comes to infrastructure and DevOps, an expert like Upsun could be your secret weapon.
