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.

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. 

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:

• Mythbusting: Static Analysis Software Testing – 100% Code Coverage
• PROTIP: Security as a Differentiator
• PROTIP: Publish Security Scoreboards Internally
• Recent SQL Injection Hacks – Things You Should Know
• If You Want to Improve Something, Measure It
• An Incident Is a Terrible Thing to Waste (even those of others)
• (CYA) Cover Your Applications – All of Them
• The Necessity of Compliance Alone Is Insufficient for Justifying Security Investment
• Theory: Google will open source their Web server — or should
• Are 20% of developers responsible for 80% of the vulnerabilities?

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.

Are 20% of Developers Responsible for 80% of the Vulnerabilities?

That’s the question I recently posed in a twitter exchange with @securityninja and @manicode. For those unfamiliar with the Pareto principle, also known as the 80/20 rule, is where roughly 80% of the effects come from 20% of the causes. This Pareto principle phenomenon can be seen in economics, agriculture, land ownership, and so on. I think it may also apply to developers and software security — particularly software vulnerabilities.

Personal experience would have most of us agreeing that not all developers are equally productive. We’ve all seen where a few developers generate way more useful code in a given amount of time than others. If this be the case, then it may stand to reason that the opposite could be true — where a few developers are responsible for a bulk of the shoddy vulnerable code. Think about it, when vulnerabilities are introduced, are they fairly evenly attributable across the developer population or clumped together within a smaller group?

The answer, backed up by data, would have a profound affect on general software security guidance. It would to more efficiently allocate security resources in developer training, standardized framework controls, software testing, personnel retention, etc. Unfortunately very few people in the industry might have the data to answer this question authoritatively, and then only from within their own organization. Off the top of my head I can only think that Adobe, Google, or Microsoft might have such data handy, but they’ve never published or discussed it.

In the meantime I think we’d all benefit from hearing some personal anecdotes. From your experience, are 20% of developers responsible for 80% of the vulnerabilities?

Theory: Google will Open Source Their Web Server — or Should

 

Google has two competitors, market-share and Microsoft. Google already dominates the online advertising industry, so there is not much more room for them to grow. They must expand the available market. Secondly, Google wants a slice of that Microsoft Office cash cow, representing $19 billion a year in sales, which is exactly what Google Apps for whatever is all about. For them to win the name of the game is NOT security, it is NOT privacy, it is SPEED. Pure unadulterated Internet speed. For Google, Internet speed equals more page views, more pages views equals more ads delivered, on an Internet wide scale (i.e. market expansion). Internet speed also makes Google Apps more attractive as compared to Office, especially to business customers.

The first salvo in the “Let’s make the web faster” battle plan was by unveiling the speed demon Google Chrome and escalating the second browser war. At that very moment Microsoft was faced with a difficult choice. Internet Explorer must either match pace with Google Chrome or lag behind and risk losing their dominant market-share position to their sworn enemy. Whatever Microsoft decided would be a win for Google, who could care less about browser market-share because Internet Explorer was slowing things down for years. If Microsoft sped up Internet Explorer, Google Apps would look that much better as opposed to Office. If they did not, browser market-share moves to Chrome or Firefox and Google Apps still looks better. What else could Microsoft do, they jumped into the browser speed game.

My theory is the second stage of the “Let’s make the web faster” plan is about to begin and will take place on the other end of the connection, the Web server. Google has been developing an experimental protocol called SPDY (pronounced “SPeeDY”) meant as a modern day open source alternative to HTTP, TCP, and SSL. SPDY offers unlimited concurrent streams over a single TCP connection, request prioritization, header compression, server-initiated requests, and doesn’t require any changes to be made to the existing networking infrastructure. Reports state SPDY deployments are resulting in a performance boost between 15% and 50%. That’s huge for any website operator. Oh, and if you are a Chrome user, you are already using SPDY on Google.com properties.

To get SPDY widely adopted, Google will likely open source a web server (GWS) that supports the protocol. Work has already begun on an Apache module. Microsoft, with a respectable 18.83% IIS market-share that drives Windows server sales and .Net development, must either support SPDY or risk losing market share to GWS or Apache. And to make the decision just that much harder, Microsoft must also slap SPDY into Internet Explorer. As before, Google would be fine either way, both options make Google Apps look better as compared to Office and gets more ads get delivered.

