March 27, 2017 By Christophe Veltsos 3 min read

“If it’s worth building, it’s worth testing. If it’s not worth testing, why are you wasting your time working on it?”Scott Ambler, Enterprise Agile Coach

In 1999, Kent Beck’s “Extreme Programming Explained: Embrace Change,” became an inspiration for rethinking the way software was developed. Three years later, his “Test-Driven Development: By Example” further elaborated on the need to reconsider the way software is planned, how teams operate and, most importantly, the way software is tested. To date, there are over 170 books on Amazon about test-driven development (TDD).

For readers curious about the origins and evolution of the concept, the Agile Alliance posted a short timeline of the evolution of the concept with a summary of its key points.

Take Your Software for a Spin

TDD is founded on the basic premise that test programs should be developed before the functionality that is to be tested, also known as test-first development. For example, one should write test code before writing the actual code. With TDD, the test-first concept is supplemented with a focus on refactoring — revising and improving — the code base at every opportunity. In many respects, this is similar to continuous improvement cycles such as the Deming cycle.

For software developers, TDD introduces a mind shift. Instead of assuming the code works based on a few test cases in which the code performed as expected, design a series of assessments to stress test the functionality of your code. After every change to the code base, rerun the battery of tests. So instead of writing code and simply hoping it works, TDD provides developers with strong assurances.

Three Lessons to Take Away From Test-Driven Development

From a cybersecurity perspective, TDD provides us with three applicable lessons.

1. Are the Systems Working the Way They Should?

Without test programs in place, how can an organization provide assurances that its systems are actually operating normally? This concept can be applied in a business operations sphere, at the network and system levels, and in a security operations sphere. Test systems can help analysts determine whether the firewall is still properly configured and whether the intrusion detection system (IDS) is fully operational and capable of generating alerts.

The concept can also be extended to the human resources and management spheres. By testing employees’ and managers’ reactions in the event of an alert, organizations can determine whether the response is appropriate according to documented procedures.

2. Don’t Deploy Another System Until You Know How to Test It

Imagine a world in which you are able to run tests on a new system prior to deploying it into your operational environment. Not only do you have assurances that the new system is working correctly, but you also tested all the interactions this new system is going to have with the rest of your operations.

This lesson is undoubtedly one of the hardest to implement, in terms of both knowledge and resources. From a knowledge standpoint, we are at a point in history where we’re creating and deploying systems that are so complex that it becomes challenging for a single person to know how the system operates and how to test it. From a resource standpoint, putting a system through an appropriately realistic battery of tests would mean having the resources to clone a production environment, complete with test data, test systems, test networks and test security equipment.

While this lesson can be very challenging to fully implement, ignore it at your own peril. There are hundreds of documented cases in which organizations deployed patches or systems and later realized how detrimental this change was to their operating environment. Even worse, this oversight could damage the confidentiality, integrity or availability of the data housed in those environments.

3. Refactoring Your Systems and, Eventually, Your Environment

A decade or two ago, organizations still had hardwired networks, systems and applications. Today, with the advent of infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS) and applications-as-a-service, organizations are able to leverage cloud-based services to reduce costs and improve agility.

However, another benefit of everything running on software is the flexibility with which these systems can be changed. Need to define new segmented network? You can do that in software. Need to connect application A to application B? You can use software as glue.

The first two lessons provide us with tests that our organizations can run to ensure that systems and networks are operating correctly. Armed with this assurance, we can take full advantage of all that is software-defined to reimagine how our IT operational environments are implemented and further refine these environments to improve cyber resilience for the entire organization.

A Decade of Change

TDD was born out of a collective realization that we needed to change the way software was developed and tested. Similarly, the field of cybersecurity has, in the past decade, brought about a change in the way we think about layered defense in the face of determined attackers.

By leveraging these three lessons, we can mirror TDD for software development to create new ways of validating and improving the cyber resilience of our own systems.

Read the Gartner Market Trends Report on Application Security Tool Adoption

More from Application Security

Critically close to zero(day): Exploiting Microsoft Kernel streaming service

10 min read - Last month Microsoft patched a vulnerability in the Microsoft Kernel Streaming Server, a Windows kernel component used in the virtualization and sharing of camera devices. The vulnerability, CVE-2023-36802, allows a local attacker to escalate privileges to SYSTEM. This blog post details my process of exploring a new attack surface in the Windows kernel, finding a 0-day vulnerability, exploring an interesting bug class, and building a stable exploit. This post doesn’t require any specialized Windows kernel knowledge to follow along, though…

Gozi strikes again, targeting banks, cryptocurrency and more

3 min read - In the world of cybercrime, malware plays a prominent role. One such malware, Gozi, emerged in 2006 as Gozi CRM, also known as CRM or Papras. Initially offered as a crime-as-a-service (CaaS) platform called 76Service, Gozi quickly gained notoriety for its advanced capabilities. Over time, Gozi underwent a significant transformation and became associated with other malware strains, such as Ursnif (Snifula) and Vawtrak/Neverquest. Now, in a recent campaign, Gozi has set its sights on banks, financial services and cryptocurrency platforms,…

Vulnerability management, its impact and threat modeling methodologies

7 min read - Vulnerability management is a security practice designed to avoid events that could potentially harm an organization. It is a regular ongoing process that identifies, assesses, and manages vulnerabilities across all the components of an IT ecosystem. Cybersecurity is one of the major priorities many organizations struggle to stay on top of. There is a huge increase in the number of cyberattacks carried out by cybercriminals to steal valuable information from businesses. Hence to encounter these attacks, organizations are now focusing…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today