Also, be sure to check out my other post from a while back, Pentesting Adobe Flex Applications with a Custom AMF Client. This post goes into how to write a client using Python to make remoting calls with a remote Flex server.

Building a continually improving security program is an important and common topic. For many CISOs and other directors of security programs — this has been their day job since they earned their titles. There still exists huge gaps between IT/Operations, Application Development, and Information Security Management organizations and how they work together. There are gaps in communication between departments, and even within departments. The challenges of finding and retaining talent are not unique only to appsec, as suggested in my last post.

I’ve only spoken about building a security plan once before on this blog, but it’s a popular conversation making the rounds. securitymetrics.org (the blog, mailing-list, Metricon conferences, and book) resurfaced a lot of my interest, as well as the work that Mike Rothman did with the Pragmatic CSO, Michael Santarchangelo with his book and the SecurityCatalyst blog/podcast/forums, and numerous others.

Not all security programs and bloggers have picked up on these resources. Take Creating a Solid Security Program from Accuvant’s new blog called Insight from Kirk Greene. He appears to be familiar with some of the above resources, but I think there is a lot more out there. After you read my comment (which never got “approved”), be sure to check out the new material I’ve been reading on the state-of-art in information security management, especially including the human element.

Comment gone wrong #2

I think what you wrote here is a great example of a vulnerability management program, but not a security program. Even then, it’s actually more operational (like a compliance initiative) because it gives little strategic or tactical advice.

Starting with awareness is probably the worst way to build a vulnerability management or security program. Maybe we just disagree, but I’d like to see some evidence or metrics demonstrating that this technique has any value, if you can point me to the literature.

Capital planning based on current or mock Strategy Maps and Scorecards/Dashboards is really the first step for building a security program. It is often best to first work with risk management (an operational activity) that can feed metrics up to the strategy, although this should be done along with compliance, regulatory requirements, and potential liability factors. Risk assessments, especially ones done with data classifications, can be the tactical metrics to pull into a risk management report. Simple risk assessments can be done using business tools such as 5 Forces, PESTEL, and/or SWOT anlaysis — although in security we have various others including FAIR, FMEA, and PRA.

I also like the concept of drilling down another strategic metric platform via Enterprise Architecture, in particular an Enterprise Architecture Blueprint (such as the one from Gunnar Peterson). Enterprise Architecture can bring metrics down to the operational level with security policy and certification standards. These can be turned into server and application hardening standards at the tactical level.

Finally, asset/inventory management is another strategic activity that can be conducted to build a proper security program. When combined with the risk analysis data, asset management will provide guidance on where to scan & patch, pen-test, and perform exploit development activities at the tactical level. These tactical procedures can then provide more metrics up to risk management, and back again up to more strategic activities.

On second or further iteration, a balanced scorecard can easily be created to include compliance metrics (operational) along with a strategic direction (suggested as a strategy map). The balanced scorecard could then include metrics from incident management, which in turn could feed back into risk management and liability factors. SABSA could be used to build a governance program to keep the capital planning and security program alive and running with the rest of the business. Additional qualitative metrics based on organizational development and organizational behavior could be included in a hybrid platform such as business scorecards very easily, including Six Sigma metrics such as Voice of the Customer, et al. Simple, isn’t it?

Your notion of using Application Security Scanners in a vulnerability management program disturbs me — especially in the way you have suggested it. Maybe you’re not familiar with these tools or how an application assessment is best performed to today’s standards.

First of all, the surface coverage for even the best app scanners is 94%, with many getting less than 1% surface coverage. Even IBM/Rational AppScan was only showing 74% surface coverage using modern link extraction application drivers.

Secondly, the false negative rate of app scanners is approaching 92%, often more. The false positive rate varies between tools, testers and apps, but I’ve seen figures as high as 40%. App scanners must be properly configured and utilized by an expert in order to be effective at all. Even then, black-box app scanners need to be combined with static analysis and manual expert review for a significant majority of applications falling under “most-risky” data classifications such as PII (PCI-DSS, HIPAA, state performance auditing, etc) or financial data (SOX, GLB, et al). Even middle-of-the-road risky data classifications (e.g. proprietary information that has yet to be patented) should probably have more done to them than a simple black-box app scanner.

