Familiarity Bias: Habit vs. Hunger
How does familiarity bias affect the decisions of application security professionals when they are designing a testing strategy?
In security, just like any other domain in our lives, people tend to make decisions largely out of habit. This phenomenon can be referred to as “familiarity bias.”
Gur Huberman is a professor of Behavioral Finance at Columbia Business School. He argues that, “Familiarity is associated with a general sense of comfort with the known and discomfort with — even distaste for and fear of — the alien and distant.”
As technology evolves and businesses innovate, it’s important to question traditional ways of thinking and objectively analyze the options that are available when it comes to application security testing.
“I suppose it is tempting,” Abraham Maslow said, “if the only tool you have is a hammer, to treat everything as if it were a nail.” Maslow’s law of the instrument refers to over-reliance on a familiar tool, an outcome of familiarity bias.
Application Security Testing Options: Scanners vs. Consultants vs. Crowdsourced Security
In order to avoid over-reliance on a familiar tool, let’s take a look at a few of the options available today. Just as the hammer evolved to accommodate more specialized uses over time, so too have the options in application security testing.
Category 1: Security Scanners
Security scanners can be programmed to automatically identify vulnerabilities, and utilize the intelligence of the engineers, architects, and product managers who made them. A security scanner is relatively easy to use compared to manual testing, and will have consistent and scalable results. Whereas a human will make mistakes from time to time, security scanners automatically find certain vulnerabilities — they don’t have “bad days” (okay, perhaps this point is arguable). A security scanner will never miss anything it is programmed to look for. At the same time, it will ALWAYS miss everything it is NOT programmed to look for.
If you have a full time application security team, using security tools can augment that team’s creativity and self-direction. There are tasks for which security scanners are extremely helpful — for example, static analysis can really assist with manual source code review.
Security scanning tools are most powerful when they are highly customized to a particular environment and application. They range from free to very expensive.
Category 2: Security Consultants
Quality security testing requires human creativity, and consultants provide testing as professional services. Consultants use security scanners and their brains to think about how attackers with malicious intentions might interact with software in unexpected ways.
Consultants are often locally sourced. If you want a particular consultant to be in a specific physical location, you will have to pay for their travel expenses. These folks are high in-demand, and are busy on purpose — high billability is desirable since most will receive a company paycheck and FTE benefits whether they are working on a client project or on the bench. Their projects may need to be scheduled in advance.
Security consultants are usually highly educated, credentialed, and expensive. They can be a great choice for security testing that requires in-person interaction with software, such as for embedded software or IoT. Consulting services are paid per person, by the hour.
Category 3: Crowdsourced Bug Bounty
A bug bounty program leverages a crowd of globally sourced researchers in competition to find security vulnerabilities in code. The once novel idea of working with the hacker community — maybe the same people who are poking at your software for fun anyway — and creating a communication channel with security researchers to enable responsible vulnerability disclosure has now become mainstream with adoption by companies such as Google and Facebook.
In a public bug bounty, anyone in the world can submit a potential security vulnerability to an organization, and the first to find a valid bug will be paid a “bounty”.
An organization running a public bug bounty will pay the cost of each bounty and manage the overhead of reviewing and filtering all of the reports (identification of false positives, duplicate removal, etc). In a public bug bounty, only one out of 10 incoming reports is likely to be a valid true positive.
A bug bounty may be used to augment an already mature security program.
Category 4: Crowdsourced Penetration Tests
A crowdsourced penetration test combines elements of bug bounty and traditional security consulting. Heavily vetted domain experts are selected from a crowd of globally sourced researchers and work collaboratively on a time-boxed (e.g. two-week) penetration test of a web application, native mobile application, or set of APIs.
Due to the cost benefits of leveraging a globally sourced freelance pool of researchers, an organization performing crowdsourced penetration tests will typically be able to perform more tests to achieve greater coverage across an application portfolio (and/or more frequent tests on code that changes more often).
The crowdsourced penetration test team works together to find security issues (fewer duplicates, false positives), resulting in a higher signal to noise ratio than typically seen in a public bug bounty. Re-test and verification of patches is also done by the crowdsourced penetration tester, facilitating not only the finding but also the fixing of security issues.
Crowdsourced penetration tests are a great starting point for an organization looking to jumpstart their application security program, agile shops that need frequent testing, and organizations looking for coverage across a large application portfolio.
Strategy: Three Factors to Consider
Every business will have a combination of different software environments and specific security needs. To determine which security testing methodology (or combination of methodologies) would be the best fit for a given scenario, the four categories described above can be evaluated using three key factors:
Ease of use
Your specific testing goals should drive the prioritization of these factors. An organization that needs to pass PCI compliance or a vendor security assessment may prioritize these factors differently than an organization with an agile testing process or one that is focused on training developer teams in application security.
Key Factor 1: Scalability
Scalability matters most for organizations that manage tens or hundreds of applications in their software portfolio. It matters less for an organization that has a single app.
Scanners: Scanners, like all technology tools, can scale very well for monolithic environments, assuming that all of the requisite “care and feeding” is in place.
Consultants: Consultants don’t scale as well, because they are premium experts who are paid by the hour.
Crowdsourced Bug Bounty: Crowdsourced bug bounty can attract many researchers if a program is appealing, but doesn’t necessarily guarantee that experienced, focused eyes will be testing the software. A robust vulnerability management process and sufficient analyst bandwidth to triage incoming reports is required to handle the low signal to noise ratio that is inherent in a bug bounty model. For a price, payment and communication with researchers can be outsourced to a bug bounty management platform.
Crowdsourced Penetration Testing: Crowdsourced penetration tests scale well due to their relatively low cost (compared to traditional security consultants) and high signal to noise ratio. Because a lead must review the findings before they are submitted and the researchers work collaboratively instead of competitively, only high quality findings are delivered to the organization.
Key Factor 2: Coverage
A malicious attacker will try everything they can to reach their target. In order to mimic that in security testing, it’s important to have coverage across an application portfolio and through comprehensive test cases.
Scanners: Scanners cannot think creatively or find design flaws; they will only look for what they are programmed to find. For example, they have predictable coverage. The areas they don’t cover are also predictable.
Consultants, bug bounty hunters, and crowdsourced penetration testers can think creatively and brainstorm misuse and abuse cases, which a scanner cannot do. They can consider application business logic and identify design flaws in addition to “just” findings bugs.
Consultants & Crowdsourced Penetration Testing: Consultants and crowdsourced penetration testers often have a procedural approach to ensuring coverage — a checklist of sorts — that includes the OWASP Top 10 or the ASVS. Bug bounty programs are continuous and in theory have an “infinite” number of eyeballs on the problem, but the approach is more “scattered” and there is no guarantee that a particular bug bounty program will attract technology-specific skills or a large volume of researchers.
Crowdsourced Bug Bounty & Penetration Testing: Crowdsourced bug bounty and penetration testing both have the advantage of a globally sourced pool of researchers. Bug bounty provides a potentially larger volume with a broad spectrum of skill sets and experience; crowdsourced penetration tests include multiple researchers who are highly vetted, skilled, and focused.
Of course, all humans are vulnerable to human error. A scanner will find the same issues today as it will tomorrow (assuming matching configuration), but a human may find something different today than he or she would tomorrow.
Key Factor 3: Ease of Use
Ease of use matters. A lot. What’s the total cost of ownership (people, process, and technology) for each of these security testing options?
Scanners: Scanners need to be customized in order to get the most value. There’s no way for a scanner to know (unless you tell it) where to look, where not to look, what to look for, what to ignore, what matters, and what doesn’t matter. Scanners require manual tuning in order to effectively crawl web applications and scenario-specific manual configuration to test any sort of business logic. Certain types of vulnerabilities (authorization and session management) can be particularly difficult for scanners to find.
Scanners and public bug bounty programs both generate a lot of findings (low signal to noise ratio) that must be filtered manually in order to get to the set of true positive findings. Scanners produce a large number of false positives unless they are carefully tuned and results are filtered, and the bug bounty model produces many duplicates.
Consultants: Consultants deliver fewer findings with a higher signal to noise ratio, typically in a PDF report. An organization might manually enter the findings details into a bug ticketing system so that the information gets to a developer who can remediate the issues. Or, the findings remain isolated in a PDF on a Sharepoint site or spread out in various email threads.
Crowdsourced Penetration Testing: Crowdsourced penetration testing provides higher quality findings because removal of irrelevant reports is done before the results are provided to the organization. This option also provides support to an organization past the “find” phase and throughout the “fix” phase by allowing an organization to communicate directly with researchers and request re-test and verification of patches.
What Matters Most: Find & Fix
What is it that matters most when it comes to security testing? Whatever combination of people, process, and tools you choose, you want to find as many true positive findings as possible so they can be addressed.
The reality is that security bugs and flaws exist in your software, regardless of whether you know they are there or not. But you cannot fix security issues if you cannot find them.
Once you’ve performed defect discovery in order to find as many true positives as possible, the next step — by no means a trivial one — is to communicate them to the developer team, get them to prioritize the fixes, get them to remediate the issues, and ideally prevent the same issues from coming up again. Fixing security issues is not a technology problem; people and process are also required to get it done.
You’ve got to find the issues — the real ones — and you’ve got to fix them. All while managing cost and coverage across an application portfolio.
At the end of the day, you want to take an honest look at the application security testing options available and evaluate them based on the factors that matter the most to you and your organization.
Consider your organization’s security objectives and choose accordingly:
If your goal is to build SecDevOps into a large development team, consider using security scanners as a foundation for your testing program and augment the scans with crowdsourced penetration testing.
If your organization seeks SOC2 compliance, consider working with consultants in order to ensure coverage and a strong brand.
If you want to establish a public communication channel with external security researchers, consider employing a public bug bounty program.
If you want to increase the frequency of penetration tests on your application portfolio and integrate security testing with your release cycle, consider crowdsourced penetration testing.
The choice is yours! Make an educated decision, not simply one out of habit.
For more on this topic, watch the on-demand BrightTALK webinar.