What does this mean for the Web security professional? Time to learn how to deploy, defend, interrogate, and hack SPDY.

The Necessity of Compliance Alone Is Insufficient for Justifying Security Investment

 

It is often much easier to justify investing security resources that are legally or contractually mandated than basing such investments on the overall value to the company of an adequately funded information risk management group. Given this disparity of  funding “must do” tasks while overlooking “should do” tasks, security teams can take the initiative and do the “non-essential” actions that strengthen their organizations’ security as they meet compliance requirements. This approach  also provides a security group the information it needs to justify requests for risk management resources.

The compliance standards currently applicable to application security include PCI-DSS, HIPAA, FFIEC, GLBA, ISO 27001/27002, and Sarbanes Oxley. A organization’s failure to comply to their standards can lead to fines, legal action, and sometimes even business shutdown. When executive management is faced with these possibilities, a typical conversation with the company’s security staff usually results in the conclusion that,  “The company must spend $A on X compliance mandate because non-compliance with regulation X carries an estimated cost of $B.”

As obvious as it may seem that compliance requirements should convince management to allocate funds for security, the necessity for compliance is often insufficient to get management to actually make the needed investments.

Government and/or industry-mandated regulations can frequently differ in how they impact an organization,  and typically can be applied differently to each organization. Some organizations may be able to change specific aspects of how they do business, and thus meet mandated requirements by changing the parameters of compliance. Other organizations,  after estimating that the punishment for non-compliance will cost less than the costs necessary to comply, may decide to simply ignore the notification to comply.

At WhiteHat we think a more realistic way to look at compliance issues is that in some instances you MIGHT get hacked, but for ignoring certain regulations you WILL get audited. In either case it is essential to understand the “historical record” of how a particular compliance standard has been applied within an industry; and to then be able to estimate the capital and operational expenditures required for your organization to comply. This way, when management asks you to justify your request for funding based on how NOT DOING SO would impact business, you’ll have the information immediately at hand, which will make the decision-making process far easier.

(CYA) Cover Your Applications – All of Them

In the interests of personal and corporate preservation, performing minimum standards of information security with due care and on a pre-incident basis is a wise course of action. That way, if and/or when an incident occurs, you – and your organization – can show that all “reasonable” steps, a.k.a., “industry best-practices” have been taken to ensure the security of data. Otherwise, legal claims of gross negligence can be made against the organization, and/or an attempt can be made to identify and remove a staff member who will serve as the “corporate scapegoat.”

Based on this scenario, what are the industry standards for spending and for best-practice safeguards in application security? Several resources are available to use as minimum standards of due care.

The most well known is “The Payment Card Industry’s Data Security Standard,” and specifically section 6.6.  This section refers to the OWASP Top Ten, which is the level of application security that credit card merchants must maintain. Substitute any digital assets that need to be protected for the term “cardholder data,” and Section 6.6 standards can be applied to just about any organization.

For estimating a reasonable security budget to meet industry best-practices, the OWASP Security Spending Benchmarks project and the “State of Web Application Security” report by the Ponemon Institute provide recent data on organization spending habits. The Building Security In Maturity Model (BSIMM) study of thirty, large-scale software security initiatives also details the activities that organizations typically implement to meet security standards.

Overall, however, it is important to remember that although adhering to arbitrary best practices can serve as a starting point for establishing adequate security, best-practices alone are insufficient for building a comprehensive and effective information security program.

An Incident Is a Terrible Thing to Waste (even those of others)

 

Hacks happen. The data captured by Verizon’s Data Breach Investigations Report, DataLossDB, and WASC’s Web Hacking Incident Database make this reality painfully obvious. The summary is most incidents, and the bulk of the data lost, is a direct result of vulnerable Web applications being exploited. As further evidence, Forrester’s 2009 research reported, “62% of organizations surveyed experienced breaches in critical applications in a 12 month period.” Dasient, a firm specializing in web-based malware, said “[In 2011] The probability that an average Internet user will hit an infected page after three months of Web browsing is 95 percent.”

These resources and the compromises of Apache.org, Comodo, Gawker, HBGary Federal, MySQL.com, NYSE, Sun.com, Zynga, and countless others are a good excuse to have a conversation with management about your organization’s potential risks.

