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.
