Tuesday, May 31, 2011

Our Process — How We Do What We Do and Why


A while back I published what became an extremely popular post, looking behind the scenes at WhiteHat Sentinel’s backend infrastructure. On display were massive database storage clusters, high-end virtualization chassis, super fast ethernet backplanes, fat pipes to the internet, near complete system redundancy, round-the-clock physical security, and so on. Seriously cool stuff that, at the time, was to support the 2,000 websites under WhiteHat Sentinel subscription where we performed weekly vulnerability assessments.

Today, only seven months later, that number has nearly doubled to 4,000. A level of success we’re very proud of. I guess we’re doing something right, because no one else, consultancy or SaaS provider, comes anywhere close. This is not said to brag or show off, but to underscore that scalability is a critical part of solving one of the many Web security challenges many companies face, and an area we focus on daily at WhiteHat.

To meet the demand we scaled up basically everything. Sentinel now peaks at over 800 concurrent scans, sends roughly 300 million HTTP requests per month, a subset of which are 3.85 million security checks sent each week, resulting in around 185 thousand potential vulnerabilities that our Threat Research Center (TRC) processes each day (Verified, False-Positives, and Duplicates), and collectively generate 6TBs of data per week. This system of epic proportions has taken millions in R&D and years of effort by many of the top minds in Web security to build.


Clearly Sentinel is not some off-the-shelf, toy, commercial desktop scanner. Nor is it a consultant body shop hiding behind a curtain. Sentinel is a true enterprise class vulnerability assessment platform, leveraging a vast knowledge-base of Web security intelligence.

This is important because a large number of corporations have hundreds, even thousands of websites each, that all need to be protected. Being able to achieve the aforementioned figures, without sacrificing assessment quality, requires not only seriously advanced automation technology, but development of a completely new process of performing website vulnerability assessments. As a security pro and vendor who values transparency, this process, our secret sauce, something radically different than anything else out there, deserves to be better explained.

As a basis for comparison, the typical one-off consultant assessment/pen-test is conducted by a single person using an ad hoc methodology, with one vulnerability scan, and one website at a time. Generally, high-end consultants are be capable of thoroughly assessing roughly twenty websites in a year, each a single time. An annual ratio of 20:1 (assessment to people).

To start off, our highly acclaimed and fast growing Threat Research Center is the department responsible for service delivery. At over 40 people strong, the entire team is located at WhiteHat headquarters in Santa Clara, California. All daily TRC workload is coordinated via a special software-based workflow management system, named “Console,” we purpose-built to shuttle millions of discreet tasks across hundreds/thousands of websites that need to be completed.

Work units include initial scan set-ups, configuring the ideal assessment schedule, URL rule creation, form training, security check customization, business logic flaw testing, vulnerability verification, findings review meetings, customer support, etc. Each of these work units is able to be handled by any available TRC expert, or team of experts, who specialize and are proficient in a specific area of Web security, that might take place during different stages of the assessment process. Once everything is finished, every follow-on assessment becomes automated.

That is the real paradigm buster, a technology-driven website vulnerability assessment process capable of overcoming the arcane one-person-one-assessment-at-a-time model that stifles scalability. It’s as if the efficiency of Henry Ford’s assembly line met the speed of a NASCAR pit crew — this model dramatically decreases man hours necessary per assessment, leverages the available skills of the TRC, and delivers consistently over time. No other technology can do this.

As a long time Web security pro, to see such a symphony of innovation come together is really a sight to behold. And if there is any question about quality, we expect Sentinel PE testing coverage to meet or exceed that of any consultancy anywhere in the world. That is, no vulnerability that exposes the website or users to a real risk of compromise should be missed.

Let’s get down to brass tacks. If all tasks were to be combined, a single member of TRC could effectively perform ongoing vulnerability assessments on 100 websites a year. At 100:1, Sentinel PE is 5x more efficient than the traditional consulting model. Certainly impressive, but this is an apples to oranges comparison. The “100” in the 100:1 ratio is websites NOT assessments like the earlier cited 20:1 consultant ratio. The vast majority of Sentinel customer websites receive weekly assessments, not annual one-time one-offs. So the more accurate calculation would equal 5200:1 (52 weeks). Sentinel also comes in varied flavors of coverage. SE and BE measure in at 220:1 and 400:1 websites to TRC members respectively.

