What I hope people reading Cory’s post walk away with is the recognition that sects exist. We all have various fanatics at each of the organization where we work. Many are good people earnest and true in their desire to do their jobs well. Yet, they could not be more different in their solutions to the problems facing their organizations. They may fall into the high priests or heretics camps, or a dozen other camps.

Let us talk about some of the divisions within IT and security. Richard Bejtlich points out in his post, , “Steve Liesman on Inputs vs Outputs,” two camps. Richard is continuing an argument he previously made in “Controls Are Not the Solution to Our Problem.” He argues that too much time and resources are being spent on auditing controls that are far too input-centric. Instead, Richard feels controls should become more output-aware and recommends directing attention away from inputs and devoting more energy to outputs. Included are some real world examples that management could understand and relate to. Steve Liesman is quoted in relation to our current economic crisis, “It’s not what you’re doing that matters; it’s whether or not it works.” Consider the following questions. Within your security organization, who focuses on controls/inputs and who focuses on output? How much of a division exist between these groups? Where do the auditors fit in?

To point out other divisions within security, take a look at Jeremiah Grossman recent post, “Quick Wins and Web Application Security.” To quote Jeremiah paraphrasing a recent conversation with Joseph Feiman (Gartner):

During an event a panel of Gartner Analysts asked the audience what the best way is for organization to invest $1 million dollars in effort to reduce risk. The choices were Network, Host, or Application security to which the Gartner analysts made their cases for these three disciplines. The catch was the budget could not be shared between them and must be prioritized into a single initiative. The audience selected Application security. However, the Gartner CSO (who took the role of CIO in the play) overruled the audiences’ decision. They instead selected Network security, while at the same time curiously agreeing that Application security would have been the better path. His rational was that that it is easier for him to show results to his CEO if he invests in the Network.

Gary McGraw was recently interviewed by James McGovern for the SilverBullet podcast. They discuss the recent release of “Building Security In Maturity Model (BSIMM).” In the interview, Gary was asked about the leaders of the enterprises that “have a clue in making their security posture better.” While the leadership that helped develop the BSIMM had very diverse backgrounds, James asked, “It sounds like they are all from a technical background at some level. Are there IT executives out there that understand software security that are just business people?” Gary responded, “I don’t know the answer to that. I really don’t know any. I will say this about these people, they are the sort of hybrid people that can speak business and also have a very deep technical background. As you know those kind of creatures are rare on earth. Right now it appears that they might be necessary to cause software security initiatives to be a success. Hopefully, we will gain enough experience and write down enough empirical science that won’t be the case in the future.”

It is not a great surprise to learn that a major divide exists between the IT and the business camp. Recent frameworks often include governance components in an attempt to help bridge the gap between the two camps. As an example, the IT Governance Institute® (ITGI™) recently released v0.1 of risk based framework based on the principles of enterprise risk management standards/frameworks such as COSO ERM2 and AS/NZS 4360,3. The framework is called Risk IT. ITGI would argue that existing IT risk guidance documents tend to focus solely on IT security. Risk IT is meant to cover all aspects of IT risk. ITGI also develops the Control Objectives for Information and related Technology (COBIT), which is focused on “providing a comprehensive framework for the delivery of information technology-based services.” Risk IT and COBIT are meant to compliment each other. COBIT is a set of good practices which provide the means of risk management; while Risk IT is meant to set good practices for the ends by “providing a framework for enterprises to identify, govern and manage IT risk.” Recall Richard Bejtlich argument concerning the division between the controls/inputs and outputs.

All these different sects make effective security most difficult. A layered approach to security fails to work when the layers operate in isolation. Gary McGraw gets an “amen!” for describing leaders of the enterprises that understand security as a “sort of hybrid people that can speak business and also have a very deep technical background. As you know those kind of creatures are rare on earth.” On top of having an understanding that reaches into areas throughout the organization, they need to be leaders.

Rob Goffee and Gareth Jones wrote an article, “Leading Clever People.” Goffee and Jones will be publishing a book with the same title late in 2009. An audio interview is available from the London Business School. Goffee and Jones conducted over a 100 interviews with leaders at major organizations and report the relationships effective leaders have with their “clever people” can be shaped by seven shared characteristics:

1. They know their worth—and they know you have to employ them if you want their tacit skills.
2. They are organizationally savvy and will seek the company context in which their interests are most generously funded.
3. They ignore corporate hierarchy; although intellectual status is important to them, you can’t lure them with promotions.
4. They expect instant access to top management, and if they don’t get it, they may think the organization doesn’t take their work seriously.
5. They are plugged into highly developed knowledge networks, which both increases their value and makes them more of a flight risk.
6. They have a low boredom threshold, so you have to keep them challenged and committed.
7. They won’t thank you—even when you’re leading them well.

Now you may be thinking, “I am security, not the CEO of the company. I am not even their project manager. Why are you talking about leadership? What should I care about business? If users just did what I told them, life would be good.” It is important to note that a characteristic not listed above is “empathy.” Folks in your organization are not going to try and see things from security’s point of view. They want to do their job and if security appear to be a road block, they will go around. We need to avoid having each sect doing their own thing. As what occurs in many religions, an “us verses them” attitude will develop. If you want people to follow, you must first lead. To lead “clever people” you must understand those people.

James Parker, Southwest Airlines ex-CEO, offers some advice. He has written a fascinating book titled “Do the Right Thing.” One story particularly interesting concerned a manager who didn’t succeed despite being very intelligent and ambitious. “When this person finally left, I asked one of his former employees why she thought everybody disliked her former boss so much. She summed it up: ‘Because he was the kind of person who kissed up and spit down.’ ” When problems arose at American, “the primary focus of communications was blaming and avoidance of blame – in contrast, when something went wrong at Southwest, the focus of communications was problem-solving,” Parker quotes from the book, “The Southwest Airlines Way“.

James Parker and Barbara Stocking, Chief Executive of Oxfam GB, discuss below “Leadership in an Age of Uncertainty” with moderator Deborah G. Ancona. The discussion focuses on the need for distributed leadership. A key point made is that companies need “employees doing things outside the narrow scope of their job responsibilities, to contribute to the success of overall operations.” This is the cornerstone of the concept of “relational competence.”

The world continues to get more complicated. In response, more specialization occurs, which leads to less understanding of other groups. The history of religions have shown us how difficult things can get when various sects develop. In the corporate world communication breaks down, the focus on the mission is lost, and the relational competence of a company dissolves. I started this post with the statement that I come bearing no answers, only questions. While that is true, I have pointed to some very intelligent people who discuss the various sects and offer possible ways to coexist. Security professionals cannot exist in their own camp, separate from the rest of the organization, dictating how people should do their jobs. In such an environment, it will not matter if every pronouncement is the embodiment of wisdom and truth. Failure is inevitable. Abraham Lincoln offered these wise words when he addressed the Washington Temperance Society on February 22, 1842:

If you would win a man to your cause, first convince him that you are his sincere friend. Therein is a drop of honey that catches his heart, which, say what you will, is the great high-road to his reason, and which, when once gained, you will find but little trouble in convincing his judgment of the justice of your cause. If indeed that cause really be a just one.

On the contrary, assume to dictate to his judgment, or to command his action, or to mark him as one to be shunned and despised, and he will retreat within himself, close all the avenues to his head and his heart; and though your cause be naked truth itself, transformed to the heaviest lance, harder than steel, and sharper than steel can be made, and though you throw it with more than herculean force and precision, you shall be no more able to pierce him, than to penetrate the hard shell of a tortoise with a rye straw.

Amen, brother Abraham.

The crime landscape is shifting. Attacks are moving up the network stack. Network-based attacks are not the prime source of security problems anymore. The attacks today are moving into the application layer: Web 2.0, instant messenger attacks, fraud, information theft, and crime-ware are just some examples of new types of attacks that generate a load of data to be collected and analyzed. Beware! Applications are really chatty and generate alot of data.

While my current post is not about security visualization (see earlier post “Security Data Visualization“), I would like to point out that DAVIX, a live CD for data analysis and visualization, is expected to be released August 6th. That should be really cool and fun.

Since application security is a topic of interest for me, I ran into the problem of having too many topics I wanted to discuss when I started trying to write a post on ModSecurity, an open source, free WAF Apache module. Today, rather than waiting for me to integrate the information, I decided to move ahead and do the post while limiting myself to only pointing out the various sources. The reader can follow the links for a more in-depth discussion and understanding on the topic.

Why You Should Care

The Risky Business podcast has come to be one of my favorite podcasts. The host, Patrick Gray and regular guest Munir Kotadia, just cracks me up. Plus the show is informative and features great guests. This week’s show had an interview with H D Moore talking about the DNS bug. Timely and informative; what else can one ask for? The 68th episode, done at the beginning of this month, had an interview with Jeremiah Grossman concerning web application firewalls. As Patrick writes in the show notes, “it takes typical organizations around 130 days to fix sequel injection bugs in code. But you can mitigate these sorts of things with a Web app firewall, and you won’t even have to deal with the development team! Hooray!.”