Despite the facts, the idea of getting hacked is not often a conscious thought in the minds of executives, so of course it’s only a matter of time before the business becomes another statistic. When this happens and the business is suddenly awakened from a culture of security complacency, all eyes will become focused on understanding exactly what happened, why it happened, and how much worse it could have been. In the aftermath of a breach, employee dismissal and business collapses are rare, more often than not security budgets are expanded. Few things free up security dollars faster than a compromise, except for maybe an auditor.The security department will have the full attention of management, the board, and customers who all want to know what steps are being taken to ensure this never happens again. Post breach is an excellent time to put a truly effective security program in place, not just built around point products, but designed around outcomes and to have a lasting impact.

If You Want to Improve Something, Measure It

 

During the past five years WhiteHat Sentinel has performed comprehensive vulnerability assessments on thousands of websites. These assessments are ongoing, as performing continuous assessments is integral to our core values at WhiteHat. With each assessment we analyze the results − discovering new facts about Web application security, share that knowledge through reports, and receive feedback from companies about which information has done the best job helping them secure their websites.

Now that we’ve gathered this large amount of data on website security, we believe that any security professional can use the seven metrics − all measurable and mostly automatable − listed below to track the performance of their application security program and the software development lifecycle that drives it.

The Seven Key Application Security Metrics

1. Discoverability – The Attacker Profile
What are the risks of a vulnerability being discovered, and what type of attack − Opportunistic, Directed Opportunistic, or Fully Targeted – will the attacker use? Does the attacker need to be authenticated in order to breach security? Is the damage that the attacker can cause within the risk tolerance of the organization attacked?

2. Exploitability – The Difficulty of Attacking
Are the site’s vulnerabilities possible to exploit? Theoretically? Possibly? Probably? Easily? Are proof-of-concept exploits available for demonstration purposes? Is it becoming more difficult for attackers to exploit issues previously identified? That is, from day to day are there less trivial vulnerabilities per application, and are the remaining vulnerabilities less likely to be exploited?

3. Technical and Business Impact – The Severity of the Attack
What negative impacts can the vulnerabilities have on the business – both technically and financially? If a vulnerability is exploited, is the breach communicated within the organization and is an estimate made of the possible damage – quickly? Once an attack is discovered will business stakeholders and development groups within the company prioritize the risk and take action to remediate the problem accordingly?

4. Vulnerabilities-per-Input – The Attack Surface
How common and how deep across the codebase are the vulnerabilities exploitable? Does the codebase become more secure – or less secure – as new code and acquired code are added; as legacy code requirements increase; and as new technologies are introduced?

5. Window of Exposure – The Exposure to Attacks
How often is the organization exposed to exploitable vulnerabilities: Always, Frequently, Regularly, Occasionally, or Rarely? How effective are the quarterly or annual remediation efforts? What is the best method for shortening the window of exposure time, i.e., the risk of compromise? Is the risk diminished by reducing the number of vulnerabilities being introduced? By increasing remediation speeds? By fixing more of the system security issues?

6. Remediation Costs – The Opportunity for Greater Savings
What are the costs of fixing the vulnerabilities that are discovered? Over time, is the cost-per-defect to remediate the vulnerabilities decreasing? Is it possible to decrease “lost opportunity costs,” i.e., to reduce the time that developers spend “fixing” security issues rather working on new business projects? And how can the efficiency of developers’ remediation efforts be improved?

7. Defeating Vulnerabilities – The Focus on Identifying Their Source
What type of code or which business unit is introducing the vulnerabilities? Are the vulnerabilities internally developed, third-party developed, from acquired software, etc.? When multiple vulnerabilities are discovered, where should the focus of attention be on immediately? Can the level of software security be improved through developer training, contractual obligations, software acceptance policies, etc.?

“To Improve the Process, Measure the Process”

In summary, corporate security teams often tell us that their businesses need to become much more concerned about their Web application security. I’m sure many of you readers can relate to such comments. At WhiteHat we’ve learned that the three primary obstacles to establishing a successful website security program are: (1) compliance issues, (2) company policies, and (3) a lack of data that will support the need for greater security.