The customer experience perspective

Whenever a new customer website is added to WhiteHat Sentinel, a series of assessment tasks are generated by the system and automatically delegated via a proprietary backend workflow management system — “Console.” Each task is picked up and completed by either a scanner technology component or a member of our Threat Research Center (TRC) — our team of Web security experts responsible for all service delivery.

Scanner tasks include logging-in to acquire session cookies, site crawling, locating forms that need valid data, customizing attack injections, vulnerability identification, etc. Tasks requiring some amount of hands-on work are scan tuning, vulnerability verification, custom test creation, filling out forms with valid data, business logic testing, etc. After every task has been completed and instrumented into Sentinel, a comprehensive assessment can be performed each week in a fully automated fashion, or by whatever frequency the customer preferrers. No additional manual labor is necessary unless a particular website change flags someone in the TRC.

This entire collection of tasks, all of which must be completed when a new website is added to Sentinel, is a process we call “on-boarding.” From start to finish, the full upfront on-boarding process normally takes between 1 – 3 weeks and 2 – 3 scans.

From there, there are people in the TRC purely dedicated to monitoring nearly hundreds of running scans and troubleshooting anything that looks out of place on an ongoing basis. Another team is tasked to simply verify hundreds of thousands of potential scanner flagged vulnerabilities each week such as Cross-Site Scripting, SQL Injection, Information Leakage, and dozens of others. Verified results, also known as false-positive removal, is one of the things our customers say they like best about Sentinel because it means many thousands of findings they didn’t have to waste their time on.

Yet another team’s job is to configure forms with valid data, and marking which are safe for testing. All this diversification of labor frees up time for those who are proficient in business logic flaw testing, allowing them to focus on issues such as Insufficient Authentication, Insufficient Authorization, Abuse of Functionality, and so on. Contrast everything you’ve read so far with a consultant engagement that amounts to a Word or PDF report.

At this point you may be wondering if website size and client-side technology complexity cause us any headaches. The answer is not so much anymore. Over the last seven years we’ve seen and had to adapt to just about every crazy, confusing, and just plain silly website technology implementation the Web has to offer — of which there are painfully many. Then of course we’ve had to add support for Flash, Ajax, Silverlight, JavaScript, Applets, Active X, (broken) HTML(5), CAPTCHAs, etc.

The three most important points here are:

1) Sentinel has been successfully deployed on about 99% of websites we’ve seen. 2) Multi-million page sites are handled regularly without much fanfare. 3) Most boutique consultancies assess maybe a few dozen websites each year. We call this Monday through Friday.

Any questions?


Thursday, May 26, 2011

Being a CTO is a Pretty Cool Job


As Founder and Chief Technology Officer (CTO) of WhiteHat Security, I’ve had the privilege of creating my job description along the way and finding the highest and best use of my time. Over the years my responsibilities have varied widely to include pen-tester, manager, developer, visionary, evangelist, salesman, customer support rep, trainer, slide monkey, blogger, author, janitor, and whatever else that needed to get done. What has been tremendously fun and challenging is witnessing how my role steadily evolved. Even more so now, having “officially” relocated back to Maui. Pause there, I’ll come back to that.

Most recently, before “the move,” my time had been segmented in thirds. The first spent interacting directly with enterprise security executives and software developers where I learn the most about what in Web security seems to work, not work, and where they’d like to improve. This is something I really enjoyed because it keeps my skills fresh and guidance grounded in reality.

The second part of the job is taking my meeting notes back to WhiteHat, exchange ideas with others, develop new attack techniques and defense strategies, honing company vision, and help create solutions to solve real-world problems. If I’ve learned anything at WhiteHat it’s that it takes a team, a brilliant team, to build something great.

To round things out, my job also had me compiling our Web security experience into relatable narratives, travel the globe, and present at conferences to raise awareness. This is obviously the most visible part of the job and what I’m best known for. My badge wall collection serves as a nice record of my mileage.


In the early years I focused my presentations on explaining the basic attacks like Cross-Site Scripting, Cross-Site Request Forgery, SQL Injection, Business Logic Flaws, etc and demonstrating what damage could be done. This was priority one. Later as people came up to speed, my “deep technical” presentations evolved into the Top Ten Web Hacking Techniques series.

