Thousands of small business owners reeling from the aggressive measures taken to halt the spread of the coronavirus may have had their personal information exposed last month on a government website that handles disaster loan applications.
read more
Originally posted on 12/28/2016
It seems so tempting. Solve your application security problem by throwing an appliance at it. After all, if web applications are the most common form of attack, why not just protect them the same way you protect your network and email servers, and be done with it? Why should you spend timeﾂ?hunting down vulnerabilitiesﾂ?in your code and figuring out how to fix them?
The ???appliance throwing??? approach would be viable if web application firewalls (WAFs) were perfect, but protecting your app layer with only a WAF leaves a lot of holes. WAFs, at their heart, are black-box protection technologies that rely on inspecting incoming traffic for known attack patterns ??? and that???s often not enough. There are circumstances where WAFs will leave you vulnerable to attack, for instance:
ﾂ?
Missed attack due to new patterns
A WAF tries to use known attack patterns to protect an application. It can be tuned via writing rules, but attackers are coming up with new patterns all the time. In fact, creating WAF bypasses is something of a cottage industry for security researchers, to the point thatﾂ?you can download cheat sheets for creating WAF bypasses from security researchers like @Pentestit_ru and @themiddleblue, the editor-in-chiefﾂ?from 1337pwn, or the well-known OWASP foundation.
And that???s not even including the risk of new vulnerability categories. Veracode Community member Mark Merkow from HealthEquity notes, ???Even if a WAF is configured 100 percent correctly and catches and stops attacks it knows about successfully and every time, it’s still at risk for letting new attacks through, including zero-day attacks. With Web Services and API communications as the most likely future form for all apps, WAFs will become less and less useful. What will survive in this new world are well-written, high-quality, resilient applications that can stand up to endless attacks.???
ﾂ?
Missed attack due to application changes
Based on the results of a penetration test or other evaluation of an application, you can make a WAF very accurate by creating rules that focus on specific input fields and types of vulnerability. However, you have to maintain these rules every time the application is changed. The SANS Institute notes, “During the WAF deployment, everyone involved understands exactly which form fields and inputs are vulnerable and to which attack categories but, over time, this knowledge fades.ﾂ?Many organizations lack the in-house expertise to conduct penetration tests every time they change the web application or WAF configurationﾂ?(and miss the opportunity to ensure a vulnerability was not introduced).???
SANS issued this report over five years ago. In the intervening years, the frequency of application updates has only gotten higher thanks to increased adoption of agile software development and DevOps. This means that the window of time during which a WAF configuration should not require updates due to application changes has dramatically decreased.
ﾂ?
Missed attack due to configuration complexity
The same SANS report notes that it???s not uncommon for WAFs to be extended to cover more applications than they can handle, to fail under high load, or to have a high number of false positives. For this reason, some organizations configure their WAFs to alert only in the event of a potential attack, rather than try to block it ??? which means that a successful attack will likely be missed in the midst of other alerts from the WAF.
There are definitely still benefits to deploying WAFs, including avoidance of denial of service attacks and???when properly configured??? some protection against an attack. If nothing else, they slow an attacker down.
ﾂ?
No application security silver bullet
Effective application security requires multiple technologies that protect apps in different ways and in different stages of their lifecycle. As Veracode Community member, Glico Man, said in a recent comment, ???WAF is a ???safety net??? and may provide ???virtual patching??? until the application code is fixed??ｦ A well-configured WAF will provide more time for a developer to fix their code.???
If you???re going to use a WAF, you won???t be protecting your products from attack indefinitely. So use the time a WAF gives you wisely; figure out where the underlying vulnerabilities are in your application and fix them. For instance, consider an automated application security solution that integrates into your SDLC, allowing developers to find and remediate security-related defects early in the development process.
ﾂ?
Cyberattackers are increasingly focused on the application layer; it???s critical to understand both how this layer is being exploited, and which solutions protect it most effectively. To learn more about application security solutions and where to start, check out the Ultimate Guide to Getting Started With AppSec or visit the Veracode Community page. ﾂ?
Companies of every size and in every industry are changing the world with software. From healthcare to agriculture, education, and manufacturing, software is enabling unprecedented advancement and innovation. But if that software is insecure, these innovations may get held up, or worse, put us at risk. And this is a very real concern; our most recent State of Software Security report found that 83 percent of applications had at least one vulnerability on initial scan. In turn, testing the security of software and addressing any security-related defects is a critical undertaking.
However, it’s important not to lose sight of the fact that effective application security secures software throughout its entire lifecycle — from inception to production. With the speed of today’s development cycles — and the speed with which software changes and the threat landscape evolves — it would be foolish to assume that code will always be 100 percent vulnerability-free after the development phase, or that code in production doesn’t need to be tested or, in some cases, patched.
An effective application security program requires some “human” elements beyond testing, including:
Developer secure coding training, because the vulnerability that is never introduced will always be the cheapest and easiest to fix. Most developers don’t receive training on secure coding, either in school or on the job, but when they do, it pays off. Data collected for our State of Software Security report found that eLearning on secure coding improved developer fix rates by 19 percent.
A solid vulnerability disclosure policy, which ensures that vulnerabilities unearthed by security researchers are addressed and disclosed in an effective manner. Veracode’s co-founder and CTO Chris Wysopal notes that, “Today, we have both tools and processes to find and reduce bugs in software during the development process. But even with these tools, new vulnerabilities are found every day. A strong disclosure policy is a necessary part of an organization’s security strategy and allows researchers to work with an organization to reduce its exposure. A good vulnerability disclosure policy will have established procedures to work with outside security researchers, set expectations on fix timelines and outcomes, and test for defects and fix software before it is shipped.”
Bug bounty programs, which put the power of multiple security researchers behind your application security. Wysopal says of bug bounty programs, “bringing in outside hackers with their own attack tools will uncover new risks. This is one of the clear values of bug bounty programs.”
Ultimately, effective application security focuses on both prevention and detection. You wouldn’t let your kids play with matches just because you have a fire extinguisher. On the other hand, even if you teach your kids about fire safety and never let them play with matches, you wouldn’t toss out the fire extinguisher. Fire safety requires prevention and detection, as does application security.
Testing your code for vulnerabilities early and often in the development process, and assessing the security of both third-party and open source code are all essential software security steps. But detecting and responding to vulnerabilities with human solutions plays a critical part as well. Developer training, a vulnerability disclosure policy, and a bug bounty partnership all play a role.
Continue this conversation with us at our fall road show; we’ve teamed up with Bugcrowd and Edgewise on a series of networking events — coming to a city near you!
Most legacy applications were not developed with security in mind. However, modern businesses and organizations are continuing to undergo digital transformation in order to pursue new business models and revenue channels, as well as giving their customers or constituents a simplified experience. This often means selecting cloud-based tools and solutions that allow for the scalability necessary to provide applications and services to a broad customer base.
For example, in 2013, the UK government adopted a Cloud First, or Cloud Native, policy for all technology decisions, making it mandatory to consider cloud solutions before alternatives. This means that government IT professionals must first consider public cloud options, including SaaS models for enterprise IT and back-office functions, as well as Infrastructure as a Service and Platform as a Service.
But this dramatic expansion of the application layer introduces new security challenges. In one engagement, Veracode worked with a High Street bank to secure its web application portfolio and uncovered 1,800 websites that had not been inventoried – making its attack surface 50 percent bigger than originally thought.
With the growing complexity of IT infrastructures and a shortage of qualified security experts, businesses and government agencies alike need to enlist application security specialists with a deep understanding of the complexity of modern applications.
Veracode pioneered static binary analysis to address the security of modern applications, which are often comprised from different teams, languages, frameworks and third-party libraries. This approach allows security and development teams to assess the security posture of entire applications once they’ve been built, rather than analyzing individual pieces of source code and missing some of the potential “cross-platform” exploits.
Yet the Veracode Platform offers so much more than its signature static binary analysis.
“With a growing number of integrations with CI/CD tools and development environments and expanding its coverage to the full software supply chain, Veracode clearly shows the commitment to fully embrace the modern DevOps and DevSecOps methodologies and to address the latest security and compliance challenges,” writes KuppingerCole Lead Analyst Alexei Balaganski. “With the SaaS approach, the company can ensure that customers can start using the platform within hours, and a wide range of support, consulting and training services means they are ready to guide every customer towards the application security best practices as quickly as possible.”
To learn more about our approach to supporting modern DevOps and DevSecOps methodologies, and how the Veracode Platform is even easier for software developers to use, download the KuppingerCole Report, Executive View: Veracode Application Security Platform.
The basic blocking and tackling of defining and executing an application security program includes having an executive mandate, a policy, and an inventory of your applications. These comprise the minimum requirements to successfully define and execute a program. But once a program is defined, what are the factors that make it successful? Optimizing your application security program means setting it up in a way that is “most conducive to a favorable outcome” and set up for growth, scale, and success (Merriam Webster).
As I’ve worked with our customers to optimize their programs over the past seven years, I see four distinctions that separate fledgling from mature AppSec programs:
- Nurture a Culture of Secure Software Delivery
- Look Forward With Analytics
- Engage with Developers Through Vulnerability Scrums
- Integrate AppSec Into the CI/CD Pipeline
Leaders who follow these four recommendations have seen their AppSec programs become the model for their company’s larger vulnerability management programs. They have seen the number of applications they onboard into the application security program rapidly scale, increasing the coverage of applications under risk management – from legacy apps on the ground to next-gen apps in the cloud. And they have seen a concurrent and sharp decrease in the number of existing open flaws (security technical debt) through remediation across static analysis, dynamic analysis, and manual penetration testing.
Nurture a Culture of Secure Software Delivery
Application security is as much a cultural problem as it is a technical problem. DevSecOps requires:
- Collaboration across development, security, and operations
- Visibility into applications and clear ownership by lead developers
- Escalation processes when teams don’t meet their remediation commitments
- Risk-focused discussions and decisions on a case-by-case basis. Application security can be aligned alongside larger company initiatives such as cloud migration, data center migration, and monolithic and microservice architecture.
- Security champions
- A granular policy with expectations that is communicated and enforced
Look Forward with Analytics
Use analytics to not only measure how far you’ve come historically, but to also provide direction on future priorities. For example, some of the most helpful metrics are Scan Aging (average number of days since the previous scan for a group of apps in a BU) and Flaw Aging (average number of days flaws have been open in a BU). These can be compared against a company’s grace period and scan frequency policies to identify out-of-compliance teams and applications. Start with the worst offenders each week to quickly show progress in addressing risk.
Engage with Developers Through Vulnerability Scrums
Once you have a culture that wants to do something about AppSec, plus the metrics in place to measure, you can mix those together to get prescriptive next steps for addressing pockets of non-compliance. The next-step action items can be laid out before each team of developers to guide them on where to apply their tools and efforts for the benefit of the program.
Integrate AppSec Into the CI/CD Pipeline
The CI/CD pipeline is the new firewall, where you can prevent insecure code from being released to production. The benefit of a secure SDLC is that application security flaws will be caught earlier on in the development process and fewer flaws will escape into production, reducing the risk of insecure code being deployed. A mature and secure SDLC will have security overlayed and integrated into each stage of the development process, as early as possible and with the least impact to the developer.
The outcome of a secure SDLC is that applications will be released to production with fewer vulnerabilities to fix later, they will be compliant with policy, and critical vulnerabilities will be prevented from escaping into production – all while leveraging automation and shift-left code scanning technologies to allow developers to write software quickly and securely.
These four areas provide the tools for making application security part of the DNA of software development. For more information, please watch the webinar Optimizing Your Application Security Program.
- 1
- 2