Bang for your buck: WAF configuration

Typical.

Via Matt Franz, I came across a Response to WAF/IDS/IPS Effectiveness Report. I found this a little odd, since NTOBJECTives seems to have produced the report to which they then respond. (I may totally misunderstand what’s going on here.) (EDIT: I did totally misunderstand; see the comments below. The report writer is not associated with NTOBJECTives at all. Apologies!)

Regardless, it made a point or two I found worth noting about bang for your buck[1] for WAF and IDS/IPS configuration:

An organization should plan to spend 2-3.5 hours per application they plan to place behind a WAF to gain that consistent level of protection for all their applications.

The post seems to imply that they consider this a bit on the high end, and that organizations do as well:

This is significantly more time spent than the average organization spends on their production WAF installations.

I find this really problematic: not the accuracy of the statement, as I don’t have any data that contradict it. However, I have to ask whether organizations find this all that high, considering the protection you’re getting and the time invested in configuring other technologies. If you bring in a consultant to set it up, and she charges $250/hour, that comes to something on the order of $1000 per application. Having recently looked at WAF prices, I’d say that that’s really tinkering on the margins of the project cost. And anyone who’s ever managed an IDS or IPS installation knows that those technologies require far more time to configure and manage (tune) effectively.

In any case, I suspect that a really effective WAF would require more attention than that, particularly in agile shops. 2-3 hours per application per week sounds more realistic to me, meaning that most organizations will need a dedicated application security person just for the WAF, or else find a way to embed the responsibility in development organizations under the oversight of an appsec specialist (to avoid “allow all” situations).

[1]: I refuse to get into the “security ROI” debate in this post.

OWASP Dallas: WTE Live Blog

 

I’m attending the OWASP Dallas meeting today with a bunch of application security ninjas. Matt Tesauro will present the freshest bits possible on the future of the OWASP Live CD and Web Testing Environment. Also watch @OWASPDallas as they might have stuff, I suppose.

Watch here for live blogging updates…

Summary: I absolutely loved the venue: SMU on a gorgeous spring-like day in early March. The room felt a bit tight, but I suspect that a lot of us who attended for the first time boosted the numbers. Matt has a dynamic and engaging way of speaking and clearly chugs the caffeine before he gets on stage. The content sounded really useful and I hope to see more “builder” tools added soon. As far as distributing the WTE, I suggest just an Ubuntu VM with instructions (or a script) to add the appropriate repository and some meta packages. Guess I will get in touch with him separately. And I absolutely loved seeing some old colleagues from a former employer and some new ones from Twitter. Not sure I’ll attend the April event (appsec’s place in risk management) but I will definitely start getting hooked into more local infosec community events.

1249: That’s all, folks! I’ll clean this up when I get home.

1246: April 6th (1st Wednesday) for next meeting. Lots of upcoming events. Next 2 OWASP Dallas meetings at SMU.

1235: OWASP. Meritocracy, not really a hierarchy per se (inverted organization). Other things needed besides vuln testing: change control, source code mgmt, threat assessment, remediation, etc.

1232: Get involved: mailing list (announcements, low traffic). Post on AppSecLive.org forums. Download ISO or VM, submit bugs and RFEs on Google Code site. Create a .deb package of a tool (docs coming, this gets repeated a lot). Suggest missing tools. Check OWASP Wiki (somebody needs to teach them how to configure it to drop the index.php part of the URL).

1227: Building is where the ROI lives, but breaking is fun. Need to add packages to help build things right. Can create custom profiles: whitebox, blackbox, static analysis, target specific (e.g. Java, .NET). (Side note: seems like a great possibility for meta-packages, bro.) Wants to include any good, freely-distributable tools even if they’re not OWASP. Also pushing for more ease-of-use to lower barriers to entry. Will document how to create packages, etc, plus align with OWASP Testing Guide. More dev focused tools, too (+1!).

1224:OWASP Education Project crossover, since they have natural ties. Can be customized for individual classes due to modularization. Can include a testing version and one with broken apps to run in separate VMs, avoid networking issues in class.