Leading up until the last several years there was a strong need for me, THE CTO, to travel heavily and evangelize. As the number of top Web security minds employed at WhiteHat grew and the industry matured, my individual need to be a road warrior became less necessary as a strategic company imperative. As a result, I cut back my conference schedule significantly. This was a welcome change because it allow me to spend more time with my family and focus on another personal passion — security metrics.

My security metrics research grew into the now widely popular WhiteHat’s Website Security Statistics Report and represents one of the accomplishments I’m most proud of. For me, being able to generate and freely share large scale, first-hand, and hard factual data about website vulnerabilities is highly rewarding. I’ve seen the findings cited everywhere. They help push the industry forward, and have served to position WhiteHat as the benchmark for measuring the security posture of production websites. How many people get an opportunity do that!?

To this day, the enterprise need for real-world and trended metrics is growing and is an area of research I’ll continue championing for the foreseeable future. It is that future, WhiteHat’s future, and my future that I want to discuss further.

Being able to view website security from such a uniquely strategic vantage point has enabled WhiteHat to expand into root cause analysis and remediation across the entire software security domain from SDLC to operational controls; from source code to client-side security; and at scale. That’s right, WhiteHat is moving beyond simply “measuring the problem” into providing effective ways that further help solve the Web problem, quantifying cost-savings, and reduce risk of compromise.

As CTO of a fast growing company that’s headed into exciting new territory, I must focus an even greater amount of my time and attention on new and emerging technologies — something I couldn’t execute while traveling non-stop, explaining the finer points of XSS and SQLi.

What many may not know is that my wife and I were both raised in Hawaii. The island of Maui to be exact. Like many of our peers we had to leave that island paradise following high school to pursue better economic opportunities. Through a series of rather remarkable events, WhiteHat was born [near the end of 2001]. We spent practically every vacation back on Maui, our real home away from our bay area home, and of course the kids loved every second.


With a growing family, a more relaxed travel schedule, being CTO of a company in a position of flourishing success (Profitable!), it was a good time to consider a better work/life balance that could accommodate everything going on in my life. Things lined up perfectly, so we’re back on Maui, thankful to be having our cake coconut and eating it too.

As for job duties as CTO, I’ll be attending ten or so conferences a year and offsetting that time to visit more companies and build next-generation Web security technologies.

WhiteHat Security has dozens of some of the best Web security engineers in the world, many of whom are already carrying the torch in presenting on the latest developments in: XSS; CSRF; filter evasion; canonicalization attacks; new RFI and LFI attacks; DAST and SAST and the correlation of both; and much more you can learn from our presentations, read on the blog, or maybe see on display at Black Hat.

In case anyone is concerned. WhiteHat has NOT been acquired, nor are we struggling financially. The truth is quite the opposite. Every single one of the last several quarters of business have broken sales records and we’ve been hiring nonstop all year. I’ve also not retired or checked out to live a life of leisure — though I fear my wife Llana may have. I’m not done with the Web security industry just yet. When I am, I’ll be the first to tell you. :)

I wish I could share some of the projects we’ve been quietly working on the last several months, but soon enough we’ll make some announcements and shake things up! This is a very exciting time. The most exciting part for me is seeing a company I started reach a point where some of the biggest companies in the world, our customers, are demanding we lead the charge on new innovations, and help them actually solve their Web security pains. It’s a big responsibility, we’re ready for it.

Wednesday, May 25, 2011

4 Tips to Get a Conference “Call for Papers” Submission Accepted


If you’ve done unique research in information security, work that others would be interested in learning, the conference circuit provides an amazing opportunity to travel the world (for free!), advance your career, and share it with others. All you have to do is respond to one of the literally hundreds of Call For Papers (CFPs) that conference organizers publish each year and get selected to present. It sounds simple, but the process can be a bit intimidating, especially those who are new to the industry.

Since 2001, I’ve given precisely 266 public presentations across 5 continents. During that time I’ve responded to a great number of CFPs and while it doesn’t happen so often anymore, I have had many presentations rejected just like everyone else, each of which were taken as learning experience. I’ve also served on the speaker review board for HiTB and now Black Hat. In effort to help others, I’d like to offer a few tips for would-be presenters on how they can increase their chances of getting selected. But this ONLY works if you are willing to invest the energy to research something important, something cool that people should know. That part is all on you.

