The original slides made heavy use of the Microsoft PowerPoint animation feature. Unfortunately, SlideShare does not currently support animation. You can download the presentation and the animations will work, but I ended up modifying the slides so they are more viewable online. SlideBoom will keep the animation, but it does it by creating a video of the presentation. I decided to stick with SlideShare and spare you the resulting nine minute video. While I should add audio and make a SlideCast, this post might never be completed if I wait until I have time to create a really nice web presentation.

Merriam-Webster defines a totem as any supposed entity that watches over or assists a group of people, such as a family, clan, or tribe. In this presentation I focused on how TOTEM assists in watching over and evaluating the threat an IP represents. The idea behind TOTEM is simple: compare threat information from sources such as watchlists (DShield, Emerging Threats, SenderBase, etc.) to activities with the organization (IDS/IPS, flow logs, etc.) and other locations (SANS ISC, DOE federated model, etc.). As new threat information and activity sources are added, a better evaluation can be rendered.

The purpose of this presentation has been to share the basic ideas behind TOTEM with the hope that others may provide helpful insight. So far I have not disappointed. I wanted to thank everyone for I have received some very intriguing ideas.

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.

I am going to be hitting the road at the end of this week. That means, catching up on podcasts while I drive, and doing some reading while in the hotel room. I pulled a few topics of interest and printed them out. In case they might interest others, I have included the links below. I am going to be attending the Cybersecurity Summit 2007 for NSF Large Research Facilities. You probably did not think the monastery would qualify as a large NSF research facilities. Well, it doesn’t. But we do advise those troubled souls in the matter of security enlightenment. Now I have not attended one of these summits before, so it should be interesting. If you happen to be attending, look for me. I’ll be one with the big notebook of reading material.

Defense in Depth

• A Layered Approach to Security
• Defense in Depth: Foundations for Secure and Resilient IT Enterprises

Security Baseline

• COBIT Security Baseline

Information Security Governance

• Information Security Governance: Guidance for Boards of Directors and Executive Management 2nd Edition
• Why Information Security Governance Is Critical to Wider Corporate
• Information Security Governance: Motivations, Benefits and Outcome

Information Security Hormonization

• Information Security Harmonisation

SOA Security

• Understanding SOA Security Design and Implementation
• SOA: Redrawing the Business Processes
• SOA Security in Action
• Interview with Gary McGraw, CTO of Cigital, Inc.
• Managing Enterprise Risks: Security Considerations in the Deployment of SOA
• SOA raises security worries
• SOA Security Overview
• SOA Security, Identity 2.0 and Convergence
• SOA Security and Enterprise Reuse
• SaaS and SOA: Together Forever
• Security Concepts, Challenges, and Design Considerations for Web Services Integration
• SOA Meta Model
• Another SOA Meta Model