When I say manual review + static analysis, I really mean it. The automated tools pay for themselves by the amount of time saved — but can never be used alone. Security review tools that implement static analysis techniques, such as Fortify, Ounce, Checkmarx, Parasoft, Grammatech, DevInspect, AppScan DE, Coverity, Klocwork, and SciTools have better false negative rates than black-box scanners, but much worse false positive error rates. FN is usually between 65-85% (the tool FAILS to find vulnerabilities this often); FP is 85-99%, you’ll often see more “vulnerabilities found” than lines of code averaged across apps. This is why manual expert review with full-knowledge remains the best application assessment technique.

I don’t mean to harsh on you too hard, but it does appear that you need to do more homework before making prescriptions for building a security program — let alone a vulnerability management program. You seem to be capable of providing this information accurately (based on your last blog post and the great blogroll you’ve setup so far), so I expect better out of future blog posts.

Aftermath and reasoning

The consulting companies that I work with (and other colleagues, often consultants from other consulting companies that have been on the same or similar engagements with me) have all taken a strong interest in building trusted advisory adjuncts to the “too busy IT manager” or Mascot CISO/CSO. We have to in order to remain relevant and respected. However, I’ve always viewed consultants as “the colostomy bag of a very ill organization”. Fix the organization and the technology advancements (or whatever else is needed) become agile and sustainable.

Rafal Los recently had me on his 31337 Spotlight: Andre Gironda for his Digital Soapbox blog. BTW – Thanks Rafal — hope you and nearly everyone else are having fun in Vegas right now! There are a few links which may have got lost in my nonsensical chatter, so I wanted to specifically point them out. I said:

I like the idea that I can use my hacking skills for good and cause organizational change through discovery of organizational management and behavior. A real “hack” to me is to take a disfunctional organization and turn it into something awesome.

There are very few state-of-the-art resources on organizational theory combined with information security management. Allow me to point you to the few that I’m familiar with and highly recommend. After you check them out, you may find yourself coming to similar or related conclusions as I did with the above comment.

• David Lacey, author of Managing the Human Factor in Information Security: How to Win over Staff and Influence Business Managers
• Krag Brotby, author of Information Security Metrics: A Definitive Guide to Effective Security Monitoring and Measurement and Information Security Governance
• Ron Person, author of Balanced Scorecards & Operational Dashboards With Microsoft Excel — one of many books on Balanced Scorecards, but very recently written and caught my attention.
• Ian Gorrie, blogger of Bad Penny, with posts such as the most recent The Trials of Toorcamp where he kindly provided the slides to his talk entitled “Hacking HR”. He has even posted earlier on information security management (or as he calls it security information management, an interesting but perhaps confusing twist there). My favorite was a presentation he did at ITCi 2007 that is a must read.
• Kevin Nassery, (@knassery, who spoke at LayerOne 2009 on Diplomatic Security Consulting, with video and slides available.

I have at least one more of these “comments gone X” posts, but the next ones should both begin and end on more positive notes. If you have any suggestions of comments you’ve seen from me that you would like to see turned into a blog post, let me know!

See you all in Vegas!

It’s also high-time that we at TS-SCI/Security begin writing again. I can tell you that since March (our last post), Marcin and I have been involved heavily in our day-to-day work at client-sites and other community efforts/projects.

A lot of new research is going to begin to become available from BlackHat/Defcon. It’s just that time of year where everyone starts to share their work with others. While we can’t exactly reveal everything that we’re working on quite yet, be sure to check in for updates. I have been begging Marcin to post something on an HTTP-related argument we got into about the Post/Redirect/Get pattern, as one example.

Comment gone wrong #1

There was some interesting discussion lately on the OWASP News Podcast, in particular, Podcast 32. This is the first News Podcast that I missed (I was on a plane at the time we recorded), and having just listened to it — I certainly think it’s worth your time to listen to.

This particular News Podcast set off a blog post from Jeremiah Grossman where he says OWASP Podcast #32 pulls no punches. I attempted to comment, but the comment eventually disappeared — perhaps Jeremiah didn’t appreciate my insights. Others did, so here it is:

on the appsec market maturity and potentiality prediction — i rate [discount black-box appsec SaaS] as low-value, and in the future, will continue to be low-value.

selling discount app pen-tests hurts infosec management as a whole because you’re trying to tell ciso’s that they can buy some freedom for $25k/yr (or whatever it is). in reality, they need to spend millions of dollars over several years.

discount app pen-tests need to go out of style. here’s why: because the middle-ground and potential high-value comes from partnering with a trusted adviser (i.e. an appsec consulting company), or attempting to retain this talent in-house (which most companies — including Microsoft who built lists of individual talent to target — have pretty much failed).

every BPO (business process outsourcing) expert knows that the ideal is to avoid “discount” shops and focus on real partnerships, but don’t give any single one partnership everything.

for example, attempt to retain 20% of your appsec program internally ASAP (this does take time — don’t expect it to happen overnight), while outsourcing initially 20% to one minor company (e.g. Gotham Digital Science, Aspect Security, Denim Group, Matasano, Independent Security Evaluators), then adding a bigger company (e.g. Accenture/McAfee/Verisign) for another 20% to take over the smaller company’s 20% if [expectations are not met -- or major changes occur, such as buyouts]. The next step is to figure out a balance of adding more consulting companies somewhere in the 40-80% range, while growing your internal talent.

investing in this model is extremely expensive and extremely difficult to manage. ciso’s are having problems finding/retaining talent, drafting RFI’s, reading RFP’s, following up on references, and deciding who is really talented and how that talent applies to the applications in their appsec programs. most can’t or won’t even draft an appsec policy.

[low-bid/low-value app pen-test houses, especially SaaS-based ones] convolute and diminish the returns that are necessary to build or even start an efficient appsec program. that’s EXACTLY what Andrew van der Stock was trying to say.

if you want software security ROI, go read Sadbury, Soo Hoo, and Jacquith’s “Tangible ROI through secure software engineering” or follow any of the work that Steve McConnell has done, which this referenced paper was based on.

if you want to keep selling the idea that your McDonalds solution is the bread-and-butter of modern appsec innovation… best of luck to you. there’s plenty of analysts, whole appsec consulting businesses, bloggers, and podcasters that are all saying that a) you’re wrong, b) you sell a one-size-fits-all solution to companies that “don’t get it” which almost forces them to stay in the “don’t get it” mode near-permanently, and c) the jury is out and the case is closed: appsec consulting is the correct path and one-stop-shops that do one-off, cheap app pen-tests are so 2008.

