Guilty Until Proven Innocent
Perhaps guilty until proven innocent isn’t so bad an idea
after all.
It’s often been said the “lawlessness” of the Internet is
similar to the American “Wild West.” I have always cringed
when hearing that, because it’s just too much of a stretch
for me, but there’s at least one aspect of it that is worthy
of consideration when it comes to securing our data systems.
In this case, guilty until proven innocent may actually have
some merit after all.
No, I’m not talking about applying this notion to humans.
Most of you reading this live in places where the opposite
is applied in our court systems: innocent until proven
guilty. And, it’s likely we all value that principle very
highly for all the right reasons. But that’s not what I’m
talking about.
I’m talking about applying the opposite principle to shoring
up our information security practices. We already see it
applied in some places, such as setting firewall rules and
such, but we need to take it further.
In government circles, the term information assurance is
used often. We’ve also heard terms like trustworthy
computing, reliable systems, and others. For these to be
successful, they must all have at their core a common
principle of guilty until proven innocent. I’ll explain with
a few examples as well as counter-examples.
• Firewall rules. As I said above, this is a great example of applying the
guilty until proven innocent principle. Most firewalls today
are configured to only allow authorized services, and to
disallow all others. I’m sure this is mostly a result of the
security community rallying during the 1990s to enforce this
sort of positive validation model, sometimes to the dismay
of the application developers who wanted to run their
software over network services that were being blocked.
Unfortunately, we haven’t been consistent at applying the
same principle in enough other areas.
• Input validation. The cornerstone to secure software,
input validation, when done poorly is the root cause of many
of today’s most prevalent security defects. This includes
buffer overflows, cross-site scripting (“XSS”), and
injection flaws such as SQL injection. Input validation is
most often the purview of the application itself, and not
(just) the firewall protecting it. For input validation to
be as robust as our firewall rules, we have to code the
guilty until proven innocent principle into our
applications, and that’s where we all too often fail. That
is, our software must use positive validation on all of its
inputs, throwing away anything that can’t be validated on
the presumption of guilt. That, I’ve found, is a concept few
software developers take to easily, but it is vital. We’re
seeing Web application firewalls (“WAFs”) trying to ease
this burden by doing the application-layer input validation
in a separate security component (installed and configured
by the security team), but that’s not a long-term solution
for all sorts of good reasons.
• Anti-virus scanners. Here’s a classic failure of the
principle. From the earliest days of the anti-virus scanner,
a negative validation model has been used. That is, scanned
software is assumed to be safe unless it matches a signature
of a known bad thing. We’re living with this failure every
day in combating email-borne malware, viruses, etc. A fairly
recent trend has been the so-called “whitelisting” of
presumably safe applications, but that too is not a
long-term solution.
• Application vulnerability scanners. Much like their
anti-virus counterparts, vulnerability scanners, including
application scanners, use a negative model to detect bad
things on our systems and in our applications. Although this
approach no doubt finds plenty of “low hanging fruit,” it is
superficial and insufficient in the long term.
• Intrusion detection/prevention systems. Same old same old
here. The vast majority of deployed IDS and IPS
installations operate on a negative model that is doomed to
failure and at the worst possible moments—when novel attacks
are discovered and launched on our unprepared systems.
So where do we go from here? Well, let’s revisit our
principle: guilty until proven innocent. It is a design
principle that must be considered against every single
aspect of our data processing systems in order to be
effective. That means we can’t stop at just the firewall.
In my Web application security classes, I always tell my
students they must never trust anything coming in an HTTP
Request (that is, from the user). On day 1, they always
giggle or just kind of scratch their heads in confusion when
I say this, but by the time they’ve seen the likes of
cross-site scripting in action, they begin to believe. By
the time they leave the class, the number one comment I get
from them is how “eye opening” this notion was for them.
We’ve got to inculcate a culture of guilty until proven
innocent in our digital world throughout our organizations,
from our information security staff through our software
developers. Only then will our software—whether in the form
of operating system kernel code or web applications—be
resilient and worthy of trusting our businesses to.