Because I was willing, I’ve gotten to hang out with Jeff Moss at an 80s nightclub in Singapore and been ferried around in a limousine bus with 30 other hackers, gone on all night drinking marathons with David Litchfield in Amsterdam and navigated through the nightlife scene by street beggars, gone on safari and had a lion incident with the Sensepost crew in South Africa, 4×4 dune bashing in Dubai, chilled with Mozilla at a late night Cookies & Milk Pajama Party in a private Las Vegas suite, done BJJ battle with Chris Hoff in San Francisco, and the list goes on. If you are so inclined, there is absolutely no reason why you can’t as well.


1) The BIO — differentiate and build credibility
Every CFP requires a personal biography (a bio), a text snippet that describes yourself. A bio also presents a key opportunity to differentiate yourself from the other highly qualified presenters who are competing for speaking slots.  In no more than 5-6 concise sentences, a bio must convincingly explain why you are an authority on your subject matter and why people should listen to what you have to say. A bio can be authored in different styles. For my bio, I choose to go with simple and professional, describing relevant experience, and an original feel.

2) Title & Abstract — Get to the point!
A conference is a business just like in any other and has a product to sell. That product is YOU! You and your presentation are the reason why people take the time to attend — well that and the parties and free schwag. Your presentations titles and abstracts must clearly describe to the organizers what it is that you are sharing, why attendees will care, why the content is fresh and different, and why they should see it presented live versus simply waiting for the slides to appear later on some archive.

These are the things speaker review boards want to know to make a decision, and the easier you make it on them, the better your odds. The idea of mistakenly passing on a good talk sucks, but reviewers may need to read through dozens, or maybe hundreds, of submissions. So if your abstract gets these points across in 7 – 10 seconds of reading, that’s ideal. Check out the the Black Hat conference archives for really good examples. Locate the ones that are most compelling to you and use them as inspiration.

Bonus Points: if your presentation will draw media attention to the conference, makes a new tool available, or offers scary onstage hacking demonstrations.

Negative Points: if your presentation is a thinly veiled or overt sales pitch. Some presenters will bait and switch, but this will only negatively impact your reputation.

3) Submit early, submit often
Conference organizers like get their speaker lineup formalized and posted as early as possible so they can so they can begin marketing promotions. Also, infosec speakers are notorious for playing chicken with CFP deadlines. This is horribly frustrating for speaker selection committees.  If you are well prepared with your material ahead of time, as you should be, prospective speakers who submit earlier stand a higher chance of getting selected because there is less competition. Another benefit is that if you get rejected, it’ll be earlier in the CFP process, allowing you to take a second bite at the apple.

4) Follow-up and be responsive
Conference organizers like to tap speakers who they are familiar with and have had a good prior experience. Known speakers, of course, have an easier time getting a speaking slot than a new and unknown person. If you are rather “new and unknown,” this doesn’t mean conference organizers won’t take a chance on you, but it’s in your best interest to personally followup with a phone call or email to build a relationship. The conference organizer might then give your presentation a closer look. Above all though, be responsive to communication. Few things are more frustrating than having to chase down speakers.

If you are a conference organizer, what other tips do you have?

… now if we could just get the average infosec speaker to get some media training. :)

Monday, May 16, 2011

Web security content moving to new WhiteHat Security corp blog

Many of you have noticed I haven’t been blogging in several weeks. The truth is I have been blogging, just not here! For those that missed the announcement, WhiteHat Security recently launched a new corporate blog, featuring over a half dozen other WhiteHat bloggers in addition to myself. To support and intermingle with other exceptionally solid posts, I’ve been directing my Web security content over there. If you review the archives you'll find cool stuff on scaling CSRF identification, DOM-based XSS, Bypassing CSRF tokens with a Flash 0-day, etc.

Here are some of my most recent posts that you may have missed:
See! I have been blogging. :) Consider updating your RSS feeds.

I'll continue posting here, only at a much lower volume, and exclusively about personal things like my adventures in Brazilian Jiu-Jitsu.