Aftermath and reasoning

My comments were due in part to actual recent industry analyst research, so they were not unfounded or inappropriate. More to the point, they were factual and unbiased.

Chenxi Wang, Ph.D., Robert Whiteley, and Margaret Ryan of Forrester Research published a report entitled TechRadar For SRM Professionals: Application Security, Q3 2009 Application Security Comes Of Age Despite A Slowdown In Security Spend. The date on the report was July 18th, 2009.

In the report, several technologies were evaluated, including:

1. Application scanning
2. Application security consulting
3. Application security SaaS
4. Penetration testing
5. Protocol testing
6. Software protection
7. Source code analysis
8. Web application firewall

These topics and research are not new to our blog, where we have discussed many of them. Take these examples:

• Software Security: a retrospective
• Security in the SDLC is not just code review
• OWASP Hartford tomorrow
• Why pen-testing doesn’t matter
• Why crawling doesn’t matter
• Baby steps with web application security scanners
• Post to webappsec mailing-list on WAF and pen-test: dead again
• Guests on OWASP Podcast #6
• Web Application Security Tomorrow
• What web application security really is
• Week of War on WAF’s: Day 1 — Top ten reasons to wait on WAF’s
• Week of War on WAF’s: Day 2 — A look at the past
• Week of War on WAF’s: Day 3 — Language specific
• Week of War on WAF’s: Day 4 — Closer to the code
• Week of War on WAF’s: Day 5 — Final thoughts
• Web application firewalls: A slight change of heart
• Short-term defenses for web applications

• The number of virtual servers will rise to more than 1.7 million physical servers by 2010, resulting in 7.9 million logical servers.  Virtualized servers will represent 14.6% of all physical servers in 2010 compared to just 4.5% in 2005 (IDC)
• 60% of production virtual machines will be less secure than their physical counterparts through to 2009 (Gartner)
• More than 75% of respondents cited reducing infrastructure hardware and software costs as the critical driver in data center planning (Ziff Davis)
• Overall virtualization market has grown from approximately $560 million in 2005 to a forecasted $2.7 billion in 2009 (IDC)
• 10% of servers will be virtual by 2009, 60% by 2013 (Gartner)
• Fewer than 10% of organizations are doing anything special for virtualization security (Ziff Davis)