While compliance issues and company policies may sometimes work to get management’s attention, I believe that data – hard numbers – work much more effectively.

When management understands how secure – or unsecure – its websites are, how secure they have been in the past, and how the company’s current Web security compares to the security of its competitors, then almost certainly the resistance to devoting more resources to Web security will diminish. Furthermore, there will be new respect within management for both the Web security services provided and the teams providing them.

As the old saying goes, “If you want to improve something, measure it.” Because almost anything that can be measured will improve. Which of the 7 metrics discussed here are you measuring today? Which of these metrics are you currently unable to measure at all? And are any of the important metrics presented here missing from your list?  Or maybe you have new ones to add!

Recent SQL Injection Hacks – Things You Should Know

SQL Injection, the remote root exploit for Web applications, has been the initial attack vector behind several high profile compromises over the last six months. MySQL.com, Sun.com, HBGary Federal, Comodo’s RA (GlobalTrust.it/InstantSSL.it), eHarmony, Nasdaq, Savannah GNU, PlentyOfFish, Royal Navy Website, BoingBoing, and no doubt countless others we’ll never hear about. Let’s also not forget if a website is serving up drive-by-download malware, as many thousands have already, chances are it’s because a SQL Injection exploit inserted a malicious iFrame. Clearly OWASP made a good call placing “Injection” at the top of the Top Ten.

Here are some quick tips to avoid becoming tomorrows headline and an end of the year statistic:

1. If Parameterized SQL statements, not Stored Procedures, are used everywhere in the code, the odds of SQL Injection vulnerabilities will drop dramatically. Purge all forms of concatenated database query strings and add a healthy code of input validation. There is no substitute.
2. Suppression of verbose error messages is still a good idea, but DO NOT do so just to get the vulnerability to “go away” in the application vulnerability scanner report. Fix your code. Don’t be fooled by vendors claim of Blind SQL Injection detection in scanning products. The lack of verbose error messaging remains serious hindrance to automated detection with painful side effects. Direct source code access the has advantage here on comprehensiveness — use to your advantage.
3. Hack yourself first. That means ALL your websites. Not just the “main” ones. Learn what the bad guys know or eventually will. Attackers are quite capable and smart enough to compromise  secondary websites, use them as launching pads, and then pivot around the network.
4. Detect any malware on website(s) before Google does. Failure to do so will get you black listed from search results. Give Dasient a look.

Yes there are many other things you can do to prevent SQL Injection, like detecting attacks with WAFs/IDS or database hardening procedures. Only let’s get some of the basics down first shall we?

PROTIP: Security as a Differentiator

Update: The counter point, Security is rarely a differentiator, via Mike Rothman (@securityincite)

Every company needs a competitive advantage, the more the better, and “security” can be a powerful differentiator. This is because security is very important to people and is becoming more so with each passing day of computer-hacking-privacy-invading headlines and virus infected PCs. People need and want to be able to trust those who ask for their names, contact details, email, social security numbers, health information, payment data, and so on. When security is made visible (i.e. help customers be and feel safe), the customer may be more inclined to do business with those who clearly take the matter seriously over others who don’t.

“Making security visible” can be achieved through offering strong and flexible security controls, documentation about a comprehensive infosec program, recent audit reports conducted by an independent third-party, contractual SLAs, etc. As an information security professional, imagine being able to ask for budget to do these things and more by saying to a CxO, “If we invest $A on B (security thing), our sales & marketing department research estimates an increase in new customers and financial upside of $C.” As long as C is great then A, then you have a strong business case.

All of sudden security budgets go from being perceived as a unavoidable cost of doing business, where the goal is to spend the least amount of dollars possible, to a vehicle that drives revenue. Nothing beats that! To get there security pros must engage with sales and marketing personnel, and of course customers and prospects, to see how often “security” is a buying criteria. Understand what customers want and the premium value potentially applied to the sale. Successful efforts result in an excellent opportunity to align with the business objectives and everybody wins.

Mythbusting: Static Analysis Software Testing – 100% Code Coverage

 

Many Web security professionals believe that because Static Analysis Software Testing (SAST) has access to the source code and / or the binary of an application,  it can deliver “100% code coverage.” Proponents of this assertion also claim that SAST therefore offers a more comprehensive vulnerability analysis than Dynamic Analysis Software Testing (DAST). This belief is a myth.

