The Role of Ethical Hackers in DevSecOps - Development Alongside Offensive Security Measures
My goal here is to provide a high-level overview of the importance of ethical hackers within DevSecOps methodologies, as well as practically explain the methodology itself. You would think that, by today, most organizations and agencies have implemented DevSecOps (or at least a similar security-centric development model) in one way or another, but that is surprisingly not always the case. As a security professional, I have been stunned more than once to witness the lack of basic security considerations even as far as basic vulnerability scanning or secure coding methodologies. These critical discoveries are primarily responsible for my shift from an analyst to a penetration tester/ethical hacker - I immediately desired to take more serious, offensive, and hands-on measures to not only patch applications and systems, but to, before the eyes of developers and system admins, attack their applications in real-time and introduce them to adversarial mindsets. I found serious vulnerabilities, and demonstrated them (with sufficient permission), and wrote reports, but I received hardly a pat on the back. As a result, and as an analyst, this was ultimately way beyond my pay grade, and I felt I couldn't do enough to implement methodologies such as DevSecOps to harden infrastructure. Analysts aren't given that kind of decision-making power. Instead of hardening systems or implementing more secure coding methodologies (or even implementing very basic security practices), priorities seemed to lie elsewhere with upper management, usually within the realm of implementing cool IoT (Internet of Things) gadgets that would improve the image of executives' impacts and legacies, while simultaneously broadening attack vectors. I believe this is why security can often take a backseat in the development process, as security itself is totally thankless unless its impact is visible, which it rarely is. Additionally, I've come across many developers who are far overstretched, severely underpaid, and constantly hounded to meet insane deadlines, typically leading to massive holes in security (at least initially). I've actually heard excuses along the lines of, "This is an internal system, there will be no real outside threats." Are you kidding me? Why are we still operating like this? Why are we surprised when entire agencies fall to ransomware? This ancient mindset highlights the importance of DevSecOps, and especially the offensive security methodologies of penetration testers/ethical hackers.
However, before discussing the importance of ethical hacking and DevSecOps (Development, Security, and Operations), we need to first revisit the traditional DevOps model and its waterfall-type methodology. DevOps (Development and Operations) is simply a methodology, or even philosophy, that is designed to reduce red tape, departmental barriers, and general time-sucks from development and deployment processes. Within organizations utilizing DevOps, software developers and deployment teams work side-by-side to develop and implement features and new ideas as quickly as reasonably possible. DevOps is an intersection of development, deployment, and operations that relies heavily on automation and constant teamwork/communication. It streamlines processes, saves resources, and is overall wonderful for saving resources, time, and delivering quality products.
DevOps sounds great, but what's the difference between DevOps and DevSecOps? On a high level, these methodologies are largely the same, with the ultimate difference obviously being the introduction and prioritization of security within DevSecOps. The trick in implementing DevSecOps is implementing security measures, tools, and automation at every single step, without choking the DevOps process by utilizing too much time or too many resources. This is why a properly trained ethical hacker (or team of ethical hackers) is invaluable to implementing DevSecOps. As with every step in the DevOps process, subject matter experts are required on every level to propel the process. We can't expect developers and deployment personnel to simply master security in addition to their previous responsibilities within the DevOps process. By introducing these experts (hackers/pen testers), the process of DevOps can flow as normal, only with a parallel flow of security monitoring, fuzzing, testing, patching, and continual maintenance. By introducing new experts, and not simply assigning a heavy load of additional tasks to the already stretched developers and IT personnel, we have not strained time or resources (or tempers), and successfully implemented DevSecOps. The only downside? The cost of labor and tools. Yes, it's easier said than done, and legacy applications may require different solutions, but it's a must for developing and maintaining new applications or systems, and should absolutely be a requirement.
So, what exactly does the ethical hacker or penetration tester do in these roles to support DevSecOps? First, let's take a look into some of the tools/techniques that developers may utilize in a DevSecOps scenario. Remember, each case is going to be different than this example, but they all share similar ideas.
Developers are largely going to rely on the implementation of tools to automate most security tools and otherwise mundane, time-consuming tasks. These tools will vary, but all utilize similar approaches; DAST, IAST, and SAST (Dynamic Application Security Testing, Interactive Security Testing, and Static Application security Testing). DAST is a very crucial step in implementing DevSecOps - these dynamic tools can check for command injections, buffer overflows, and perform other checks that are rather mundane and could take hours for humans to perform. IAST is "interactive" in that it looks at the application during runtime and performs analysis, makes decisions. On the other hand, SAST statically analyzes the source code itself for potential errors. I recommend checking out this link for more info on these approaches to DevSecOps.
Here is where ethical hackers prove their worth. These automated tasks, tools, and approaches may seem sufficient, but proficient hackers are going to be aware of these common practices, and will immediately begin searching for weaknesses that may be inherent in similar implementations. Hackers typically come from a background of development, and will be able to utilize very similar tools, except in an adversarial fashion that does not exist in the typical DevOps process. Ethical hackers are able to adapt this adversarial mindset and find holes in security that developers and their automated tools have overlooked. Misconfigurations, human error, bad credentials - these are all examples of attack vectors that cannot necessarily be detected by tools, and there's a reason misconfigurations and broken authentication/access controls are on the OWASP Top 10. Ethical hackers are a final piece of the DevSecOps puzzle that cannot be replaced by an automated tool; this is a job that relies on finding the one weakness that may have been overlooked. An overlooked, informational-level finding on a security audit could be the initial foothold that a hacker uses to pivot his/her way into the network. By employing ethical hackers, you are employing the adversarial mindset of enemy attackers, and using their own powers and tools against them.
Employing the enemy's methodology to defeat the enemy reminds me of my favorite Sun Tzu quote that I'll wrap up with; "If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself, but not the enemy, for every victory gained, you will also suffer a defeat." - Sun Tzu