Virtual Appliances (VAs) have several advantages over Live CD distributions.  They are easier to enable persistence and customize (especially for real performance in a VM, instead of via a bootable ISO).  It’s easier to take snapshots that represent a “point-in-time” to rollback configurations — or prevent security scanners from running into loop or crash conditions.  Cloning and templating can have significant advantages in terms of agility for testing and scaling architectures, in addition to aiding changes and repair processes.

Microsoft (including the free Hyper-V Server) and VMware (including the free ESXi) are the major players for hardware-VMM server virtualization, with the FOSS project, Xen, being prominent in some other product implementations.

Both VMware and Microsoft have their own disk formats for importing VMs (aka “Guests”) on to their Hosts (aka Hypervisor or Virtual Machine Monitor — VMM).  There is also a third, open format called OVF (or Open Virtualization Format).

1. Microsoft: VHD (Virtual Hard Disk)
2. VMware: vmdk (virtual machine disk)
3. Open Virtualization Format: ovf

Sometimes, one-off scenarios will utilize tar, zip, or rar files to distribute VMs or encapsulated VMs, but this is becoming more and more rare.

Virtual Appliances

A Virtual Appliances is a pre-packaged VM.  Normally, a VM is just like a new machine — no OS, no nothing.  Virtual Appliances come with stuff, and usually only require booting into a DHCP-enabled network, where they self-configure themselves and become available via a web interface for further interaction.

You can find VAs at the following sources:

• VMware — [www.vmware.com] [www.vmware.com]
• Microsoft — VHD Test Drive Program, VHD Partners, VHDs by Product

For those of you still using the outdated OSI model (i.e. you stupid network security geeks, j/k ;> ), here is a general layout of what is available for you:

• Layer 7 – Stonegate Virtual IPS
• Layers 5&6 — Checkpoint VPN-1 Virtual Edition
• Layer 4 — X-m0n0wall
• Layer 3 — Vyatta Community Edition 5
• Layer 2 — HoneyMole

Certainly, if you haven’t read or seen Chris Hoff’s various recent presentations, then you’re going to screw this up.  However, anyone with even a few weeks of virtual infrastructure experience will understand the application of the above VAs in a virtual infrastructure environment.

VMware is very useful for fuzz testing (as seen with Sulley and other frameworks which include interfaces to VMware monitors), and full-state or kernel debugging (as seen with Syser, the replacement to the classic SoftICE), but this is more often for the VMware Server/Workstation products, not their Virtual Infrastructure products (i.e. ESX, ESXi, Virtual Center, vCenter Server, and vSphere).

Many ISOs are moving to VAs.

Many demo-ware and software evaluations are moving from standalone installs directly to VAs (i.e. demo the new app on the new OS at the same time!).

Take these examples outlined in the next sections for a test drive.

Pen-test VAs

Would it be nice if you could setup a perfect pen-test environment, save it, and then clone it a bunch of times in order to tweak one specific thing and then run all your tests in parallel (say, with different credentials).  Well this is exactly what Pen-test VAs are going to allow you to do.  One machine: 4 web application security scanners.

Or better — run DRS (VMware’s Distributed Resource Schedule), which will automatically move VMs around contended Host resources.  Say you have four physical machines, all with a dual-core 2.2GHz proc and 3GB of memory.  Now say that you’re scanning some client machines in far away places (with constant ISP bandwidth churn on both ends — and in between).  Let’s pretend you have this setup:

• IBM AppScan running default-mode with regular user credentials
• Acunetix WVS with AcuSensor tweaked specifically to the app using (at the very least) the web configuration files and structural layout.  One of your co-workers is changing the configuration as he/she learns more about the app from the client and working with the Acunetix support team
• WebInspect running in four more VMs, two with admin rights — two others with user rights.  They’re setup to do parameter tampering and see if they can pollute access controls from admin to admin, user to user, or any combination

If any of you know what CloudAV is… think what CloudWASS would look like.  I call it “WhiteRockSec”, which is… “like WhiteHatSec, but on Crack”.

Of course nobody has built these VAs yet.  In the meantime, you can use these two VAs to accomplish something similar:

1. OWASP Live CD VA
2. InGuardians Samurai Web Testing Framework

WAF VAs or as I like to call them: VA+WAF

VA+WAF is a Virtual Appliance that includes a WAF.  To those of you who don’t love my humor, you’re bound to definitely hate me for flipping the script on this marketing terminology.