In Grossman’s blog post “Can WAFs protect against business logic flaws?“, he pointed out that “WAFs don’t defend against every logic flaw, or even every crazy form of SQLi or XSS. Just as white/black box scanners can’t identify every vulnerability and neither can expert pen-testers or source code auditors.” Stuart King, in his article, “Larry David and Web Application Firewalls“, builds upon this idea when he wrote:

Back to the CSO article where the point is made that we are sitting on a huge legacy of insecure code and that “we can’t rewrite history.” So, the argument is that a web application firewall mitigates the risk – note: does not solve the problem – until the code can be replaced.

How much of the risk is mitigated is open to debate, but there are lots of other things to consider too. For instance the cost of redeveloping code against the cost of purchasing and supporting a WAF. We also need to consider the value and risk profile of the product.

Today’s world consist of attackers adjusting focus from network-based attacks to the application layer. Grossman in his post “Website Security Strategies that Work” makes the claim that “9 out of 10 (or more) websites have vulnerabilities as a result of being built by those who didn’t know or appreciate the severity of today’s attacks.” There is no arguing that many organizations are sitting on a huge legacy of insecure code, much of which may have been written before the discovery of prevalent vulnerabilities such as XSS, SQL Injection, CSRF, etc. Even worse, organization often have their security groups focused on network or system security, leaving application level security to developers. Unfortunately, these developers are receiving little or no training, while remaining under pressure to produce code under short deadlines.

Andre Gironda series, starting with “Week of War on WAF’s: Day 1 — Top ten reasons to wait on WAF’s,” provides important reasons why WAFs should not be viewed as a silver bullet solution. Rich Mogull in his post “Web Application Security: We Need Web Application Firewalls To Work. Better” makes the important point:

With old school vulnerabilities we know the details of the specific vulnerability and (usually) exploit mechanism. With WAFs, we are trying to block vulnerability classes instead of specific vulnerabilities. This is a HUGE difference. The WAF doesn’t know the details of the application or any application-specific vulnerabilities, and thus is much more limited in what it can block.

Mogull goes on to state that WAFs can:

no longer be merely external boxes protecting against generic vulnerabilities; they need tighter integration into our applications. In the long term, I’ve branded this Application and Database Monitoring and Protection (ADMP) as we create a dedicated application and database security stack that links from the browser on the front end, to the DB server on the back.

ADMPs, or if you prefer WAFs + Database Activity Monitoring (WAFs+DAM), would be another step in the evolution of WAFs. As Ivan Ristic, creator of ModSecurity, points out in his blog post “What’s the Score of the Game?“:

I feel that one of areas where organizations are failing, with regards to web application security, is that there is a lack of communication between the following three groups: Development teams (who are running source code reviews), InfoSec teams (who are running vulnerability scans) and Operational Security teams (who are running web application firewalls). These three teams each have unique perspectives on the vulnerabilities of the webapps and they should share their data with each other.

Nicely stated. No one is arguing that writing secure code is not the answer. If organization began adapting secure systems development lifecycle (SDLC) models into their business operation, many security problems would go away. Building secure software will require changes in the current development culture, which will include people, processes, and technology. No small task.

Gunnar Peterson has a nice post, “WAF and XSG Risk and Effectiveness at 20,000 feet” where he discusses modeling of combination of risk and effectiveness to identify areas of focus. As Peterson points out in another post, “WAFs are not as static as network firewalls…Instead WAFs collaborate much more directly with development, which is another growth opportunity for security industry.”

This post is going to stay focused on WAFs. With it taking on average 130 days to fix sequel injection bugs, organizations need something they can implement today. WAFs have an important role to play in adding a layer of security and monitoring to a defense in depth security approach. WAFs will evolve. They are in the process of evolving now. Understanding the fundamental ideas and going through the implementation of an open source solution starts us on the path of better understanding of future technologies.

An Implementation Using ModSecurity

Building on previous posts concerning “An Apache Implementation“, “PHP Implementation“, and “Apache and OpenSSL“, we have an Apache web server setup to build upon. For additional details, please get Ivan Ristic’s book, “Apache Security.” It really is a must have book for anyone serious about running an Apache web server. Ristic also maintains the ModSecurity website and blog, which serves as a great source for up-to-date information on ModSecurity.

