Hacker Curriculum Principles

To meet the challenges of modern computer security practice, students must be able to switch from their conditioning by traditional computer science and software engineering curricula to a more adversarial mode of thinking. Over the years, the hacker community has produced an informal but highly coherent and efficient “curriculum” that approaches the same topics as the traditional curricula from a variety of unusual angles. Far from being a haphazard collection of ad-hoc “hacks,” this curriculum exhibits complexity and has rich – although often implicit – structure.

We seek to have a conversation stemming from our lessons applying Hacker Curriculum principles to the education of Dartmouth students and interns, in professional partnerships to help secure Dartmouth’s production networks, and within our campus-wide Cyber Security Initiative (CSI) and the Secure Information Systems Mentoring and Training (SISMAT) program. We make two observations:

  1. The hacker community has developed "cross-layer, cross-field" methods of approaching computer systems that we can and should learn from, and
  2. We should not be afraid to trust talented people who have a way with technology; instead, we should give them something interesting to work on.

Principles (Work-in-Progress)

We are trying to name the engineering and system analysis patterns that hackers tend to use; feel free to take issue with a particular name or description. We notice that most of these principles express themselves in particular attacks or analysis that actually links back to fundamental computer science computability theories and principles via the composition of trust (i.e., expected behavior) in a particular combination of systems or algorithms.

Injection, Inspection, Isolation, Composition, …

The Injection Principle

Achieving the ability to inject bits, errors, commands, or data on control and data input and output channels.

Finding control and input injection points, grammar, and constraints

The Inspection Principle

(i.e., Anti-APIs: seeking understanding at a depth greater than tool GUIs and language APIs)

(perhaps: The Detour Principle?)

The Fuzzing Principle

discovering the boundaries of input formats for network messages and files

The Modeling Conjecture Principle

how we envision a designer made choices between several reasonable alternatives

The Configuration Principle

understanding how configuration affects various operating modes

The Tracing Principle? (more than just configuration)

The Visualization Principle

Build a model of what's actually happening in the system rather than what the specification says.

The Principle of Co-existing or Composed Control

Alternate control streams: understanding how technologies deployed side by side (e.g., C pre-processor macros and C; DWARF and ELF) can be made to display "spooky action at a (near) distance"

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License