Because network vendors (F5, Citrix, Breach, Cisco, Barracuda, Imperva, et al) really like to sell expensive appliances, it’s likely that they aren’t too keen on the idea of selling a software-based VA that is equivalent to their mind like an ISO (anyone remember the presentation on how to reverse-ISO a Netscreen IDP onto cheap PC hardware?). So you don’t see too many of these around yet.

I did happen to find these two though:

1. Microsoft IAG 2007 Virtual Machine Trial 
2. Security Enhanced Web Application Server with mod-security

AppDev/AppSec VAs

Again, there really isn’t much here yet.

Microsoft has:

1. Visual Studio Team System 2008 VSTS Hyper-V Image (Trial)
2. Visual Studio Team System 2008 TFS Hyper-V Image (Trial)
3. Microsoft Pre-release Software Visual Studio 2010 and .NET Framework 4.0 Community Technology Preview (CTP)

Note well that the last link above, for the VSTS 2010 pre-release, has the VA in “vmc” format.  “vmc format” was from Microsoft’s older product.  Searching the Microsoft Download Center for vmc or vhd both have great results, but hopefully Microsoft will standardize on VHD or OVF.  For now, you can convert in many ways — including the latest tool from Microsoft, the VMC to Hyper-V Import Tool.

Integrating AppSec with the above VSTS and TFS tools is relatively easy.  For those not familiar with FxCop, StyleCop, and CAT.NET — you certainly should be.  TFS has some great built-ins for Governance that apply equally well between quality and security.  The TFS Team Blog has some decent postings on topic, not directly to security yet (but probably in the future).  I’m working on additional ideas, heavily borrowed from the Microsoft Process Templates and Tools development center — and from watching how Microsoft uses TFS with their new MPT toolkit.

Security folk such as myself might want to just load Source Insight (or the Microsoft Express Editions) along with using the command-line CAT.NET or possibly SharpDevelop until Ounce O2 is widely available.

For Java, you can search the VMware Appliance Directory, but I found nothing useful.  Currently, the easiest and cheapest way to get JEE AppDev/AppSec going is to use EasyEclipse.   There is a commercial equivalent called Yoxos that also sounds very promising.  I think most of us would be flying blind without a few Eclipse plugins such as Classlocator, Jupiter, Flow4J, IvyDE, FindBugs, and PMD.  Build server ISOs such as Buildix would be wonderful to turn into a VA.

Again, us security folk would probably stick to Source Insight and/or SciTE along with the command-line versions of FindBugs and PMD.  Static analysis tools are slowly turning to be out of vogue these days… so YMMV.

Summary

Learning Virtual Infrastructure is going to take some time, but the payoff is worth it.  In no time, you’ll be turning your minimally-equipped Security Operations Center or appsec group into a real infrastructure to fear.

Download the hardware-VMMs to “whitebox supported” hardware (note: this doesn’t always have to be on an “official list” from the vendor).   Try both the evaluation versions (Microsoft Windows Server 2008 R2 Beta with Hyper-V Role enabled ; VMware ESX and vCenter Server VA) and the free ones (Microsoft Hyper-V Server 2008 R2 Beta ; VMware ESXi).  Download a few VAs in various formats and learn how to import and start them.  You’re on your way!

Application Log File Forensics: The Hard Way

The first thing a security professional or administrator usually think of when handling an application security incident is to check the logs for the applications, databases, and other application-tiers involved.  Often, these logs are either on the servers that run the applications themselves, or possibly in a central logging location.  If a certain attacker tool can be identified from the log files (or other sources such as full packet-capture), then it may be of interest to run that exact same tool against your own application-under-target (preferably in a mocked-up lab or test environment, if it mirrors production well enough).

The most popular web servers, Apache httpd and Microsoft IIS, do create local log files by default.  According to most compliance regulations and standards (e.g. COBIT, HIPAA, GLB, PCI-DSS, FISMA, EU Directive on Privacy and Electronic Communications, ISO 17799/27002, CA SB1386 and similar), logging must be centrally located, or may have other required provisions.  This may include application-layer information, such as the log information from Apache and IIS.  It may be very likely that your organization already has centralized logging where this information is available.

If centralized logging does not exist, it may be a good time to start up a project to enable it.  The Apache Cookbook, 2E, is the best place to go in order to configure httpd to start sending syslog information.   It’s about as simple to add “ErrorLog syslog:user” into the httpd.conf file, but this only logs error messages, not authentication/access_log messages.  The book gives two prescriptions, one using “AccessLog “|/usr/bin/logger” combined” if your OS supports the logger command properly.  The other is to run a custom log message through a Perl script, as seen below:

