I am an advocate of secure code, but I am also a realist and readily admit that I don't believe fully secure exists.  As hard as we might try to write secure code there is someone with more time and more to gain by finding ways around it.  So, organizations should code applications as securely as possible, but never rely solely on that for application security.  In the quotes above, SANS recommends several 3rd party tools to help identify weaknesses in code and I am in complete agreement that knowing where you're weaknesses exist is a step in the right direction toward securing those weaknesses.  I think the most compelling argument against trusting secure code was also stated above and I will quote it again.

How do you verify this?  Who is willing to wait for 3rd party software vendors to fix web application code in their software?  Will they fix it immediately or wait until the next patch or even the next release?  How long must your organization accept an open public facing vulnerability?  Do you take your application offline until it is fixed?  Do secure coding tools or practices protect these applications in your production network? I think not.  

Source code testing tools, web application security scanning tools, and object code testing tools have proven useful in securing application software, along with manual application security penetration testing by testers who have extensive programming knowledge as well as application penetration testing expertise.

 As I said previously, some of the mentioned tools do help organizations move closer to application security.  Knowing you have a problem is the first step in fixing it.  I've recently worked closely with Web application vulnerability scanners.  These tools are quite effective at finding vulnerabilities, but admittedly, have no solution to protect the issues that are found.  Almost all of the vulnerability assessment vendors have or are beginning to partner with Imperva Inc. to automatically feed vulnerabilities into the SecureSphere Web Application Firewall and close the gap between the first step "Knowing you have a problem" and the final stage of solving the problem and mitigating the risk or vulnerability.

Organizations should protect web applications by deploying web application firewalls that inspect all traffic flowing to the web application for common web application attacks, including but not limited to Cross-Site Scripting, SQL injection, command injection, and directory traversal attacks. 

As with the quote above, Web Application Firewalls (WAF) are the only mitigating solution for web applications that can keep up with changing attack techniques and web application changes and growth. It's only in this one section on Web Application Firewalls that SANS uses the word "Protect" in conjunction with applications and it's for a very good reason.  All of the code review, monitoring and scanning techniques they mention work to increase security, as much as possible, but as they say, it's only with a WAF that you can provide the protection required.

It's critical to point out, that a WAF that cannot block traffic 'real-time' should never be considered a protective/mitigating solution.  These types of non-real-time blocking WAFs are monitors at best and have limited or no protection capabilities.  I state this, because I hear confusion when speaking to some organizations about whether they need to block or not.  If you know you have a vulnerability and know where it is, you should absolutely implement a blocking solution, at least, for that part of the web application, preferably for the rest of the site, as well, considering, where there is one vulnerability there is likely to be others you don't know about.

For applications that rely on a database, organizations should conduct a configuration review of both the operating system housing the database and the database software itself, checking settings to ensure that the database system has been hardened using standard hardening templates.

Almost all web applications rely on a back-end databases these days.  Data security is our focus at Imperva and we have known from the beginning that the database is the target of the attacks that this Critical Control #7 is focused on preventing.  Imperva Inc. is the only organization to provide complete monitoring and protection for both the web application and the back-end database that houses everything the criminal wants to steal.

I hate being long winded and yes my fingers are hurting, but remember this.  Source code review and code scanning is just that, a review of the code.  It does nothing to protect web applications and certainly does nothing to protect 3rd party web applications, of which there is some in almost every company.  Vulnerability assessment/scanning products are effective at finding vulnerabilities, but have no ability to prevent attacks or protect web applications out-right, however, these vendors have begun to partner with Imperva Inc. to provide an automated scanning solution that can seamlessly feed found vulnerabilities into Imperva's SecureSphere WAF to protect web applications where they need it. Lastly, to meet SANS complete control requirements, SecureSphere provides not only the WAF solution required to protect the web application, but also the recommended database protection to protect the actual target of web application attacks - the data. 

I was at home the other day thinking about whether I should cook dinner or order out.  As with most of those people I know, 'order out' almost always wins, as it did in this case.  Even though it wasn't football season, pizza was on my mind with regular crust, pepperoni, black olives and of course, jalapeños.  I have an account online with a chain pizza company, so I logged in, selected my usual and went to check-out.  I selected credit card as my method of purchase and entered my card number and usual three to four digit CVV/CVC code on the back of the card.  None of this is abnormal, but when the pizza delivery person arrived with my pizza he asked to see the card and proceeded to swipe it through an old school carbon copy device.  I stopped him and asked why this was necessary, to which he answered, "Our online system is not working right now, so we have to swipe the cards manually".  Call me paranoid, but I didn't like this change of plans, nor did I like someone I didn't know walking away with a copy of my credit card in their back pocket.  So I called the manger and got approval to pay cash instead.  But this started me thinking.

How is the credit card carbon copy any different than a standard purchase online?  Do I know who has access to my data?  How will my data be used within the company?  How effective are the company's data security policies?  Has the company had data breaches before?  

Of course, I had none of these answers about any of the companies I purchase from, so I went on to work through a short exercise to see how many times I share my credit card with others without knowing much or anything about how the data will be used or protected.

There are certainly days when I don't use credit at all and others when it's all I use.  For the purposes of my exercise I chose a few days during work travel to Hong Kong.

1) Airline check-in - I swipe my credit card to identify myself to the automated kiosk check-in.  Do they stored any private data from that, clearly the airlines authenticate me via the card at the very least.