The Apache module mod_unique_id needs to be installed for ModSecurity to work properly. This module was not installed when we configured Apache. At that time, we did not know we needed it. While it can be somewhat inconvenient, for security reasons it is best not to install modules not needed.

1. Stop Apache Server.

# /usr/local/apache/bin/apachectl stop

2. Install mod_unique_id Module.

For non Mac OS X, do the following:

root# cd /usr/local/src/httpd-2.2.8
/usr/local/src/httpd-2.2.8 root# make clean
/usr/local/src/httpd-2.2.8 root# CC=gcc \
CFLAGS="-O3 -fno-omit-frame-pointer" \
./configure --prefix=/usr/local/apache \
--enable-rewrite \
--enable-so \
--disable-imap \
--disable-userdir --with-mpm=worker --enable-ssl --enable-unique-id --enable-unique-id
/usr/local/src/httpd-2.2.8 root# make
/usr/local/src/httpd-2.2.8 root# make install

For Mac OS X, please do:

root# cd /usr/local/src/httpd-2.2.8
/usr/local/src/httpd-2.2.8 root# make clean
/usr/local/src/httpd-2.2.8 root# CC=gcc \
CFLAGS="-O3 -fno-omit-frame-pointer" \
LDFLAGS="-L/opt/local/lib -L/usr/lib" \
./configure --prefix=/usr/local/apache --enable-rewrite \
--enable-so --disable-imap --disable-userdir \
--with-mpm=worker --enable-ssl --enable-unique-id
/usr/local/src/httpd-2.2.8 root# make
/usr/local/src/httpd-2.2.8 root# make install

3. Install PCRE.

Only under Mac OS X did I have to install Perl Compatible Regular Expressions (PCRE). You may be able to skip this step, depending on your OS.

root# cd /usr/local/src
/usr/local/src root# wget http://downloads.sourceforge.net/pcre/pcre-7.7.tar.gz
/usr/local/src root# tar xzf pcre-7.7.tar.gz
/usr/local/src root# cd pcre-7.7
/usr/local/src/pcre-7.7 root# CC=gcc \
CFLAGS="-O3 -fno-omit-frame-pointer" \
LDFLAGS="-L/opt/local/lib -L/usr/lib" \
./configure
/usr/local/src/pcre-7.7 root# make
/usr/local/src/pcre-7.7 root# make test
/usr/local/src/pcre-7.7 root# make install

4. Install the latest version of libxml2 or Lua.

To quote wikipedia, libxml is “a library for parsing XML documents” and Lua is “a lightweight, reflective, imperative and procedural programming language, designed as a scripting language with extensible semantics as a primary goal.” ModSecurity requires dynamic libraries which are not built by default in the source distribution. Binary distribution is recommended.

I will go through configuration and installation of libxml2 from source and the binary installation of lua under Mac OS X. There is a good chance if you are running a different OS, the libraries will have already been installed.

root# cd  /usr/local/src/
/usr/local/src root# wget ftp://xmlsoft.org/libxml2/libxml2-2.6.32.tar.gz
/usr/local/src root# tar xzf libxml2-2.6.32.tar.gz
/usr/local/src root# cd libxml2-2.6.32
/usr/local/src/cd libxml2-2.6.32 root#  CC=gcc \
CFLAGS="-O3 -fno-omit-frame-pointer" \
LDFLAGS="-L/opt/local/lib -L/usr/lib" \
/usr/local/src/cd libxml2-2.6.32 root# ./configure
/usr/local/src/cd libxml2-2.6.32 root# make
/usr/local/src/cd libxml2-2.6.32 root# make install
/usr/local/src/cd libxml2-2.6.32 root# cd ..
/usr/local/src root# wget http://luaforge.net/frs/download.php/3097/lua5_1_3_Darwin811x86_lib.tar.gz
/usr/local/src root# mkdir lua
/usr/local/src root# cd lua
/usr/local/src/lua root# tar xzf lua5_1_3_Darwin811x86_lib.tar.gz
/usr/local/src/lua root# cp liblua5.1.* /usr/local/lib
/usr/local/src/lua root# cp include/* /usr/local/include

5. Download, unpack, configure, and compile ModSecurity.

If you are interested in connecting a ModSecurity sensor to the central audit log repository, you will want to build the ModSecurity Log Collector below with the command “make mlogc”. Install instructions can be found under apache2/mlogc-src directory. That step will not be included below.