CustomLog |/usr/local/apache/bin/apache_syslog combined
cat > apache_syslog
#!/usr/bin/perl
use Sys::Syslog qw( :DEFAULT setlogsock );
setlogsock('unix');
openlog('apache', 'cons', 'pid', 'user');
while ($log = <STDIN>) {
syslog('notice', $log);
}
closelog;

Microsoft IIS will need to go through the Event Log, which can be converted to syslog messages using a third-party software package such as Snare or MonitorWare Agent.  If IIS logs can also be converted to w3c standard log format, then Apache log analyzer tools such as AWStats could also be used.  W3C also has their own log analysis tool that also does HTML validation, called the Log Validator.  These may be useful to run following your own scan of the application using the same or similar attacker tool, as they will not only point out where in your application the scan/tool covered, but also where you may have the most errors or lack of quality/security controls.

The book Practical Information Security Monitoring also makes some suggestions for log collections, including the use of Sawmill or Splunk to sort/search log messages and gain further information and detail.  There may also be further adjustments you will want to do at the application (or other tier) layer, such as logging POST data.  We discussed logging HTTP referrers on our old post: Using Google Analytics to Subvert Privacy.  Practical Information Security Monitoring talks about Oracle audit logging, but there is also a detailed article on Pete Finnigan’s blog on Oracle forensics and UKOUG.  At the recent BlackHat DC conference, David Litchfield gave a talk on The Forensic Investigation of a Compromised Oracle Database Server, which may also be of interest (once the slides are available).  There are also some new books coming out on the topic of Oracle Forensics in the next few months / year.

Web Application Incident Handling: The Easy Way

Most of the logfile “digging” takes time, even when consolidated and using expert tools and analysis.  There are some very easy approaches that we’ve come up with, or seen others using and talking about.  These tools integrate well at the HTML and Script layers.

Over a year ago, Mario Heiderich started the PHP-IDS project, as a way to build protection and monitoring capabilities into PHP applications. Several side projects spurred up as a direct result of the incredible work that was put into PHP-IDS, mainly its default_filter.xml regular expressions. This XML file of regular expressions provides capabilities to detect a vast range of attacks, including XSS, CSRF, SQL Injection, Directory Traversal, Local/Remote File Execution, DoS, and Information Disclosure. Part of the success behind the PHP-IDS project, was the constant testing and attacking of PHP-IDS regex filters, which can be reviewed extensively in this sla.ckers.org thread. More info on PHP-IDS can be found in the PHP-IDS FAQ.

Romain Gaucher, wrote Scalp, an Apache log analyzer in Python, which leverages PHP-IDS’ default_filter.xml to detect attack strings in logs. I’ve used Scalp on numerous occasions, including a recent attack attempt on tssci-security.com. By nature, Scalp cannot examine POST content because Apache logs do not contain POST data. (See PHP-IDS or mod_security for those purposes)

Simply use Scalp by running it as follows (keep in mind there may be false positives with regards to the attack type, though it is very good at pulling attack queries from the log):

./scalp.py --log access_log --filters ./default_filter.xml --html --tough --exhaustive

Arshan Dabirsiaghi recently released OWASP Scrubbr. Scrubbr works by detecting input data in a specified database that does not match up with a specified AntiSamy policy file. Because Scrubbr uses an AntiSamy policy to validate data, does not mean it necessarily detects XSS in your database. Note, one does not require AntiSamy to be implemented in an application to use Scrubbr. Using Scrubbr, you have the capability of validating each and every column capable of holding strings of every row of every table in a database.

Together, Scalp and Scrubbr make for excellent web application security forensic tools. Scalp can help detect attacks in Apache logs, and Scrubbr can help you clean your database of content that does not match your site’s policy.

I think that very large-installation, Internet-facing web applications require Anti-DDoS technology in the form of an appliance, preferably one that does rate-based behavior detection.  I often feel that those same organizations also require SLB appliances, although I prefer to see these integrated with a switch fabric in a chassis-based, large backplane network switch.  In a year’s time, SLB Layer-2 technology could be replaced by VMware DRS clustering and/or an equivalent like Microsoft PRO.  I was always a fan of Anycast to replace SLB at Layer-3.  I continue to suggest these models/architectures today.

