Security is good. Security is necessary. Security is someone else's
concern. Security is for our CISSP engineers to focus on in their dimly lit
rooms with their lava lamps and empty Red Bulls stacked to the
heavens. It's an ugly business, and making sense of it requires
professionals with years of experience and dog-eared certificates. It
has become an industry unto itself and frightens politicians to adopt
far-reaching policies that stoke the smoldering furnace of paranoiac
innovation. We attend Hacker conferences and Security summits to
behold the latest zero-day vulnerability and poke fingers at the
developers who fail to create secure software.

We are Systems Administrators. We are Web Developers. We are
Database Engineers and Storage Architects and Pointy-Haired Bosses
with hard copies of Schneier's
blog littering our desks. We've been told before that Security is
our mandate, but to what end? We have heeded the vendor patch
announcements and updated our servers. We comply
with PCI
requirements and pass the Nessus scans. We've studied the
latest OWASP
Top 10 list and applied its principles to combat the cross-site
scripting attacks and SQL injections. Haven't we? Sure we have! Or
have we? Have I, as a Systems Administrator, considered the
implications of the AJAX interface written by the dev team? Has the
DBA considered the impact
of an exploit in the chrooted webserver? Have our PHP developers been
in touch with the SAN
administrator to ensure that he has the capacity to withstand
unlimited file uploads, and what effect that might have on our
encrypted volume?

A secure infrastructure is not a zero-sum game. While applications
on the Internet have become more complex and availability has
increased, so have the attack vectors and their impact on the rest of
the application stack. We've long recognized that an OSI-centric approach to
security is a losing proposition. Firewalls are no longer considered a
panacea for network attacks. Modern intrusions exercise multiple
layers of the defense perimeter. Engineering secure applications
becomes akin to a round
of Jenga; how many pieces
can we lose before the structure collapses? A cohesive approach to Web
Application Security mandates a holistic approach across the entire
engineering organization. But how many of us think beyond the edges of
the envelope that defines our professional skills and aptitude?

Most of us gain our skills through a function-oriented approach. We
learn repeatable steps that culminate in the desired result. Often
this includes a period of trial-and-error where we assimilate aspects
of the misstep and adapt to avoid the failure condition. This is only
natural and is reinforced by our trainers or educators in order to
attain the prescribed goals. However, these tactics can also be used
to seek out the stress points within a system. When you increase your
knowledge of the entire application stack, you reveal "opportunities
for efficiency" by understanding the relationship of each component to
the whole.

Unfortunately, the churn of modern software development fosters a
"feature-first" mentality. We're all familiar with the
process. Marketing or Project Management determines the feature set
that will drive purchases and upgrades for the client base. Deadlines
are aligned with revenue cycles rather than product maturity. In the
end, Developers feel the squeeze from Project Managers focused on
their calendars and from Customers, frustrated by another release as
unwitting QA test subjects. Engineers are forced into specialization,
becoming a cog with a narrowed focus. Our aperture begins to close,
decreasing our exposure to the application stack and impeding
interoperability with other project teams and departments. Although
we've entered the Information Age, popular software engineering
practices are still rooted in the assembly line mentality.

The birth of secure software requires more than a commitment to
correct code and elegant program design. A sort of Renaissance man is
needed, a polymath who familiarizes himself (or herself) with the
belts and pulleys of neighboring components. Someone who has a passion
for the whole system. Orthogonal studies should become a desired
trait, not a distraction. Database Administrators, Network Engineers,
Java Developers and Systems Administrators working in harmony.

Hackers, in the acceptable sense, are a strange breed. By
definition we enjoy the art of deconstruction. We want to know what
makes things tick. Perhaps it's something in our biological blueprint
that drives our thirst for knowledge. We have an insatiable curiosity
for understanding the misunderstood or unknown. An expensive hobby,
for certain. Whether that price comes in the form of relationships,
money or spare parts, it matters not. The knowledge of how that system
works is compelling enough to hold our attention for hours and days
and weeks and years.

Or maybe we just like breaking stuff.

After an attack, it's only natural to wonder what motivated the
attacker to focus on us. We comb through the evidence looking for the
exposed stress points. But to focus on the bugs is to ignore the
problem and merely serves to reinforce the broken processes. The same
vulnerability will crawl out of a different hole next time. It will
wait for the next hacker. And they will come. The hacker has already
created new tools to make it easier next time. The hacker is
generous. He likes to share his toys with his hacker friends.

Engineering teams with a foundation in "whole system" design stand
a better chance of resisting and recovering from attacks. By studying
different layers of the application stack they gain an understanding
of the operational complexities and attack vectors. They can predict
vulnerabilities in the design and planning phases. They can isolate
exploits faster and pinpoint failures in unfamiliar regions. New code
becomes inoculated by the changes in philosophy. Junior programmers
and administrators pass these principles on to their peers. A new
Renaissance begins.