[WEB SECURITY] Great article outlining a core issue with many in the security community

Paul Schmehl pschmehl_lists at tx.rr.com
Tue Feb 15 10:36:08 EST 2011

--On February 14, 2011 1:19:41 PM -0500 "Vance, Michael" 
<Michael.Vance at salliemae.com> wrote:

> Where do you draw the line at what developers should know and do
> automatically and what they should only do if there is a specific,
> written requirement? Where do things get too technical for product owners
> and stakeholders to define them? We don’t expect there to be a written
> requirement to use a specific data type or array structure; why should
> there have to be a specific requirement to sanitize input using a
> whitelist? Shouldn’t that be automatic, part of “good coding
> practices?”

Absolutely....except...when it breaks the application in unexpected ways, 
then the developer has to explain why he chose the path of input 
verification over functionality when that wasn't in the specs he was given.

Recently we were asked to open some ports on our firewall so some folks 
could engage in online multiplayer games.  When we asked why that was 
needed, the answer we got from the game vendor was, "Other universities 
have done it, and the game works."

Mind you, they want these ports opened to literally thousands of IP 
addresses.  (They gave us a list of 12 networks in the /21 to /18 size.)

We said no.  You tell us what isn't working, and we'll find a way to get it 
working without exposing ourselves to excessive risk.  Oh, and BTW, we can 
telnet to every port they've asked for and get a banner, so the problem 
isn't the ports they told us about anyway.  It's probably some port they 
want to open without first getting a request from a client.

Ease of use will always trump security until someone puts their foot down 
and says no.  When they do, they must be backed up by both facts and their 

Making things work **as expected** in a secure environment is a non-trivial 
exercise.  It requires a much clearer understanding of TCP/IP, networking, 
routing, applications and protocols than many people have a grasp of.  It 
also requires experience with the right tools **used in the right ways** to 
track down actual causes and suggest solutions.

That's why it isn't often done.  It's hard.  Opening the firewall is easy. 
The requestor is satisfied immediately, and there isn't that incredible 
pressure to relent _just_this_one_time so someone can get done what they 
want to do.  (It works at home,  Why doesn't it work here?)

These aren't easy problems to solve.  If they were, they would have been 
solved already.  Arguing about whose fault it is is pointless and 
non-productive.  Finding a way to blend security into technology until it 
becomes an integral part is much more productive.

Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell

More information about the websecurity mailing list