Arbitrarily declaring that one form of testing is superior to another is like saying that a household thermostat is better at measuring heat than a meat thermometer. Sure, both devices do measure heat, but that’s where the similarity ends. Source code access absolutely has its benefits, but just like comparing the functions of a room temperature gauge and a meat temperature thermometer, there are many other important distinctions between SAST and DAST that must be considered.

SAST and DAST should be used for different purposes, because they are adept at identifying different classes of vulnerabilities, and at different stages of the Software Development Life-Cycle (SDLC). That is precisely why SAST and DAST should be considered complementary, and NOT competitive with one another. As when performing most tasks, to achieve the best results you need to match the right tool for the job at hand.

SAST Is the Better Choice During Code Writing & QA

SAST, for instance, is ideal for helping to reduce the number of security defects in an application introduced during the code writing and unit testing phases of SDLC. However, SAST products lack the ability to discover defects that are introduced during the requirement stage or just prior to deployment.

Nevertheless, many organizations have found value in SAST, because any amount of accurate vulnerability data that developers have as they write or commit code can mean the difference between fixing a vulnerability within days as opposed to weeks, months − or maybe never.

DAST Is the Better Choice When the Application Is Functional

DAST is typically deployed in late-stage QA or production when the application is functional, and therefore ideally suited for testing how truly secure a system is against an attacker who has a given amount of skill, time, and access to the website. As such, the comprehensiveness of DAST should meet or exceed the “bandwidth” of the adversary that the organization would like to repel. That’s why DAST is often considered to be superior for measuring outcomes − after SAST,  SDLC processes, and security controls have been implemented.

Busting the Myth About SAST and Its “100% Coverage”

Based on the information about DAST and SAST presented to this point, let’s see if we can bust the myths about SAST and the “100% code coverage” that some claim it can provide.

1. SAST Fails to Find Vulnerabilities Located Outside the Code

SAST searches are confined to checking either the source code or binary code, while many very serious website vulnerabilities are located elsewhere. In a recent example of being able to overcome SAST searches, “Bloomberg News” was able to obtain financial earnings data for Disney, NetApp, and other publicly traded companies hours ahead of any other media organization.  “Bloomberg News” then funneled the information to its customer subscriber terminals. Obviously, if you’re a stock trader, having access to earnings data before anyone else does is like discovering nuggets of pure gold. Surprisingly, Bloomberg was able to break through the extensive security on the top-level websites by using a very common Web hacking technique called “Predictable Resource Location (PRL).” PLR is used so commonly, in fact, that at WhiteHat we have found during testing of customer websites that PLR is an issue for 14% of those sites.

In this example of “Bloomberg News“ accessing earnings’ announcements before their public release, the companies had uploaded their financial reports to a secret location on their websites just prior to the stock market’s closing on the day prior to the “official” public announcements.  The companies then hyperlinked the content of their reports immediately after the New York Stock Exchange’s closing bell marked the end of trading for the day.

Unfortunately, the URLs to the “secret & secure” financial reports that Bloomberg published prior their official release were easily guessed. For example, Q2 2010 earnings for Disney were found at www.disney.com/earnings/Q22010release.html and Q3 2010 earnings were at www.disney.com/earnings/Q32010release.html.

It certainly didn’t take a genius at “Bloomberg News” to figure out where the Q4 earnings report might be found. Basically, someone on the Bloomberg staff periodically checked the “guessed” URLs, waiting for the exact moment when the documents associated with them became available, i.e., were uploaded. While the files were technically hidden, “security by obscurity” was the only safeguard to prevent a breach of security.

These simple hacks, which were possible due to minor security mistakes, nevertheless caused extremely serious breaches of Web security for several world-famous companies. And recently, both the national and international press have reported many similar examples of security breaches based on simple methods for hacking “highly secure” websites.

Clearly, SAST – with its “100% code coverage” – fails to find these types of issues. DAST on the other hand can and does find them, because it can perform an educated brute force search to discover these types of files.

With PRLs being 14% of the hacks that we find at WhiteHat, they are on our Top Ten List of Most Pervasive Vulnerabilities. Two other types of vulnerabilities NOT typically found in source code: “Information Leakage” – 64% of websites, and “HTTP Response Splitting” – discovered in 9% of websites.

