Mike Weider, the CTO for Watchfire
has agreed to be interviewed for the security lab for this special
series in web app security and we certainly thank him for his time.
Mike, can you tell us something about yourself, what do you like to
do when you are not in front of a computer, Apple or Microsoft,
favorite language to code it?
When I am not working I spend a lot of time with my family. I have
three girls, ages two, four and six. Outside of that I like to
bike, run and many other kinds of exercise. I grew up on side of a ski
hill and definitely enjoy skiing and snowboarding in the winter.
You founded Watchfire, can you tell us just a bit about how it got
started, tell us something about the early days, what was the main
problem you were trying to solve.
I started Watchfire in 1996. Our initial focus was to improve the user
experience of online sites. We noted that there were many quality and
performance issues with Websites and the process for testing was very
manual. I had an idea of creating an automated testing tool for
Websites to help find and fix quality problems. Over the years we have
expanded our offerings to also test for privacy, compliance and
security. We got into the application security market through the
acquisition of Sanctum and its AppScan technology: they were the
pioneer and leader in the market and had very strong technology,
and we had a very strong enterprise platform for testing large scale
and complex sites. The fit was extremely complementary.
What can you share about the web app security market segment,
growing, shrinking, becoming more sophisticated? How would you
describe the typical customer for AppScan?
The application security market is growing fast. The growth is being driven from three core trends:
Hackers are increasingly targeting applications. The top two
vulnerabilities on the net are now application security issues. This is
very different than it was only two years ago.
Companies are now realizing they are exposed. Our estimates
indicate that 80 percent of Websites are vulnerable. Developers are not
security experts and have never been trained on security. If no one
downstream is testing, you’re going to see a lot of security issues
making it into production. This is exactly what is happening today.
Compliance is also forcing companies to move faster. PCI and
other regulations are driving companies to improve their application
security situation. Disclosure laws like 1386 and high profile breaches
are also shining the spot light on this issue by forcing companies to
tell their customers when hacks occur.
In a related question, I was just up on Fyodor’s web site,
www.insecure.org, and I noticed the banner ad for AppScan 7.5, that is
pretty cool. What else is Watchfire doing to reach customers
in unique ways?
In addition to regular webinars, in the first quarter of 2007 we
launched a series of complimentary and interactive "Hacking 101"
security workshops held in cities across North America and Europe.
These sessions provided attendees with first-hand insight into how
hackers exploit the web application layer, and explored specific
attacks including cross-site scripting and SQL injection. In North
America alone, Watchfire had well over 1700 registered attendees which
is evidence of the market demand for more education on this critical
issue.
What is the biggest focus you have for development with AppScan?
What cool new capabilities can we expect to have over the next year or
so?
AppScan’s main value to customers is automating manual security
testing. We are constantly looking for new tests to automate and
improve the accuracy of the existing tests. For example, we recently
added new tests to automate privilege escalation and testing of AJAX
applications.
Another big focus for us this year is to help customers tackle the
broader issue of application security across the SDLC. AppScan has
traditionally been used by Security analysts to test applications prior
to deployment. Now we’re seeing increasing interest in the usage of
AppScan within QA and Development groups. In response we’ve integrated
AppScan with the leading QA management platform. We have also created a
new version of AppScan targeted at application developers. QA and
Development don’t have the same security knowledge, so we’ve also
invested in training programs to help educate them. We now have over
nine hours of Computer Based Training on application security. The work
that SANS is doing in this area will also be critical to adoption of
application security in development.
On the cool side, we recently launched an exciting new program called
the AppScan Extensions Framework (AXF). With AXF our customers and
partners are now building add-ons and extensions to AppScan’s
functionality and posting them for free download on the
axf.watchfire.com site. We now have over 15 extensions that will do
anything from logging a security defect in HP Quality Center to
producing an executive summary powerpoint of AppScan results. All the
source code for these extensions is also there for free. The response
has been really positive and we expect customers to produce many more.
This is a question I like to ask everyone in this space, one of the
unique things about web applications is that one programming error can
be referenced in hundreds of instances often all of them Internet
reachable. What do you think the number one error is, the mistake a
programmer can make to guarantee a spot in the hall of shame?
The number one issue is clearly input validation. Neglecting to
validate input in one location can lead to anything from cross site
scripting, to sql injection, to buffer overflows, to remote command
execution. It's certain to cause problems in one way or another.
Mike, the security market continues to change and new threats
evolve. What are the hottest trends right now in attacking web
applications, and what can we do to prevent them?
It’s fun to talk about the hot new attacks; however, I would say the
hottest trend is the acceleration of attacks on the same old
vulnerabilities. Recent data from Honeypot projects has shown the vast
majority of attacks are targeting very simple vulnerabilities like XSS
and SQL Injection. What has increased is that hackers are now using
automated scripts to scale their attacks to much higher levels. So many
sites are still vulnerable to these attacks, there is no need to move
to more sophisticated methods. New Web development technologies like
AJAX create new security challenges. However, in most cases the
challenges are new attack vectors to exploit the same XSS and SQLi
vulnerabilities.
What we need to do to protect against this is to ensure that all
applications deployed on the net have had some minimal level of testing
prior to deployment. Ideally we would integrate security at all stages
of the SDLC from design to deployment. Some organizations are there but
many still are not. What we need to do is to “operationalize” security
the same way we have quality and performance testing. Quality and
performance testing is now a standard practice but this wasn’t always
the case. We need to get to the same level with security.
I see you have an educational outreach with events scheduled across
the country and Paris France as well, can you tell us a bit more about
hacking 101? [2]
As I mentioned previously, we have had phenomenal response to our
Hacking 101 workshop series. We’ve co-hosted these events with some key
partners and these workshops were held in more than 24 cities in five
countries including the United States, Canada, England, and France.
Targeted to IT security professionals in addition to QA and developers,
these training sessions were designed to teach attendees first-hand the
fundamentals of hacking - how to find web application vulnerabilities
through a combination of manual and automated approaches, and what to
do when a vulnerability has been identified. The half day workshop
covers the importance of web application security; the most common web
application attacks - how they occur and what can be done to prevent
them; manual versus automated approaches for scanning and identifying
web application vulnerabilities; and, finally, best practices for
fixing vulnerabilities once they have been identified.
What advice do you have for someone in the security field to stay
current on web app security, what is your favorite newsgroup, mailing
list or other information source? I know you speak at events on a
regular basis, where does a software developer go to get the inside
scoop on application security?
Watchfire.com of course! We have a lot of great whitepapers and
education material. Second best site is the OWASP.org site. There is a
ton of great information on this site.
You are a CTO, you have a technical background, if you had a close
friend, who was primarily technical, but was being offered a senior
level position such as a CTO in a mid sized company, what is the
primary piece of advice you would give him or her based on your own
experience?
As CTO you’re obviously going to spend time focusing on technology. My
advice is to not lose sight of the market and the customers. Too often
we get excited about technology for technologies sake and we lose sight
of the customer problem we’re trying to address and where the market is
moving. I would recommend spending a lot of time with customers to
understand their needs and help guide and map your company’s technology
strategy towards solving real problems for customers.
What haven’t I asked, this is your chance to grab the bully
pulpit[3], a platform from which to persuasively advocate an agenda,
and drive home your number one point that you are trying to make as a
thought leader in the industry?
My number one point has been mentioned above – we need to integrate
security into the SDLC versus the current practice of bolting on
security to the end of an existing process. We need to value security
as much as we value functionality, quality, performance and other
attributes we currently take for granted. Today I often hear of
companies deploying applications with no security testing or having to
push out applications into production with known problems because they
don’t have time or resources to fix them. If security testing was
valued and accounted for in the development process we wouldn’t be in
this situation.
Mike, we appreciate your time and willingness to share your thoughts with the SANS readership community, thank you.