Published on
When designing systems to be impervious to outside activity, you should always aim to be at least two steps ahead of your adversaries. Whatever it is that you want to protect, whether it’s a physical object inside a safe or a digital item in a web application, understanding why someone might want it and how they might attempt to get it could potentially spare you from losing that asset — and from losing your customers’ trust, if the asset is their personally identifiable information (PII).
In order to proactively secure a system, it’s necessary to think — and sometimes behave — like a hacker. This mentality will help you locate vulnerabilities and patch them before malicious actors can exploit them for their own benefit. According to Open Web Application Security Project (OWASP) board member Eoin Keary, “You can’t build a secure application without performing security testing on it.” Although testing alone isn’t enough to ensure security, since the cyber ecosystem is always evolving, it is an important tool to ensure you’re doing your due diligence in building web applications that are resilient to attacks.
There are many scenarios in which offensive practices can be used to bolster security, both in practice and in principle. Whether you’re just beginning your security training journey and deciding which philosophy is right for you, or you’ve mastered the basics and are considering applying for a security role, it’s important to understand the distinctions between types of offensive security in testing and training and the associated terminology.
Disambiguation of Offensive Security Terminology
First, let’s go back to the basics: defensive security involves measures that keep people out, like installing an intrusion detection system, using encryption to protect data in transit, or putting up a firewall to protect a computer network. But how do you know those measures are actually doing what they’re supposed to do?
That’s where offensive security comes in. It involves using many different methods to break into a system past existing defenses.
Here at HackEDU, we use offensive security in combination with defensive security to facilitate our security training modules. Studies have shown defensive + offensive approaches to security education have better security outcomes than defensive-only education plans, mainly because they’re more motivating for learners. As the authors of the study noted: “It is easier to discover a vulnerability than to prove that there are no vulnerabilities at all.”
So what are the different ways to approach discovering vulnerabilities?
Vulnerability Testing
Conducting a vulnerability assessment is the first step to identifying security holes in any application. These assessments are usually done in-house on a continual basis using automated scanning software. The scanning software, typically referred to as Static, Dynamic or Interactive Application Security Testing (SAST, DAST, IAST) Tools, inspects applications for vulnerabilities such as Cross-site scripting, SQL Injection, Command Injection, Path Traversal and Insecure Server Configuration.
Once an initial assessment is conducted and a system baseline of functionality is defined, the vulnerability scan is conducted. Once the scan is complete, a vulnerability report is generated, which can provide indications of vulnerabilities that will require patching.
It is important to note that a scan alone is not enough to ensure the security of a system; an understanding of the configuration of the system is needed to recognize if the vulnerabilities listed on the report are true vulnerabilities that are worth taking the time and energy to patch, or if prioritizing their repair is a waste of time in comparison with more critical issues.
For more information on vulnerability assessments, we recommend the step-by-step guide on IBM’s Security Intelligence site and the OWASP recommendations of Dynamic Application Security Testing (DAST) Tools as well as free and open source tools.
Penetration Testing
Penetration testing is the most well-known form of offensive security testing. Like vulnerability testing, both types of testing have the shared goal of discovering vulnerabilities in an organization’s security defenses. But while vulnerability testing is automated, penetration testing — or “pen testing” for short — is performed manually, by a human or team of humans. These teams often start with automated scans, and it’s considered a best practice to fix the issues found by scanners first, before bringing in the pen testers.
Generally speaking, penetration tests are limited in duration and scope. One wouldn’t order a pen test on their entire organization, but rather a narrowly defined section of software or management tools.
Sometimes pen testing will involve attempting to penetrate active corporate networks in real time. During a pen test, the testers may use a variety of hacking tools at their disposal to simulate a real-world attack. They may also use social engineering, or human-to-human deception, to attempt to convince employees to pass off sensitive information like passwords, which can then be used to exploit a system.
So what’s the difference between a pen tester and a malicious hacker? The two can be thought of as one and the same, albeit with vastly different goals: a malicious hacker’s goals being malevolent from the perspective of the organization, and the pen tester’s goals being to help the organization which has requested their services.
Bug Bounty
Bug Bounty programs can be thought of as crowdsourced penetration testing. Both pen testing and bug bounty programs aim to locate vulnerabilities in applications and platforms so that the organizations that own them can fix them.
“Pen tests and bug bounty programs allow testing of applications by simulating attacks to detect and fix vulnerabilities. A pen test is a service performed by a team of consultants working for a specialised company, while a bug bounty program relies on independent hackers paid per vulnerability.” (https://www.vaadata.com/blog/pentest-bug-bounty-which-approach-to-choose-for-security-tests/)
Red Teaming
A red team is a security testing team designed to closely simulate a real-world attack in order to test the resilience of an organization’s defenses. The term originates from military intelligence communities: specifically, from war games where a red team and blue team face off in a scrimmage — the red team almost always representing the foreign adversary or offensive side, and blue team representing the defensive, or home team.
Like pen testing, red teaming’s purpose is to identify gaps in an organization’s defenses. But unlike pen testing, which stops short of eliciting a defensive response, red teaming is focused on emulating an advanced threat actor “in the wild” and assessing the blue team’s ability to detect and respond to an attack as though it was real. While the blue team will almost always be aware of the simulation, and that a red team engagement is forthcoming, some element of surprise is typically involved, which may not be readily distinguishable from a real attack. The red team may use stealth tactics, real-time evasion, or other measures from a hacker’s tool box, and often targets DevOps or end users.
As one writer from IBM’s series on offensive security put it: “One common way to describe the relationship between network penetration testing and red teaming is to think of network penetration testing as a boxer hitting a punching bag, whereas red teaming is more akin to a boxer working with a sparring partner who will counter-punch.”
Part of the confusion in terminology between pen testing and red teaming comes from casual use of the term “red team” to describe those engaging in offensive security testing, and “blue team” to describe anyone working on the defensive side. But a pen tester is not necessarily “red teaming” an organization when carrying out their duties.
Purple team
Like the color, which is a blend of red and blue, a purple team uses a process that combines the efforts from the blue team back into the offensive side. This team is generally tasked with improving organizational security and conducts exercises to help security teams better understand their stack of coverage.
Conclusion
A good place to start learning which mode of security testing is right for your organization is the OWASP Testing Guide, which is intended for use by anyone who builds software.
As Keary says, “Security should not be a black art or closed secret that only a few can practice.” It should be accessible by all and used regularly to improve upon the systems that together constitute the open web.
HackEDU’s training platform connects with vulnerability detection tools and programs like SAST and DAST tools and bug bounty programs, to offer adaptive lesson plans that are based on the actual vulnerabilities in code. This makes the lessons both relevant and timely. They are delivered from both the offensive and defensive perspectives, giving developers the ability to both understand the attackers’ mindset, and to defend against these attacks proactively.