2. SAST Is Unable to Find Vulnerabilities in Third-Party Code Unless It Has Access to That Code

One of the most often-mentioned shortcomings of a SAST deployment is the difficulty it has in capturing the entire code base of an application. That’s because the code is often spread across the enterprise in separate repositories, or resides in different business units that may share the same code, and /or is located in compiled libraries supplied by third-party vendors. While “100% code coverage” is possible to achieve in theory, the reality is much different.

If you are using third-party ISVs that are unwilling to provide source code, which is often the case, then the only alternative is to rely on binary analysis. However, what if the third-party software your application relies upon is also hosted at a different physical location, such as a remote website or XML Web service? In that case, you must request authorization to test the software, and even if the vendor grants your request, only DAST can perform a test under those circumstances.

3. SAST Is Unable to Prioritize Vulnerability Resolution Based on Exploitability

Let’s say a security professional wants to prioritize remediation efforts in the context of a particular vulnerability’s: (1) likelihood of discovery, (2) difficulty of discovery, (3) potential negative impact on business and/or regarding technical risks, (4) Web Application Firewall (WAF) virtual-patching potential, and (5) the relative skill required for the exploitation to be successful. These are the most critical metrics to prioritizing “risk.” Given these factors to consider, business stakeholders are left with the difficult decision of whether to: (A) transfer product development resources to fix a vulnerability that may or may not be exploited, risking potential financial loss IF it is, or (B) ignore the issue in the short-term in order to publish the new feature(s) that WILL definitely cost the company money if it is not delivered on time.

Experienced Web security professionals know this situation of “making a choice that’s really a guess” occurs quite often, and that an IT executive must have the insight to make the most well-informed security risk decisions. That’s because SAST itself is limited to simply analyzing the source code, and is thus unable to provide this kind of insight. Even if SAST could provide 100% code coverage − whether early in the software development lifecycle or at any other time − it can never deliver the degree of intelligence that DAST can.

4. SAST Is Unable to Find Vulnerabilities Caused by Intermediary Components

Websites can be an incredibly complex collection of Web servers, Web applications, application servers, databases, load balancers, caching proxies, Web application firewalls, CDNs, and more. The interaction between all of these discrete components as they process user-supplied input often causes unexpected security issues to occur that are only discoverable at run-time or production.  One component in the flow might encode or decode a piece of data before passing it onto the next layer, and then that layer encodes yet another piece of data and passes it on to the next layer, and so on. And security issues like these cannot be replicated in QA. Furthermore, SAST can analyze only code that is at rest, and it has no contextual knowledge of any intermediary components, let alone the ability to test them under these conditions.

For example, in one of the checks used at WhiteHat Sentinel, we HTML entity encode a standard Cross-Site Scripting (XSS) test, then base64 encode that value, and finally URL hex encodes that. The result is an almost nonsensical, backwards, triple-encoded, filter-evasion / canonicalization attack that would seem to have absolutely no chance of succeeding. Only it does.

app.cgi?foo=JTI2JTZjJTc0JTNiJTczJTYzJTcyJTY5JTcwJTc0JTI2JTY3JTc0JTNiJTYxJTZjJTY1JTcyJTc0JTI4JTMxJTI5JTI2JTZjJTc0JTNiJTJmJTczJTYzJTcyJTY5JTcwJTc0JTI2JTY3JTc0JTNi

Astonishingly, a check such as the one above has indeed found a non-trivial amount of vulnerabilities. On the way in, the string has no “special” characters, so it is allowed to cross the first filter gate. However, as the data passes through the system, each hardware component or application layer may recognize an encoding, decode it, and then pass it along to the next component − until the fully decoded string eventually finds its way back to the Web browser in a vulnerable XSS state! We’ve also found similar vulnerabilities in Content Spoofing, HTTP Response Splitting, and SQL Injection.

While it may be easy to classify these vulnerabilities as edge-cases, in our experience of assessing over 3,000 websites − from start-ups to Fortune 500 companies − and performing thousands of filter-bypass experiments, there are hundreds of edge-cases like the one described here,  and websites are susceptible to a wide variety of such techniques. Most double and triple-layered attacks score in the single and sub-single digit vulnerability percentage of total websites, but a surprising handful score up to low double-digit percentile (e.g. 10%, 12%, etc).

