What security really is...

Security isn't a project or even a program. It is a practice that must be ingrained in every aspect of your environment... and it is never "done".

I have my own personal quote:

"Security is the practice of making the level of effort required to access a resource higher than the value of that resource."

I believe this makes perfect sense. If something is low value but high effort, why would anyone bother? If it's high value but low difficulty, you should consider it a target for compromise.

Notice also the use of the word "practice". Security isn't a tool or an architecture or ever "done". Security is something to be considered and validated and ensured every day. Verifying your security hasn't been compromised requires constant monitoring and vigilance. Updating your practices and technology and investments must also be constant. Security is never "done".

This leads me to another personal quote:

"Anyone that uses the phrase or tells you that something is '100% secure' is either an idiot or lying."

Why? Consider these truths:

• The value of information is constantly changing. What might have been of less value yesterday could become critical and vitally important tomorrow. This means that it's value as a target and therefore likelihood that someone will attempt to compromise it goes up.

• The tools available to perform attacks and compromises of existing security solutions and architectures improve constantly, every day. This means that a compromise that may have been difficult yesterday may be as simple as running a script against a target today.

• The raw computing power of the systems used to perform attacks is also ever increasing. This is true for your desktop computer, but it's also true for the number of devices on the internet that have lax security and are compromised into tools for performing attacks. Sure, even if an attacker has a fast desktop computer they're unlikely to overwhelm your VPN server… but if that computer is simply the command-and-control center for 100,000 compromised devices that can all simultaneously attempt connections against your infrastructure? Even if they can't get in, the power of such a distributed denial of service attack will almost certainly prevent you or your clients from getting in either.

• New vulnerabilities are discovered every day. Despite the best efforts of great organizations to develop the most stable and secure platforms possible, things are always missed and assumptions are always made. The programmer's belief that a number will never exceed a certain value, or that the amount of data submitted will never go beyond a certain amount, or a certain string of text will never contain certain characters, or that the infrastructure in front of you is properly configured, all happen every single day in even the best solutions. These assumptions are an attacker’s best friend.

• Your security isn't just about your own platform or tool or component. Every piece of the infrastructure introduces the possibility of misconfiguration or information from compromised sources (think reused passwords, compromised certificates, improperly applied permissions), and solely relying on other systems or fully trusting those systems puts the security of your component completely in their hands.

• Your infrastructure isn't static. It changes constantly as new tools are added, new things need to talk to other new things, ports need to be opened, new connections need to be allowed, new code or functionality is introduced. In many cases, these solutions are somehow "presumed" to be reasonably securely designed and implemented… but that belief is never actually tested or verified.

• In today's world, everything depends on everything, and we don't always know those dependency chains or how their security is verified. Your software developers are constantly introducing new packages and libraries that depend on other libraries which depend on other libraries, etc. Do you think they're testing all of those? Doing code reviews for every package? Do you think they even know or care about that chain of dependencies? Every package that's introduced is a risk that should have testing and mitigations in place. Consider the SolarWinds compromise: It wasn't SolarWinds that was compromised… it was a package that depended on a package that was compromised. Security isn't just about you.

The point is security is never "done". The world is constantly changing. The capabilities of attackers, the value of your information or resources, and your infrastructure, code, and architecture are all in a constant state of flux. Your security practices and efforts MUST be equally ongoing. If your security isn't keeping up with the world, you are already at risk… and in the world of security, being at risk means you have already failed… not because you're compromised, but because you have put yourself in the position of either knowingly left yourself open to compromise or possibly having been compromised and simply not know. Yet.

So, now that you're paranoid or even terrified (you should be), what should you?

• INVEST in your security teams and infrastructure. Underfunding security directly correlates to increased risk of compromise. If they don't have the tools to protect from or detect or mitigate risks, you are directly allowing the possibility of those risks becoming reality… and then it's too late.

• PRIORITIZE security. Make security a first-class citizen in your organization. Give your security teams not only the ability to recognize risk, but the power to prevent those identified risks from moving forward. Allow your security teams to have full veto authority on anything that could increase an unmitigated risk. Overriding a risk your security team identified and tried to prevent becomes your responsibility and your potential fault, not theirs.

• BE PARANOID. Recognize that you are never 100% secure. Don't trust anyone or anything that declares itself to be secure. Test everything. Review everything. Try to compromise everything. Then, do it again. And again. Remember, everything is constantly changing, so your possibility of new risks being introduced is also constant… so your work to attempt to identify those risks must be equally ongoing.

• OWN RESPONSIBILITY. The decisions you make, regardless of your role in an organization, have a direct impact on your security stance and risk. The CFO that underfunds the security team is contributing to risk. The team that demands an integration with a 3rd party platform without allowing a security review is creating risk. The software developer that isn't fully reviewing a package or library and all its dependencies is introducing risk. The server administrator that isn't consistently applying updates or isn't taking advantage of security capabilities or configurating or is allowing everything to run with root/administrator rights is creating risk. Risk is created everywhere, by everyone, including you.

You can never be "100% secure"… but you can recognize the value of your information or tools as a target. You can recognize your potential risks. You can ensure you have the resources to prevent and detect risks and implement mitigation factors. You can avoid the term "acceptable risk"… and if you do "accept" risk, own that decision and the impact if/when the risk occurs. You can evangelize the importance of security not only because it's your responsibility but it's the responsibility of everyone around you as well.

Security is a practice, not a solution. It goes on forever. When you think you're "done", you have already failed.