Information Security is an ancient field, with its earliest recorded origins pointing to Julius Caesar himself. Keeping sensitive information secure is obviously nothing new, but the techniques used continue to get overhauls every few years as our world and technology continues to innovate.
Web Application Security is of course only as “old” as web apps themselves. But to read the history of Information Security and Web Application Security Testing is not only fascinating, but can also be massively helpful in helping create a more secure future. So, without further ado, read on for a brief history of security in general and application security testing in specific.
The modern history of security testing goes further back then you might imagine.
The Second World War saw the first instance where military information was sent over computer systems, only to be stolen and decrypted by the enemy. The Bombe, which was actually first created by the Polish to break Germany’s messages sent through the Enigma machine, was adopted by the British and later the Americans, as they tried to stay ahead of the next attack. The Bombe can be considered the first penetration tool, and though its’ antiquated technology is no longer used today, many of the security concepts from this era are still around and in use today.
Information Security was a fast-growing field as early as the late 60s. The number of security experts was small, but because of the highly-sensitive industries computers were first used in – aerospace and the military, primarily – security concerns quickly became important.
The Cold War spurred advancements both in technology and security. Sputnik’s launch pushed the US to create ARPA, renamed later to DARPA (Defense Advanced Research Projects Agency) in order to help spur innovation. DARPA would later go on to “create” the internet.
NASA was also instrumental in these early days of computer security; The teams set up at NASA to test computer security would go on to help the Apollo 13 lunar landing in 1970. These so-called Tiger Teams were essentially the first white-hat hackers. Manually reviewing code, the teams were known to leave messages like “busted” and “your code book has been stolen” in the systems they analyzed. They mostly used manual analysis
Another Tiger Team would, in 1973, perform a vulnerability analysis on the defense-grade Multics system. As one of Multics original creators and programmers Tom Van Fleck recalled, “and break it they did….they handed me my password on a slip of paper.”
This was the first major wake up call that systems used by governments and major enterprises could be opened to attack through their systems. The results and subsequent security enhancements in Multics would help form the foundation for the Trusted Computer System Evaluation Criteria, or Orange Book, a precursor of the Common Criteria.
In 1967, the world’s leading computer and security professionals met at the Joint Computer Conference, where major discussions about both networked systems and how to secure them were first held publicly, and where the word ‘penetration’ was first widely used. That same year, the Security Controls for Computer Systems Report was published. This paper, also referred to as the Willis Report, was the first instance of many of the guiding principles of Information Security, and though it was released decades before, also contributed to the foundations of application security.
In 1971, James P. Anderson, working with the U.S. Air Force, outlined the five steps of a penetration attack still in use by pentesters today. Penetration testing was an efficient way to find major issues in specific, sensitive code. But the growing network of computers around the world and the development being done was unsustainable with manual testing each line of code.
By 1979, automated security analysis was introduced. Lint, a tool that originally flagged suspicious code written in C and later for all languages, was released. Lint was the early precursor to modern static code testing tools, and was the first widely-used tool that inspected source code and flagged issues.
As part of the first generation of Static Code Analysis, Lint was great at finding potential bugs, yet moved slow and weren’t equipped with the full view of the program. It could only analyze one file at a time, and results were given only after the build was compiled. This first generation of AppSec tools led to a lot of false positives and while they were helpful in finding specific bugs, they were clunky and didn’t do much of a better job than manual analysis.
This is part one of a two part series. Click here for part two.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.