1222: /opt/owasp itself now has 732M, so it doesn’t really fit on CD very well anyway. Custom remixes coming, targeted installs, Wubi (lolwut? for the non-geeks?), kiosk version.

1219: OWASP docs also included: Testing Guide v2 and v3, plus moar program development stuffz. Top 10 for 2010 and J2EE. PDFs scraped from the project. OSSTMM and WASC Threat Classification. Repository up (appseclive.org), stable and testing. Can work with Ubuntu Software Store, Synaptic, whatever. Google Code site too, meaning the source is all there (AS IT SHOULD BE). This means the Live CD has died and is +ded+.

1212: Lots of other proxies, scanners, SQL-i tools, browser, other typical stuff. Tied to repos in some cases. Firefox caused some dependency issues, so installs a separate WTE copy that can also work with the local proxies for testing. Lots of additional plugins, generally by user request.

1208:Tools will all have entries under OWASP sub-menus and install into /opt/owasp/$pkgname. Wrapper shell script goes in /usr/bin (?) so that it’s always in the PATH. Makes it easier for us lazy types! 26 “significant” tools: Web Scarab (testing proxy), WSFuzzer (Python for web services fuzzing), Web Goat (testing environment), Wapiti (automated dynamic scanner), CAL9000 (abandoned collection of encode/decode tools), EnDe (CAL9000 on crack), DirBuster (brute force names), WebSlayer (brute forcing and fuzzing), ZAP Proxy (maintained fork of Paros).

1203: Customizations to simplify usage, which helps make security visible. Started to create his own package dependency system, but then realized no need. Doesn’t compete with BackTrack: focuses on appsec, not network pen testing.

1201: Apparently the WTE / LiveCD has lots of history, but started as a Summer of Code project in 2008. Now it’s not just a SLAX LiveCD, since that doesn’t have too much persistence and makes tool updates painful. Went to Debian packages for every tool, which creates a lot of flexibility. Now uses Ubuntu 10.10 plus a few additional tweaks, then creates a VDI / CD (and soon USB). Still works with Ubuntu repositories. Goal: make tools and docs available and easy to use.

1153: Preso has started. Hi Matt!

1148: Just joined the LinkedIn group.

1142: Introductory remarks. Happy to see a few familiar faces.

1132: Food was delicious (thanks Veracode), barring lack of coffee. Looks like we will get started in a few moments here.

1118: Checked in, meeting folks, grabbing some food. Very nice venue.

Kissing your sister: professionalism in infosec

I’ve thought more and more about 0ph3lia‘s “most honest post“. A few bits in particular rang true with me.

Sometimes I don’t know what I’m even doing in the computer security industry, but on other days, I love it to death…and I guess that’s alright.

Seven or eight years ago, somebody asked me why I got into security. I instantly answered, “because I like a job where I need to be smarter than the other guy”. And I’ve ended up doing okay for myself, but similar frustrations to 0ph3lia’s do come up. Even now that I work in incident response instead of security architecture and consulting, most of my job consists of explaining to someone why they can’t do what they just did.

That’s not really fulfilling. It doesn’t feel like working on stuff that matters. Maybe that’s why I get so annoyed when people just don’t want to listen. ‘Stepping on the air hose’ doesn’t really make something. It might help something not to get unmade, but that seems like the professional equivalent of kissing your sister.

Where do I go from here? I do enjoy IR when we really dive into the guts of a problem. Digging through many gigs of SIEM data to find the elusive evil bit gets my motor running, and I really do like crisis management. Everyone else loses their head when the fail whale comes up for air, but that’s when I really thrive. On the flip side, though, we have to avoid the temptation to turn everything into a crisis. And, generally speaking, coming into a problem after the fact means that we have to kick some ostriches in the tail rather than simply stay away from the lion.

I could stay with what I do now, of course, but I occasionally think about getting back into application security (ideally with my current employer). That could also happen in another organization that already has understood the need to build security into their SDLC. I really do want to feel like I can help build something new. Even better (but possibly more soul-sucking), maybe I should work for a security product company? I’ve previously learned the hard way that consulting doesn’t suit me, and sales engineering even less so.

For now, I’ll just resolve to blog here more often and see where that takes me. The best way to figure out what I think about something is to write about it.