How do Observability and Security Work Together?
There’s no question that the last 18 months have seen a pronounced increase in the sophistication of cyber threats. The technology industry is seeing a macro…
Our next-gen architecture is built to help you make sense of your ever-growing data Watch a 4-min demo video!
Formats: PNG, PDF, and SVG
Files size: 2.8 MB
For brand guidelines, please click here
Whenever engineers discover a new security issue, the question arises every time: is this an exploit or vulnerability? What is a software vulnerability? How does it differ from an exploit?
A vulnerability is a gap in the armor or weakness that allows people to enter. The exploit is the mechanism that someone uses to get in. For example, a door with a fragile lock has a vulnerability. The exploit uses the keys, hammer, or lockpick to break the lock. Let’s explore these definitions and look at some recent security incidents.
A software vulnerability is some weakness in how a piece of software has been built. These come in many different forms, but some of the most common are:
These vulnerabilities are the first port of call for a hacker, and this is what takes up the majority of a malicious agent’s time. Examples of these exploits are the Log4Shell vulnerability, the GHOST vulnerability, and the Pwnkit vulnerability. Malicious agents hunt for these known vulnerabilities, looking for some gap in your application, from which they can launch a more sophisticated attack by using an exploit.
There is another, more subtle distinction, when reviewing the question of exploit vs. vulnerability. A vulnerability might not have obvious relevance in a security context, but the exploit almost always does. An exploit might be as simple as allowing you to log in using a specific protocol or a new feature that saves your details in a central database. This is the problem: a vulnerability is any configuration or code that can be misused unexpectedly. This makes it very, very difficult to write vulnerability “free” code.
An exploit is some malicious code used to take advantage of a vulnerability. Most exploits have a set of common goals:
For example, the Log4Shell vulnerability was a weakness in how the Log4j program allowed users to execute arbitrary code based on values that should have been printed in the logs. This was an example of poor input sanitization. Many different exploits were subsequently implemented that attempted to use this vulnerability in different ways – some of them allowed you to plug in your own code while others exposed the private environment variables of the software.
A zero-day vulnerability is a vulnerability that is made public without a patch already available. This means that you have zero days to fix it. Zero-day vulnerabilities are a currency unto themselves, and there are black markets that will trade these vulnerabilities before they are ever made public.
The aforementioned Log4Shell vulnerability was an example of a zero-day vulnerability because it became common knowledge before a patch was implemented and was already being used in production code. When we’re assessing exploit vs. vulnerability, this is important to understand. A vulnerability is a weakness, so a gap in the armor was presented to the world before any fix was available. This is why Log4Shell was such a big event. It was a gap in almost everyone’s armor, and it was shown to the world before they could do anything about it.
Another example is the Heartbleed vulnerability, which allowed attackers to read protected memory areas over the Internet. This was a vulnerability detected in the OpenSSL libraries, and meant it had been proliferated amongst software for years.
Staying one step ahead of a cyber attack is an ongoing battle, with more sophisticated exploits built for more nuanced vulnerabilities. There are a few things engineers can do that will significantly improve their security posture.
Software is rarely wholly original. Most commonly, it’s a tapestry of open source and proprietary software that has been linked together with custom code. This means that one of the most effective ways to minimize vulnerabilities is to keep all of your dependencies up to date. This will ensure that you aren’t caught out by any legacy vulnerabilities that may be hanging around in your software.
Red-teaming is the practice of hiring engineers to attempt to hack into your system. Your blue team will then actively try to defend against these attacks. This is a brilliant exercise because it helps your engineers become more aware of their system, weaknesses, and strengths. It also helps to establish ways of working when the organization is truly under attack. A more thorough alternative is to pay for an external penetration test, where a highly trained security specialist will attempt to find and document the major weaknesses in your system. A combination of these two strategies gives you an excellent understanding of the major weaknesses in your system.
Static code analysis allows you to dive deep into your code base and look for any code patterns that may indicate the presence of common vulnerabilities. For example, a code snippet that looks like this may trigger a flag for a SQL injection vulnerability:
String sqlQuery = “SELECT * FROM “ + table + “ WHERE VAL LIKE ‘“ + input + “‘“
Code scanning takes some of the burden off of your software engineers and automates some of the more mundane code checkings. However, it doesn’t completely lift the burden, and more complex vulnerabilities still need to be investigated to ensure they don’t pose any risk to your security posture.
Once you’ve got some tremendous preventative strategies in place, you need to look at how you defend an attack in progress. The component of your system that will be integral to your success is your observability stack. Knowing precisely what your system is doing is essential to understanding when something is happening out of the ordinary. Whether you’re detecting a DDOS attack or noticing some unwanted IP addresses, it all begins with an effective, well-built, thorough observability function.