Skip to content
RESEARCH INDEX BREACHROAD / INTELLIGENCE NOTE

From ARPANET to Ransomware: Cybersecurity Milestones

From shared computers, Creeper and the Morris worm to ransomware, zero trust and cloud security. Explore the incidents and standards that shaped defence.

PUBLIC RESEARCH
AUTHOR
/ Pentester (OSCP, PNPT)
PUBLISHED
14 March 2026
READING TIME
17 min read
TOPIC
History
From ARPANET to Ransomware: Cybersecurity Milestones

The history of cybersecurity is a history of expanding trust boundaries. At first, defenders protected processor time and files belonging to several users of one computer. Networks allowed a defect to spread remotely. The Internet exposed services to the world, phones moved identity into every pocket, cloud infrastructure turned configuration into code, and software supply chains made one dependency a trust decision for thousands of organisations.

This timeline is not a gallery of famous hackers. It follows how incidents and standards changed defence: from access control and cryptography through incident response and vulnerability management to secure by design and continuous identity verification.

Major cybersecurity milestones

YearEventDurable change
1960–1970Time-sharing systemsUser separation, passwords and permissions
1971Creeper and Reaper on ARPANETSelf-propagating code becomes a network problem
1976–1977Diffie–Hellman and DESCryptography enters open research and standards
1983–1984Fred Cohen’s experimentsThe computer virus receives a formal definition
1988Morris wormA major Internet crisis leads to CERT/CC
1995–1999SSL 3.0, TLS 1.0 and CVEProtected communication and shared vulnerability names
2000ILOVEYOUEmail, social engineering and automation create a global epidemic
2010StuxnetCode sabotages a physical industrial process
2014HeartbleedA cryptographic-library flaw exposes dependency risk
2017WannaCry and NotPetyaExploit, worm behaviour and destruction disrupt the world
2020–2021SolarWinds, Log4Shell and Colonial PipelineSupply chain, open source and identity become central risks

Security before the Internet

Early computers were expensive and shared. Users connected to one machine, making process, memory and file isolation the core problem. Authentication, access-control lists and privilege levels aimed to stop one account from accidentally or deliberately affecting another.

In 1975 Jerome Saltzer and Michael Schroeder described design principles including least privilege, fail-safe defaults, complete mediation and avoiding security that depends on design secrecy. The same principles appear in zero trust, sandboxes and cloud architecture. Tools changed, but the questions remain: who is asking, for which resource, under what authority, and is every operation checked?

Creeper, Reaper and code moving across a network

Creeper ran on TENEX systems connected to ARPANET in the early 1970s, moving between machines and displaying a message. Calling it the “first virus” without qualification is misleading: it was not destructive and current terminology came later. It remains an important early example of software transporting itself through a network.

Reaper was created to locate and remove Creeper. This miniature episode already contains both sides of modern security: automated propagation and automated response. The full progression appears in our history of malware.

Cryptography moves into public standards

Whitfield Diffie and Martin Hellman’s 1976 “New Directions in Cryptography” described establishing a shared secret across a public channel and introduced public-key concepts. The US National Bureau of Standards published DES as FIPS 46 in 1977. Rivest, Shamir and Adleman described RSA in 1978.

These developments transformed network security. Parties without a pre-shared secret could establish protected communication and sign information. They did not remove the identity problem: a public key must still be reliably associated with an entity. Certificates, certificate authorities and PKI address that binding. The history from DES and RSA to AES and TLS explains the technical sequence.

1983–1984: a formal computer-virus definition

In 1983 Fred Cohen conducted authorised experiments with a program that attached to other programs and made them capable of further replication. His 1984 paper “Computer Viruses — Theory and Experiments” formally defined the problem; Leonard Adleman suggested the name “virus.”

Cohen also explored fundamental limits of detection and defence. No simple universal test settles every possible program. This foreshadowed the enduring cycle: signatures identify known patterns, attackers transform code, defenders add heuristics and behavioural analysis.

1988: the Morris worm creates CERT/CC

On 2 November 1988, a worm written by Robert Tappan Morris spread through the early Internet. It used flaws in sendmail and fingerd, trust relationships and password guessing. A mechanism intended to avoid skipping an infected machine caused repeated copies and resource exhaustion.

RFC 1135 records the response by teams at Berkeley and MIT and the use of analysis, communication and patching. The crisis exposed the lack of a formal coordination centre. DARPA asked Carnegie Mellon’s Software Engineering Institute to establish what became the CERT Coordination Center. Modern CSIRTs, coordinated disclosure and cross-vendor incident handling grow from that need.