5. SAST Is Unable to Find Business Logic Flaws

To be fair, DAST is unable to find them, either. But that’s the point: “100% code coverage” is basically meaningless when it comes to Business Logic Flaws, which make up an extremely important segment of website security issues. For example, let’s say that a website allows users to reset their password if they’ve forgotten it. In many cases users must enter their email address and correctly answer a previously defined secret question. The secret question is personal, making it easy for a person to remember, but also difficult − hopefully − for others, i.e., attackers, to guess. Often the level of difficulty is less than assumed, such as “What is your favorite color?” or “What is your date of birth?” That’s because many systems using this type of password security method contain pools of likely answers that are too small to prevent brute force attacks designed to access user accounts.

This class of issue / attack, which is called Weak Password Recovery Validation, is just one of many types of Business Logic Flaws that SAST or DAST scanners are unable to identify without human intervention. The fact is that you can use the most advanced automation – even if it has access to the application source code and binary – and still fail to find certain types of vulnerabilities. Furthermore, if your SAST or DAST scanner shows clean results, you could have problems of the worst kind – the ones you don’t know you have. Many companies have discovered this only after the damage to their sites and customers had been done.

Essentially, Business Logic Flaws must be discovered manually, by analyzing source code or testing for them at run-time. If possible, do both procedures; but “manually” must be the method.

6. SAST Won’t Find Vulnerabilities in Code That It’s Been Told Is Safe

One of the most vital elements of writing secure software is input validation. This is the act of testing incoming data to make sure it conforms to what is expected to be received before allowing it to be used. Rock solid input validation, which includes data normalization and checks for length, character-set, and format is peerless in its ability to wipe out vulnerabilities such as Cross-Site Scripting, SQL Injection, Command Injection, etc. To check if a particular data path is being protected by an input validator a SAST scanner must guess at the right subroutine or be told the location by its human operator. In either case the problem is input validation libraries / subroutines are often not perfectly implemented. That is input validators will often contain security gaps that DAST can find ways to bypass. Clearly there is a difference between an input validator that’s applied and one that actually works well. SAST can only reliably verify the former case, potentially missing many vulnerabilities, while DAST excels at the latter and finds those missed issues.

7. SAST Has A Difficult Time Finding Vulnerabilities in Client-Side Code

Much of the code in a current Web 2.0 application is executed on the client rather than on the server. Because of this, and for several years now, an increasing number of vulnerabilities have been found in Web applications that use large amounts of client-side code, such as JavaScript and Adobe Flash. This client-side code also resides on websites that use third-party Web Widgets, such as ads, traffic counters, user polls, security badges, social buttons, etc. The growing amount of interaction based on user-supplied data, in code that may or may not be your own, has provided many new locations for Cross-Site Scripting vulnerabilities to exist. This type of vulnerability is generally referred to as “DOM-based” Cross-Site Scripting.

While the source code to client-side applications is technically available to a Web browser’s “view-source” functionality, SAST scanners designed with Java, PHP, ASP.NET, and other types of support are rarely helpful with JavaScript or Adobe Flash. Just as with Business Logic Flaws, most client-side code vulnerabilities must be found manually, aided by purpose-built penetration-testing tools.

Conclusion

Again, when used very early in the development process SAST is a great resource for discovering software security defects, and for locating improper code constructs and policy violations. SAST also enables organizations to identify code flaws while the code is being written, and to isolate bugs all the way down to the line of code and to the developer who checked the code in. However, the idea that SAST can find all issues, at all times – or even that SAST can find all the high severity vulnerabilities – is a myth.

The best advice is to determine precisely what your organization needs to measure; then to select the most appropriate software security testing methodology for making the measurements. Because doing the process the other way around would be like using a tape measure to figure out if a house has termites.

So, after reading in the six examples above about what SAST fails to do, or is unable to do, or finds difficult to do, what you think? Is the SAST “100% code coverage” myth busted?

Sentinel SecurityCheck

