2012 (ISC)2 Security Congress/ASIS

I just got back from Philadelphia, Pa where I gave my poster session about creating a foundation for secure coding.

Here is my abstract and Introduction...

Abstract

Teaching secure coding in the Enterprise requires more than giving lectures to programmers about SQL injection, XSS and string vulnerabilities. It requires a new foundation and culture to be put in place for the IT Enterprise. This paper describes what foundation and culture changes need to take place before teaching secure coding.

Introduction

            Despite technological advancements, software vulnerabilities have continued to grow at an alarming rate, with the cost of data breaches becoming more significant to all stakeholders, regardless of if they are public or private, large or small.  Because of the increased cost this situation has placed on the enterprise, security has moved from firewalls, IPS, IDC, et al, to include enterprise programmers to create more secure code.  There are many sources, both online and in print, that have coding guidelines, best practices, suggestions and tips for creating secure coding; however, as good as this information is, it is worthless if secure coding practices are not integrated into the framework of the enterprise.  Not integrating these practices into the framework of the enterprise could result in the loss of data, compromise to the system, loss of productivity, and financial loss.

            The purpose of this paper is not to present another secure coding guideline for developers or another methodology such as Microsoft Trust Computing SDLC or ALM, but rather to show how a layered approach is necessary so that the complete infrastructure is firmly in place before the enterprise moves to secure coding.  Part of this layered approach will be emphasizing the need for creating a culture that will place emphasis on secure coding in the first place.  I am well aware that what I am proposing is not new; it has been suggested before many times.  However, what is being taught today in the field of secure coding does not include the attendant infrastructure that an engineer would encounter in the real world; in short, secure coding is being taught in a vacuum, devoid of the complexities of the environment in which it will operate.  My objective for this paper is to bring teaching secure coding and the practice of creating secure coding out of the classroom and shows how to integrate it into the software development lifecycle (SDLC) of the enterprise.  Software development is no longer an individual task; it is now a very large and complex process involving several teams and team members.  Understanding these basic principles and applying them to the best practices of secure coding is the aim of my paper.

Download entire paper at https://www.dropbox.com/sh/p6kba70j7uaphol/ekkN3FwLn3

ISC2 Security Congress

I have been ask to give a poster session at this years ISC2 Security Congress this year in September in Philadelphia.  My employer has graciously agreed to pay for my expense, plus I will be there for the whole conference to attend some great classes. 

https://buildsecurityin.us-cert.gov/bsi/events/1355-BSI.html

http://en.wikipedia.org/wiki/Poster_session

Code Obfuscation

Languages like C# and Java can be easily be de-compiled and now with more web applications using JavaScript we don’t even need to de-compile the code to see it.

Because of this, code obfuscators are on the rise.  One of the newest kids on the block is JScrambler (https://jscrambler.com/) made by AuditMark (http://auditmark.com/).

Code obfuscator’s work but do they provide any value? Do they add any value, for security, protecting our intellectual property, etc.?

Obfuscated code is modified on purpose to make it harder to read and making it more difficult to analysis what the code really does.  A key point here is this goal is a two way street.  It can be for someone trying to protect their intellectual property or for malware trying to prevent its detection by anti virus/malware scanners.  So our first point is obfuscated code can be used for and against us.

That brings up an excellent point. If your web site uses something like jscrambler should I have the right to inspect the JavaScript used by your web application to make sure it is not doing something evil? Remember the JavaScript is not running on the server it’s running on your box.

Code obfuscated makers say obfuscation provides the following benefits to its users…

•       Protect Intellectual property (e.g. algorithms) contained in JavaScript.
•       Prevent code reutilization.
•       Prevent code modification.
•      Prevent unauthorized code execution (piracy).
•       Add another layer of security, by making it harder for attackers to interfere with your Web Application.

This last point is the most discussed point; does obfuscated code really provide a benefit as an added layer of security? Remember code obfuscation is NOT encryption.

Yes, obfuscated code does provide extra security. We know it can be broken/reverse engineered but the time and effort it takes does provide a temporarily determent to the causal hacker. In the long-run it will not protect your code.

Before using code obfuscation I think one of the first things we need to ask ourselves is “What are we trying to accomplish with code obfuscation?” with that question in mind here are a few guidelines.

•    Never put sensitive information on the client (passwords, 'hidden" URLs, validation routines, encryption routines, etc).
•    Understand that anything on a client can be compromised because you no longer have control.
•   Any obfuscation of client-side code has to be un-done in order for the framework to process it... thus only providing only a marginal security improvement.

My personal take on this is JavaScript code obfuscation provides less transparency on the Web. Open transparency creates better privacy in that everyone can see what everyone else is doing in an open environment. The temporary time value of security gained by using obfuscation is not enough to overcome the potential downfall of a less open transparent environment.

A few other resources:

http://blog.kotowicz.net/2010/04/beating-javascript-obfuscators-with.html

http://getfirebug.com/

https://developers.google.com/closure/compiler/docs/api-tutorial3  Compression provides obfuscation as a side-effect.

https://developers.google.com/web-toolkit/doc/latest/FAQ_DebuggingAndCompiling#Why_is_my_GWT-generated_JavaScript_gibberish?