The 1990s: networking becomes a commercial product

Commercial Internet use increased services, users and financial incentives. Firewalls separated trusted from untrusted networks, although perimeter architecture assumed that the inside was comparatively safe. Scanners and intrusion-detection systems automated discovery of known patterns.

SSL and then TLS 1.0 in 1999 protected client–server confidentiality and integrity. The same year the public CVE List launched with 321 records. Different tools previously used different names for the same flaw; a common identifier enabled correlation between advisories, scanners and patches. The history of CVE, NVD and KEV explains why identification is not prioritisation.

2000–2009: mass malware becomes an industry

The ILOVEYOU worm spread through email by combining an attractive lure, executable script and access to a victim’s contacts. Its lesson is not merely that a person clicked. Hidden extensions, easy script execution, broad permissions and automated address-book access converted one click into an epidemic.

Botnets, banking trojans and access markets then formed a cybercrime economy. SQL Slammer in 2003 propagated at extraordinary speed through a single UDP packet, while Conficker combined exploitation, weak passwords and removable media. Defence moved beyond antivirus towards patch management, segmentation and network telemetry.

Stuxnet turns code into physical effect

Disclosed in 2010, Stuxnet was a multi-stage operation targeting industrial systems. It used several vulnerabilities, could bridge through removable media, modified PLC logic and concealed changes from operators. The malware history shows why OT security requires knowledge of the physical process, not only Windows endpoints.

Executives could no longer plausibly treat cybersecurity as an isolated IT concern. Software could affect production, energy and human safety.

Heartbleed, WannaCry and NotPetya expose shared-component risk

Heartbleed in 2014 was an out-of-bounds read in OpenSSL’s heartbeat extension. A request could induce a server to return fragments of its own memory. A flaw in a widely used library revealed how much digital infrastructure can depend on a small open-source project.

In 2017 WannaCry combined an SMB vulnerability with worm propagation to spread ransomware automatically. NotPetya used some related techniques, but its design and outcome were destructive rather than recoverable through payment. The ransomware defence guide and vulnerability-management process show why an available patch is not the same as a patched estate.

2020–2021: identity and supply chain become the perimeter

Compromising the SolarWinds Orion build process delivered malicious code through a trusted update. Log4Shell demonstrated dependency exposure that many organisations could not inventory quickly. The Colonial Pipeline intrusion involved access through a VPN account without MFA and led to an operational shutdown.

The shared lesson is that a network perimeter is insufficient. Identity, device, artefact and context must be verified. Zero trust does not mean distrusting colleagues; it means removing permanent technical exemptions merely because a request originated “inside.”

The same principles return in cloud and AI

Cloud platforms move control into APIs and configuration. One overly broad IAM permission can replace the exposed port of an earlier era. Infrastructure as Code makes controls repeatable but also repeats mistakes. AWS IAM penetration testing and control-plane logging are today’s equivalent of privileged-account review.

AI adds probabilistic behaviour. Prompt injection shows how data can be interpreted as instruction. An agent with tools links uncertain model output to a real privilege. The answer is historically familiar: least privilege, complete mediation, separation, monitoring and fail-safe defaults.

Durable lessons

  1. Connectivity increases blast radius. Segmentation and egress limits still matter.
  2. Identity is an attack surface. Phishing-resistant MFA and account lifecycle are foundational.
  3. A shared component creates shared risk. Maintain dependency inventory and update ownership.
  4. Detection without response does not protect. Alerts need a rehearsed process.
  5. Security must be designed. Patches cannot repair a trust model that grants too much by default.

Frequently asked questions

What was the first cyberattack?

There is no undisputed answer because definitions vary. Creeper is an early network-moving program, Cohen’s experiments formalised the virus, and the Morris worm became the first major crisis of the connected Internet.

Why was the Morris worm so important?

It showed that automated code could disrupt a large fraction of connected systems while the community lacked coordination. CERT/CC was created in direct response.

Is cybersecurity improving if attacks keep increasing?

Many mechanisms are far more mature, but the number of systems, dependencies and value of digital operations have also grown. More incidents can reflect greater exposure and attacker incentives, not simply weaker individual technologies.

Sources

History shows that neglected fundamentals return in every new platform. Book a penetration test to examine real attack paths, not only checklist compliance.

SHARE / COPY