Have you been hearing about WhiteHat Sentinel for a while, but never had the opportunity to try out the service for yourself? We'd like to change that and make Sentinel accessible to more people. We've recently announced a new promotion, for those who are interested and qualify, to receive the full customer experience for 30 days -- for FREE. This is way more than just finding vulnerabilities. If you like it, great sign-up! If not, which is extremely rare, you owe nothing. Follow the link below for additional details.

WhiteHat Security Announces No Cost Website Vulnerability Assessment Program
Sentinel SecurityCheck offers organizations 30 days of continuous assessment to identify all website vulnerabilities and mitigate leading risk for data breaches; Participating companies gain access to WhiteHat Security's verified vulnerability results and personalized guidance on website risk management

11th WhiteHat Website Security Statistic Report: Windows of Exposure

WhiteHat Security's 11th Website Security Statistics Report, presents a statistical picture gleaned from over five years of vulnerability assessment results taken from over 3,000 websites across 400 organizations under WhiteHat Sentinel management. This represents the largest, most complete, and unique dataset of its kind. WhiteHat Security makes this report available specifically for organizations that aim to start or significantly improve their website security programs, prevent breaches, and data loss.

Top 3 Key Findings (Full list available in the report)

• Most websites were exposed to at least one serious* vulnerability every day of 2010, or nearly so (9–12 months of the year). Only 16% of websites were vulnerable less than 30 days of the year overall.
• During 2010, the average website had 230 serious* vulnerabilities.
• In 2010, 64% of websites had at least one Information Leakage vulnerability, which overtook Cross-Site Scripting as the most prevalent vulnerability by a few tenths of a percent.

Window of Exposure is an organizational key performance indicator that measures the number of days a website has at least one serious vulnerability over a given period of time.

Download the Full Report...

Robert “RSnake” Hansen, age 34, has passed away, on Facebook

Facebook encourages people to keep up with friends and family through those familiar little website reminders notices. In some cases the person suggested in the reminder has passed away, which would explain the account inactivity, and this might obviously be taken as offensive and emotionally distressing. Facebook recognizes this and offers a process where they allow accounts to be “Memorialized” on the recommendation of a “friend” by filling out the appropriate form.

“When a user passes away, we memorialize their account to protect their privacy. Memorializing an account sets the account privacy so that only confirmed friends can see the profile or locate it in search. The Wall remains, so friends and family can leave posts in remembrance. Memorializing an account also prevents anyone from logging into the account.”

As many readers might recall, a couple months ago Robert “RSnake” Hansen, best known for his contributions to Web security, bid his farewell in a final 1,000th blog post. Since RSnake has departed “the scene,” he is effectively dead in an online sense. As such some felt it only fitting that his Facebook persona follow a similar path and shake off its digital coil. To get RSnake’s page memorialized all that was required was finding a person who shared the same name, who had a recent obituary published somewhere online, lived in roughly the same area, and then fill out the necessary form. Not to long after...

If you are a Facebook friend of RSnake, you may still pay your last respects to him on his wall. Rest assured that while he can no longer reply himself, he is indeed smiling (or LHAO) down on us all from above.

PROTIP: Publish Security Scoreboards Internally

 

Scoreboards have been around forever, used to show who’s winning, how competitors rank, and sometimes track what has transpired. Scoreboards are seen in sports, video games, stock markets, box office sales, traffic analytics, education, and on and on. As a fundamental concept, scoreboards also have the powerful ability to harness a basic human instinct — competitiveness. Leaders at the top of a scoreboard will naturally work to preserve their position, those further down are innately compelled to fight to move up, and collectively all participants similarly driven towards a common objective. Using this influence many organizations have found that using scoreboards to measure and communicate “security” objectives can be amazingly effective at aligning business interests.

Achieving similar success requires first choosing a useful and collectable set of security metrics where the organization would like to improve. Anything measured tends to improve. These metrics may be the total number of vulnerabilities, remediation rates & speed, vulnerabilities-per-input, percentage of developers passing awareness training, time exposed to serious issues, and so on. Next, start collecting data. When enough is gathered, the results are properly formatted, typically organized by subsidiary, business unit, or team, and the reports published internally for all too see. Security scoreboard leaders will be proud to see their performance recognized as they set the standard for coworkers to follow. Laggards feel a sense of pressure to do the things necessary to close the gap with their peers. Less and less will security teams have to chase down the weakest links, those needing the most help will begin seeking them out.