Can whitelist WAF technology be used by those same devices in the short-term (Anti-DDoS or SLB appliance)?  Absolutely, as long as it’s done by an expert and tuned to the applications.  Should these devices sometimes be separated out of a traditional operational role, due to auditability and for compliance scoping purposes?  Probably not.  Should they perform monitoring, debugging capability, or solving hard production problems?  Probably not.

The reason that the first question is a yes, and the others are a no is because Anti-DDoS and SLB devices are already performance-ready-capable of providing WAF whitelisting functionality (note: not in all cases, but this works especially well for devices that provide rate-based behavior detection before mitigation).  Monitoring does NOT require an inline device.  All it requires is network taps (or potentially port-mirroring, but most professionals recommend taps over SPAN ports).  Also, infrastructure is changing rapidly, so it’s not wise to invest in a dying model.

Additionally, I know that companies like Sourcefire and Reflex Systems are integrating at the VMsafe API layer, which is a hypervisor introspection layer much like XenAccess.  This is really where much of the AV/IDS/IPS/HIMS/DLP/WAF/blacklisting-whitelisting technology belongs.  VNET will also change the introspection layer (in addition to almost completely eliminating the physical network layer and SIM/SEM/SIEM/NMS/EMS moves & changes), as it simply adds to introspection functionality.  I have already alluded to Cisco AXG becoming a VNET “module”, but what if Reflex Systems or StoneSoft start integrating WAF not only as a VNSS (Virtual Network Security System), but also at the hypervisor introspection layer?

Fortunately, for application security, server virtualization and the evolutions it’s bringing with it e.g VNET and VMsafe, are going to dominate traditional networks and cut their existing budgets.  Unfortunately for application security, the new virtualization evolution also brings with it tons of object reuse (there are at least two new controls channels available to adversaries), and new ways of establishing covert channels.

This means a few things.  First of all, the word “firewall” is dead, and therefore, the word “web application firewall” and the associated acronym, WAF, are also dead.  Imagine today if there existed a control channel that, when taken over by adversaries, it became a covert channel that had unlimited object reuse control of every physical RAM on every computer in existence all at once.  This is cloud computing, but virtualized.

Not only that, but we are saying that adversaries have already bypassed traditional firewalls by using the application layer i.e.  Hacking Intranets from Jeremiah Grossman.  Thus, this master, covert control channel is already on its way to being built (at least as man-in-the-browser).  Imagine for a second that you don’t use NoScript with Firefox and additionally implement the features of Chrome by using multiple Firefox profiles.  Imagine for a second that you are a regular user, with all of those Clickjacking and modern application attacks available to anyone who wants to get to you.

Like many of us used the words “brick-and-mortar” to describe backwards-companies during the dotCom bubble, I think “fire-and-wall” well-describes organizations that continue to cling to traditional networks and network security as answers to Internet, Enterprise IT, and any operational risk.

Do I intend to sell you on the idea that we should all instead jump to Fortify RTA or Microsoft SRE?  No.  There are potential consequences to any of this.  This is only the functionality required to reduce risk to applications, not the assurance that risks have been removed.

TCSEC says that we need to balance functionality and assurance.  But nobody ever bothered to do any assurance.  Assurance is the Microsoft SDL, SDL Pro, and SDL-IT.  @Stake and Foundstone are gone and have split into tons of fractured security evaluation and risk assessment boutiques that have 1-300 developer-security-tester guru’s that mix SAST and DAST with expert review.

But the SAST+DAST market is less than $100M, while WAF is at least 20% more than that (although probably inflated).

I hate to be the bearer of bad news, but you don’t just say “DO BOTH” because nobody will do the SAST+DAST work.  We tried that last time, when tcp_wrappers and the DEC firewall came about  The underground that wanted to keep their covert control channels alive started dumping rootkits on pre-pwned Unix machines.  Then Dildog and others made it possible to easily access Windows machines, and after that – botnets and the like have reigned.  There are already backdoors in our web applications.  OWASP Scrubbr is not going to save us all by itself.

Who did the work back then?  OpenBSD?  Certainly not Microsoft, and even today their SDL appears to be failing by some, but imagine if it did not exist at all.  We obviously have to do better with assurance practices.

Can functionality-based controls work easier, better, and faster than assurance ones?  Are they that less complex and easier to train?  Or is there just more written about them because it’s easier to SELL them by baking them into products rather than customizing them to an ISV organization or an Enterprise development team?