root# cd  /usr/local/src/
/usr/local/src root# wget http://www.modsecurity.org/download/modsecurity-apache_2.5.5.tar.gz
/usr/local/src root# tar xzf modsecurity-apache_2.5.5.tar.gz
/usr/local/src root# cd modsecurity-apache_2.5.5
/usr/local/src/modsecurity-apache_2.5.5 root# cd apache2

For non Mac OS X, configure with the command:

/usr/local/src/modsecurity-apache_2.5.5/apache2 root# ./configure \
--with-apxs=/usr/local/apache/bin/apxs \
--with-apr=/usr/local/apache/bin \
--with-apu=/usr/local/apache/bin

For Mac OS X, use the command:

/usr/local/src/modsecurity-apache_2.5.5/apache2 root# CC=gcc \
CFLAGS="-O3 -fno-omit-frame-pointer" \
LDFLAGS="-L/opt/local/lib -L/usr/lib" \
./configure --with-apxs=/usr/local/apache/bin/apxs

Continue to compile and install with the commands:

/usr/local/src/modsecurity-apache_2.5.5/apache2 root# make
/usr/local/src/modsecurity-apache_2.5.5/apache2 root# make test
/usr/local/src/modsecurity-apache_2.5.5/apache2 root# make install
/usr/local/src/modsecurity-apache_2.5.5/apache2 root# ls -la /usr/local/apache/modules

6. Configure Apache and ModSecurity.

We must now edit the httpd.conf file in order to load libxml2 or lua5.1 modules before the ModSecurity module.

/usr/local/src/modsecurity-apache_2.5.5/apache2 root# vi /usr/local/apache/conf/httpd.conf

Add the lines for non Mac OS X:

#
LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so
#
LoadModule security2_module modules/mod_security2.so

For Mac OS X, add the lines:

#
LoadFile /usr/local/lib/libxml2.2.dylib
LoadFile /usr/local/lib/liblua5.1.so
#
LoadModule security2_module modules/mod_security2.so

Create the ModSecurity configuration file. There is a file modsecurity.conf-minimal present in the /usr/local/src/modsecurity-apache_2.5.5 that can be used. There is also a a Core Rule Set that was included in the /usr/local/src/modsecurity-apache_2.5.5/rules directory courtesy of Breach Security Inc. To quote the README file, “The Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.” Under the rules subdirectory, there a directory “optional” which contains additional possible rules. It is left to the reader which configuration files they may want to include, though it might be wise to start with the minimal and make sure the Apache runs without problems. Then add configurations files as desired.

/usr/local/src/modsecurity-apache_2.5.5/apache2 root# cd ..
/usr/local/src/modsecurity-apache_2.5.5 root# cp  modsecurity.conf-minimal /usr/local/apache/conf/modsecurity.conf
/usr/local/src/modsecurity-apache_2.5.5 root# cp  rules/*.conf /usr/local/apache/conf/

Include the modsecurity.conf, and additional ModSecurity configurations file, in the Apache httpd.conf file.

/usr/local/src/modsecurity-apache_2.5.5 root# vi /usr/local/apache/conf/httpd.conf

Add the line:

Include /usr/local/apache/conf/modsecurity.conf
#Include /usr/local/apache/conf/modsecurity_crs_10_config.conf
#Include /usr/local/apache/conf/modsecurity_crs_21_protocol_anomalies.conf
#Include /usr/local/apache/conf/modsecurity_crs_23_request_limits.conf
#Include /usr/local/apache/conf/modsecurity_crs_30_http_policy.conf
#Include /usr/local/apache/conf/modsecurity_crs_35_bad_robots.conf
#Include /usr/local/apache/conf/modsecurity_crs_40_generic_attacks.conf
#Include /usr/local/apache/conf/modsecurity_crs_45_trojans.conf
#Include /usr/local/apache/conf/modsecurity_crs_50_outbound.conf

Edit /usr/local/apache/conf/modsecurity.conf. The modifications will be very dependent on your environment. See resources listed in the Additional Information section to help with configuration. The default configuration saves the log files relative to the configuration file directory. Change this to where the apache logs are currently being saved.

/usr/local/src/modsecurity-apache_2.5.5 root# vi /usr/local/apache/conf/modsecurity.conf

Change the values to:

SecAuditLog /var/www/logs/modsec_audit.log
SecDebugLog /var/www/logs/modsec_debug.log

