Network Security Is An Application Layer Issue

Part 1 of a 3 part series

For my very first assignment as a consultant I traveled to a top 25 metro market to a school district that believed they had been hacked. Back then, I was just a developer who had read some white papers on security. But that put me at the top of the rotation in our midsized consulting firm.

What I found when I arrived was shocking in many ways, not the least of which was the ease of entry provided to those who would do harm. **Spoiler Alert** It was nothing more than a SQL injection attack facilitated by a text entry box with no input validation in a web form, which allowed an outsider to create a series of accounts on the SQL server and subsequently the physical server, and grant themselves Domain Administrator access across the network.

The damage caused was mostly superficial, and some egos in positions of authority were bruised. Things were cleaned up, and some security measures added to the web application. And while I continued on as a developer, architect and manager, that experience placed me squarely on a parallel path of focusing on security.

Let me say clearly, I am not a “hacker”. I do not have the deep skill set required to be a true hacker, and in truth those people are relatively rare, and are almost impossible to completely stop in today’s technological landscape. The other end of the spectrum are “script kiddies” who buy or find executable scripts and use them to gain entry and cause mischief, but generally do not have the aptitude to really exploit the vulnerabilities they uncover.

Somewhere in the middle is the much larger percentage comprised of professional exploiters. They have various degrees of skill in programming, the willingness to do harm and the mindset to profit illegally from the weaknesses they find. They are the ones exploiting networks to gain financial information, personal information, proprietary business data and intellectual property, all of which are money makers on the black market.

Just how easy is it? Over the years, partly because I have some experience in the topic, and partly because I am reasonably proficient at public speaking, I have been asked to speak to various groups on the topics of application performance and security. In one specific endeavor, I was a guest lecturer for a graduate level program in public administration on the topic of application and network security. As part of the presentation prepared for that audience, I would ask the class to shout out words. The first word I heard clearly, I would enter into Google. With the screen projected for the class to see, I would click on each link and attempt a SQL injection attack on the resulting website. (note – it was never a malicious attack, just an simple command to see if the vulnerability existed). If the website rejected that simple attempt, I would move on. In five years, presenting 2 or 3 times a year, I never made it to the second page of results before finding a vulnerable website.

And as these were Google results, for simple common words, they were all high profile, big visitor count websites, e-commerce, corporations and government entities. The demonstration never failed to bring the class to absolute stillness. Stunned, open mouth staring was the general response. People could just not fathom big public websites with a known vulnerability so easy to exploit.

As we rapidly approach 2015, and high profile data breaches seem to occur weekly, I encourage you to try a simple test of your own. Go to any website, any web form, and type any word in a textbox followed by a single apostrophe (‘). Websites can handle that a variety of different ways, from filtering it out, to not executing at all. However, if you get a screen with an alert for a database error, chances are the system is vulnerable to a SQL injection attack.

If you are a manager in any IT capacity, and have not mandated a few simple steps to protect against these kinds of threats, it is a potentially career ending mistake waiting to happen. Even if the application in question is internal, active measures must be taken.

Common steps to reduce vulnerability:

• Set the maximum character length to the shortest possible value that allows valid entries.
• Validate data types. Dates should be dates and numbers should be numeric etc.
• Filter out non alpha numeric characters from text entry boxes.
• Where possible, use Regular Expression pattern matching to validate phone numbers, email addresses, zip codes, etc.

Dozens more Security Best Practices exist and can be incorporated into daily activities. But in the overwhelming majority of organizations, they are either not made policy or not enforced. Partly due to the effort required, the mentality of “get it working, then go back and clean it up” and partly due to the entire organization passing the buck with the attitude that Security is someone else’s job.

With those challenges in mind, here is a strategy that will work and can be implemented across the board. We live in an Object Oriented world. Regardless of the language or the system;

• Define a class that inherits from the base text box
• Default the character length to “0”
• Default validation to one of an enumerated list of validation classes.
• Default input type to one of an enumerated list of entry types (numeric, alphanumeric, password etc)
• Use the class as designed, or inherit it to further refine for specific use and data types;
  • Email
  • Password
  • Date
  • Phone

For an implementation strategy;

• Require the new class be used in all new development.
• Require the class to be used in all updates or edits to existing code.
• Set aside budgeted hours for updating legacy code.

Discussion:

Is this a “Silver Bullet”?

No. Much more needs to be done. But this is a starting point that not only has a direct and significant impact, but makes security a component of every design and architecture discussion, as well as a part of the daily life of developers.

Will it solve the entire problem of application security?

No. It is simply the first piece of “low hanging fruit” that is easy to implement and easy to monitor for compliance. And as such cost effective.

When should this be implemented?

Yesterday

Is this an oversimplification of old ideas?

Yes. To the extent that there is literally nothing new or groundbreaking in the ideas put forth. But given that it is so infrequently implemented, it bears repeating in plain language.

Whose responsibility is this?

In a word, “Yours”. If you the reader, are involved enough with technology to have bothered to read this, then you have a stake in the topic.