If you are part of the group that is spending $120M on WAF technology, then you are hurting the SAST+DAST market because you’re taking away that spending.  Clearly, risk analysis is not taking place and people are spending based on familiarity in addition to PCI-DSS requirement 6.6, which all but forces the inequality to happen.

Look at the best in exploitation-countermeasure functionality-based controls that work on object reuse problems e.g. DEP, ASLR, SafeSEH, SafeInt, et al.  Are adversaries still bypassing these?  Security researchers in the offensive-research space are.  These countermeasures are closer to the code (even HIPS is closer than network-based IPS), like many WAF suggestions.  Is is true that we still require assurance even after 15 years of exploitation-countermeasure optimization?  I remember when stack-guard protections were first coming out – they were seen as a huge joke (i.e. toy/researcher technology), much like Fortify RTA, CORE GRASP, Microsoft AntiXSS-SRE/AntiCSRF, GDS Security GPF, and HDIV are seen now.

I know to many of you out there, this looks like a rant, and I really could go on forever about this topic.  So, go to the datacenter, give your WAFs a hug, and continue to buy into the “functionality is better than assurance” argument.  You’ll feel better in the morning, right after you forget that you just opened up your database to any talented people who want to make money from the data in it.

Also, pen-testing is dead.  We no longer need to prove that applications are insecure.  We know they’re insecure – no matter how many functionality controls you layer on top of them.  Unless YOU prove that the applications that YOU are responsible for ARE secure, you are working against the rights of users, consumers, cardholder data, personally identifiable information tied to healthcare and financial records, trade secrets, and the ability to control our critical infrastructure.  Enjoy.

OWASP Podcast Series #6 (direct download link)

Brian introduced a tool he has been working on, SPF – Secure Parameter Filter, which has the features we would like to see in WAFs, and would recommend people checking out as an alternative to implementing a commercial WAF as a short-term fix.

We came up with the idea for the site when Romain came upon an SSL failure with Gmail. Tyler then blogged about it, and then I was getting errors with Facebook.

The interesting things about Gmail, when you go to https://gmail.com, Firefox was the only browser we tested to follow the 301 Redirect to another domain (www.google.com) with a proper SSL certificate. IE7 and Google Chrome on the other hand, asked the user for confirmation before the redirect. Is this a Firefox SSL failure? I don’t know, and several others I’ve spoken with aren’t sure how a browser should handle it either.

Anyways, just wanted to point out this new site, which has already gotten some attention from lonervamp at terminal23 and hype-free.

Back in 2004, OWASP published the Secure Software Contract Annex (referred to as OWASP Contract hereon out) to help software buyers and sellers achieve a meeting of the minds on application security. The OWASP Contract was generously placed in the public domain so that end-users could use it without license burdens. Since that time, the OWASP Contract has been widely used, even included in a Government acquisition guide (with full attribution). Now SANS has published their SANS Application Security Procurement Language (referred to as SANS Contract) along with the release of the CWE Top 25.

There is no question, that the SANS Contract contains a ton of language from the OWASP Contract. Roughly 75% of the SANS Contract is taken from the OWASP Contract (see below for a side-by-side comparison).

In comparison the original contract put out by OWASP, the SANS-added contract language is very biased. The OWASP Contract was meant to be fair, and balanced — between the software developers and the software buyers. In the SANS Contract, the terms have been slanted to solely benefit software buyers and SANS. Yes, SANS; through including terms that require developers “pass competency tests on application security,” which map directly back to SANS-offered application security training and certification exams. In their contract, the vendor bears the burden of almost every term.

In no way do I intend that this post undermine the incredible efforts the MITRE organization has done with the Common Weakness Enumeration project. Steven M. Christey of MITRE even suggests “promoting these efforts *NOW* while people are still paying attention.”

Instead of looking to the CWE/SANS Top 25 and SANS Application Security Procurement Language, I suggest everyone review the OWASP Application Security Verification Standard and OWASP Secure Software Contract Annex. These two OWASP documents, brought together, set the bar for application security, and take a truly positive approach. No longer are we enumerating badness — creating lists of things to watch out for — but what makes an application truly secure. Take it one step further, and look at Andrew van der Stock’s OWASP Coding Standard to what developers should be doing.

So I leave you all now with the following comparison between the two contracts and leave the rest up for discussion.

Side-by-side comparison (diff -u output)