Let’s create null files with the correct permissions for Apache.

/usr/local/src/modsecurity-apache_2.5.5 root# touch  /var/www/logs/modsec_audit.log
/usr/local/src/modsecurity-apache_2.5.5 root# chown httpd.httpd /var/www/logs/modsec_audit.log
/usr/local/src/modsecurity-apache_2.5.5 root# touch  /var/www/logs/modsec_debug.log
/usr/local/src/modsecurity-apache_2.5.5 root# chown httpd.httpd /var/www/logs/modsec_debug.log

7. Start Apache.

Check that the configuration file is correct and start up Apache.

/usr/local/src/modsecurity-apache_2.5.5 root# /usr/local/apache/bin/apachectl configtest
Syntax OK
/usr/local/src/modsecurity-apache_2.5.5 root# /usr/local/apache/bin/apachectl start

Check if ModSecurity if configured into running Apache server.

/usr/local/src/modsecurity-apache_2.5.5 root# cat /var/www/logs/error_log | grep ModSecurity
[Thu Jul 31 18:24:59 2008] [notice] ModSecurity for Apache/2.5.5 (http://www.modsecurity.org/) configured.

Additional Information

This post is only to get the basics down. The above information was taken from the ModSecurity documentation install section for version 2.5.5. A great deal more information is available at the ModSecurity blog site and in the book “Apache Security“.

Concluding Remarks

Ivan Ristic and Ofer Shezaf are working on an interesting paper, “Enough With Default Allow in Web Applications!” This paper demonstrates how WAFs are evolving. To quote the paper:

The default allow deployment model, which is commonly used to implement and deploy web applications, is the cause of numerous security problems. We propose a method of modeling web applications in a platform-agnostic way to adopt a default deny model instead, removing several classes of vulnerability altogether and significantly reducing the attack surface of many others. Our approach is best adopted during development, but can be nearly as efficient as an afterthought, or when used at deployment time. What they are looking to do is create a protection layer between the web servers and applications which would increase security and turn applications into verifiable components with external contracts that can be enforced.

Ristic mentions in his post the planned release of “an open source profiling tool (which I will announce next week) to help with the third use case and automate the creation of positive security models (also known as the learning feature of web application firewalls).” Breach Security has also teamed up with WhiteHat Security to add the ability to their Sentinel scanning service to automatically create custom ModSecurity rules for certain classes of vulnerabilities that are found in your web applications. This is the kind of evolution that is required in security and makes ModSecurity such an interesting software package.

Many of the security issues we are beginning to see with Web applications are issues that we have seen in some form with traditional client/server applications. Unlike the Phoenix, the Web application security issues are not rising from the ashes of traditional client/server applications. Client/server security is still very much alive. The Phoenix just provides better imagery then the Hydra, where if you cut the head off the Hydra two came back in its place. In the old days of the Internet (a few years ago), everything was done on the server. When you think about vulnerabilities in ftp, mail, and Web servers, it was the infrastructure groups responsibility for fixing it. Fixes were done by doing such things as setting up firewall rules, patching systems, upgrading server software, etc. With Web 1.0, the intelligence was pretty much on the Web server. Your Web browser would simply talk to your server where the applications resided.

Asynchronous JavaScript and XML (Ajax) changes the traditional model by having the application running on the browser where more of the work is done. The JavaScript engine runs on the browser, talking to the server and third party sources on your behalf. This is not unique to Ajax. Anywhere you have Rich Internet Applications (RIA), there will be this interplay between the server, third party sources, and the client. State information has to be shared between the client and server. Unfortunately, one of the lessons we have learned over the years is that you cannot trust the client. Outside of client side certificates, there really is no way for the server to know who is talking to it.

Shreeraj Shah, the author of Web 2.0 Security – Defending Ajax, RIA and SOA; Web Hacking (Stuart McClure and Saumil Shah co-authors); and Hacking Web Services, did a presentation at the HITB Security Conference titled “Web 2.0 hacking, keeping focus on Ajax and Web Services.” In the presentation, Shreeraj discusses the vectors of change between Web 1.0 and Web 2.0. In Web 1.0, the entry points were structured, there were limited dependencies, the vulnerabilities were on the server side (typically through injections), and there were server side exploitations. In Web 2.0, everything changes. You have scattered and multiple entry points. There are dependencies on multiple technologies, information sources, and protocols. Vulnerabilities can be exploited on Web services through payloads and on the client side through such exploits as XSS and XSRF. Exploits exist for both server and client.

More worrisome is that in many organizations, security remains solely network focused while developers are left untrained and unaware. Up until now, developers have not had to deal seriously with security problems. Add to this changing environment, pressure on developers to meet deadlines and develop code quickly. Some developers main goal is simply getting their application not to crash. It is easy to understand how due to lack of exposure and the need for quick code turn around, developers can fail to put security measures in place sufficient for a Web 2.0 world. Ross Anderson and Tyler Moore add some great insight into the software development environment in their paper, “Information Security Economics – and Beyond.” Ross and Tyler wrote:

In many markets, the attitude of ‘ship it Tuesday and get it right by version 3’ is perfectly rational behaviour. Many software markets have dominant firms thanks to the combination of high fixed and low marginal costs, network externalities and client lock-in noted above, so winning market races is all-important. In such races, competitors must appeal to complementers, such as application developers, for whom security gets in the way; and security tends to be a lemons market anyway. So platform vendors start off with too little security, and such as they provide tends to be designed so that the compliance costs are dumped on the end users. Once a dominant position has been established, the vendor may add more security than is needed, but engineered in such a way as to maximise customer lock-in.

In some cases, security is even worse than a lemons market: even the vendor does not know how secure its software is. So buyers have no reason to pay more for protection, and vendors are disinclined to invest in it.

Another outstanding article is by Sergey Bratus in the July/August 2007 IEEE Security and Privacy magazine titled “What Hackers Learn that the Rest of Us Don’t: Notes on Hacker Curriculum.” Sergey makes the following comparisons between developers in the academic programs to those in the hacking community:

• Developers are under pressue to follow standard solutions, or the path of least resistance to “just making it work.”
• Developers tend to be implicity trained away from exploring underlying APIs because the extra time investment rarely pays off.
• Developers often receive a limited view of the API, with few or hardly any details about its implementation.
• Developers are de facto trained to ignore or avoid infrequent border cases and might not understand their effects.
• Developers might receive explicit directions to ignore specific problems as being in other developers’ domains.
• Developers often lack tools for examining the full state of the system, let alone changing it outside of the limited API.

No one said it was going to be easy. The first step is to recognize that there is a problem. Actually, there are multiple issues to deal with when getting into application security. Just keep reminding yourself, one step at a time. The second step is to reach out and seek help. To help us on our road to security recover, Billy Hoffman and Bryan Sullivan have written the book Ajax Security. Billy has an interview on IT Conversations Technometria titled “Ajax Security” where he talks about Ajax in general and reviews some of the specific security issues most likely to occur. He also gives a number of examples of where security is likely to be a problem.

Richard Bejtlich provided the following very favorable review of “Ajax Security:”

Ajax Security was the last book I read and reviewed in 2007. However, it was the best book I read all year. The book is absolutely compelling and every security professional and Web developer should read it. It’s really as simple as that.

I am not a Web developer. I was not very familiar with Ajax (beyond its buzzword status and a vague notion of functionality) when I started reading Ajax Security. I attended the authors’ Black Hat 2007 talk and was thoroughly impressed and disturbed by the security implications they presented. I expected Ajax Security to be a good book, but one can never be sure if talented hackers and presenters can transfer their skills to the written word. Ajax Security gets the job done.

This is extremely high praise considering Richard’s background and the number of books Richard reviews.

Billy has done some outstanding presentations at Black Hat. In 2006, he presented Ajax (in)security. In 2007, Bryan Sullivan and Billy Hoffman presented “Premature Ajax-ulation“. If video is more to your liking, Bill presented “0wn3d: How AJAX Makes Web Hacking Easier.” In the presentation area of this site, there are a couple very interesting talks on Ajax:

• Why AJAX Applications Are Far More Likely To Be Insecure (And What To Do About It) by Dave Wichers
• Ajax Security by Andrew van der Stock
• Ajax Security Concerns by Rohini Sulatycki
• Hacking Ajax and Web Services: Next Generation Web Attacks on the Rise by Shreeraj Shah

Borrowing from Dave Wicher’s presentation, security issues that need to be dealt with include secure communications, authentication and sessions, access control, data protection, input validation and output encoding, error handling, logging & intrusion detection, availability, and concurrency. Not a simple task. Is Ajax applications less secure then other Web applications? Ajax, in and of itself, is neither secure nor insecure. The OWASP 3.0 Guide chapter on Ajax and “Other” Rich Interface Technologies states, “AJAX applications face exactly the same security issues as all other Web applications, plus they add their own particular set of risks that must be correctly managed. By their complex, bidirectional, and asynchronous nature, AJAX applications increase attack surface area.” Because of the increase attack surface area of Ajax applications, one can argue these applications are less secure. The truth is that other Rich Internet Applications, such as Flash, Java applets, and Active X controls can be just as insecure.

How do you go about securing Ajax applications? Borrowing from Rohini Sulatycki presentation, you need to validate all inputs, all client side validation must be backed up by server side validation, do not implement business logic validation client side, implement whitelist validation, do not trust third party source (filter it out), identify valid data and reject everything else, no direct cross domain call back, and encode all outputs. Do not cripple Web development in the name of security. Instead, organizations need to make sure developers know the security issues. Get security involved on the application side.

Expanding from securing Ajax applications to moving your organizations toward software security and application security, Gary McGraw wrote a nice concise article titled “Four ways to kick off your organization’s software security initiative in the New Year.” Read the article along with everything Gary writes. To summarize the four methods:

• A top-down framework approach…perform a gap analysis between where you are and where you want to be from a software security perspective. Then build a plan to address the gaps….
• The portfolio risk method takes a more business-oriented approach to the software security problem. The idea here is to assess the entire application portfolio according to some risk criteria agreed on in advance. …
• The training first approach to software security is more grounded in the technical world. This approach helps developers who love to do the right thing but just don’t know what the right thing is when it comes to security. …
• The lead with a tool approach, meanwhile, makes sense for an organization that has already purchased and attempted to roll out a security analysis tool….

Gary also does the Silver Bullet Security Podcast, where on broadcast titled “Show 021 – A Panel Discussion with Cigital’s Principals“, the principals at Cigital discuss the best ways for large companies to get started with software security.

Gunnar Peterson is his post titled “Go Wide and Deep, Incrementally” makes the point that the best method for an organizations depends on “what you are trying to do, your company culture, and the people’s skills who are working on software security.” Gunnar suggest a fifth method, “namely decentralized specialized teams, or centers of excellence in PHB speak.” He makes the important point that “to deploy any of the current cutting edge stuff in software security at scale, requires technical depth and deployment width. This automatically limits your resource pool of who can deliver this stuff.”

Gunnar offers additional advice in his post titled “Phasing Security into the SDLC – A Comparison of Approaches.” He suggest four main ways to get started: top down, testing and validation, start in the middle, and training. Gary and Gunnar favor a mix approach of top down and bottom up, “that approach often leads with the creation of a special ops execution team that becomes the software security group. By far, this is the most impressive approach in terms of results and the one that is the most effective in well-run enterprises” (Gary quote). They will not get any arguments from me.

Moving an organization towards an environment where secure code can be produced, let it be Ajax or any RIA, is not an easy endeavor. Like the software development life cycle, an iterative, incremental delivery is the way to go. You do what you can. You work the program, one day at a time. This way, you take the needed steps to a secure recovery.

A quick post on software security. Gunnar Peterson, a Software Security Architect and CTO at Arctec Group, has posted some excellent advice on getting started with software security. His posting is titled, “Go Wide and Deep, Incrementally.” He bases his advice on an article titled “Software Security Strategies” by Gary McGraw. While I am tempted to quote Gunnar quoting Gary, I’ll leave it to you to follow the links. When Gary and Gunnar speak, it is smart to listen.

Speaking of smart things to do, check out Gary’s most recent podcast, “Show 021 – A Panel Discussion with Cigital’s Principals.” The Silver Bullet Security Podcast has become one of my favorite podcasts. In this episode, to quote from Citigal’s site, “The group discusses the best ways for large companies to get started with software security and the similarities between CLASP, Microsoft’s SDL, and the Security Touchpoints.” The Justice League’s members for this podcast consists of Sammy Migues (Director of Training and Knowledge Management), John Steven (Principal Consultant), Pravir Chandra (Principal Consultant), and Gary McGraw (CTO). A very interesting discussion.

On a related topic, Jeremiah Grossman just pointed out in his blog that Fortify Software has announced the premier of their new documentary, “The New Face of Cybercrime”. Check out the trailer:

I wish the film was not just premiering in San Francisco, New York, and London. Following each screening, there will be an expert panel discussion on cybercrime. Since Gary is in the film, and has good relationships with Fortify Software, I am hoping one of the post-screening discussions will make its way to the Silver Bullet Security Podcast.