2) Breakfast - My flights to Asia depart in the morning, so Starbucks, swipes my credit card for purchases.

3) ATM - I hit my bank's ATM make a modest withdrawal for the trip - Debit/credit card usage.

4) Hong Kong Immigration - My passport is provided and scanned, and my completed arrival form is entered and stored.

5) Train Ticket - Purchase express train ticket with credit card.

6) Currency exchange - Passport must be provided and scanned.

7) Hotel check-in - Credit card and passport must be provided and information collected.

8) Dinner in the city

My personal solution:

As I said, there are days when my private data isn't shared much and days when it's shared frequently. The point of this exercise for me was to identify places or times when I could avoid sharing my information and hopefully minimize my risk of data theft by paying with cash.  If I can minimize the companies that receive my personal data, it makes selecting which companies that are 'Card Worthy' easier.  For example, I only use banks that I know have better data security than most and I try to only purchase from companies who I know have security measures in place to protect my data.  

Sadly, lists of secure companies are not easily available for most consumers.  Consumers can however consider whether companies with prior breaches should have their business.  I'll also note, that many companies that have a breach, if they survive it, usually try to correct the problem that lead to the breach.

Below is an article from the Privacy Rights Clearinghouse that lists a chronology of data losses since 2005.  I sometimes search this list if I am considering a new bank or major purchase.

http://www.privacyrights.org/ar/ChronDataBreaches.htm#CP

I also, regularly monitor my credit card statements and have informed my credit card companies to keep my accounts in a high risk fraud category.  This high risk category does present some frustrations when making unusual purchases, but nothing compared to having your identity stolen.

I don't carry any more cash on me than I did previously, but I will likely visit my ATM more frequently as I spend less with my credit card.

On a recent visit to Asia I had the opportunity to sit with many of our regional partners to discuss IT security regulations specific to web applications and databases.  There was no surprise that PCI was at the top of the list followed by SOX for some international companies, primarily American, and then a short list of ISO and country specific regulations.  Each partner I spoke with talked about a different local requirement usually still being defined or just about to become officially enforced.  In each case I received the same question, "Will SecureSphere support the legislation?"

The short answer I gave them all was the same.  If the legislation requires web application security and/or monitoring, and/or defines requirements for securing and/or monitoring database and data access, the answer is 'yes'.  The reality that I have experienced so far has been that while there are various data security regulations, they all typically require the same fundamental output.  Data privacy regulations, regardless of the industry or country, at a minimum, require complying organizations to restrict and/or monitor (audit) who has access to, and to what degree they have access to, the data that must be regulated.

  Jimmy Private Data

This, of course, is quite easy for SecureSphere since it has the ability to secure and monitor (audit) any aspect of database and application activity.  All that is required of the administrator is to know what elements of data access should be monitored to comply with the regulation and to configure SecureSphere to secure and/or monitor that activity.  Of course, SecureSphere is pre-configured with the most common regulations, but as I say, it can be easily configured to meet even the most obscure legislation.

The most common current Asia regulations I identified are below:

PCI

SOX

J-SOX

K-SOX

ISO27001

As I stated above, there are some regulations in development for various countries, but they have yet to be ratified.  Additionally, some countries have existing regulations, but have yet to include IT data to the requirements and are still very much focused on the 'paper' books rather than electronic data.  Having worked extensively in various locations around the globe, it's always interesting to see the considerable differences from region to region and country to country.

Ellen Messmer, at Network World, published a short, entertaining article about an unemployed Russian system administrator who hacked into a giant public billboard on a Moscow street, replacing the advertisement with a pornographic movie.

…Interior Ministry's high-tech crime unit says the suspected billboard hacker is a 41-year-old unemployed man who police believe used the IP address of an organization based in Chechnya to breach a Moscow server…

Needless to say, this stopped traffic both on the street and on the sidewalks stuffing them with gawkers and cell phone videophiles.  Considering the ‘rubber-neck’ traffic created by someone changing a tire where I live, I can only imagine the backup caused this incident.  Taking the security of the billboard server and public safety issues of stopping traffic aside, this article underscored for me the idle hands environment we find ourselves into today with unemployment rates steadily rising. 

Statements attributed to police sources says the hacker was breaking into computers out of curiosity and had admitted to the stunt, which he allegedly said was an effort to entertain

At least in this case, the alleged intent was curiosity and entertainment rather than data theft or destruction. I also consider the distribution method in this case and how the billboard could have been made to show healthcare information, credit card numbers, private financial data, etc…

Network World's reporter Ellen Messmer published an article today about an Oracle vulnerability identified by David Litchfield for the purpose of refuting Larry Ellison's claim that his database was "unbreakable".

David Litchfield, a researcher at NGS Consulting, demonstrated how a user can subvert security to elevate his privileges to take complete control over Oracle 11g and also showed how to bypass the Oracle Label Security used to set mandatory access controls over information depending on security level.

The security-industry veteran said ever since he heard Oracle's chief Larry Ellison touting his database as being "unbreakable, I took umbrage at that." Litchfield noted he and Oracle have had a "rocky relationship" for a long time.

Mr. Litchfield is targeting Oracle in this case, but most database vendors make similar efforts to calm their user's fears of vulnerabilities.  The DB attack discussed is an example of the challenges that database vendors face when trying secure their own code.  Databases are large complex software packages and to expect them to be inherently secure from the vendor, regardless of CEO comments or promises, is risky.