A recent study from Columbia University found that we’re bogged down by more than 70 decisions a day. That's if you only count the important ones, as previous research from Cornell University determined that we make over 200 decisions just regarding food in any given day.
Many of the decisions we make in a day are inconsequential in the long term. The impact is minimal, and most cannot be categorized as "good" or "bad". They are merely the choice we made. But some choices have significant consequences. Some are intentional and made with forethought. Others are unintended and only become obvious with hindsight.
Some unintended consequences that seems obvious with hindsight relate to the security of our applications.
CHOICES: PLATFORMS, FRAMEWORKS, and COMPONENTS
From the first day of development, choices are being made. Many of those choices revolve around platforms and frameworks, libraries and third-party components. There are a lot of these choices made during development. It is estimated today that 80-90% of an application is comprised from open/third-party source components. Each of the choices that leads to the inclusion of an open/third-party sourced component has potential consequences, particularly with respect to application security. Black Duck Software's analysis claims an average of 105 open source components per commercial software offering.
Those consequences, on the surface, are not that terrifying. After all, research from Contrast Security finds that software libraries represent just 7% of vulnerabilities. Black Duck found an average 22.5 open source vulnerabilities per application. Forty percent (40%) of those vulnerabilities were rated as 'severe.' Still, that's minimal considering the remaining 10-20% of an application - custom code - is responsible for most of the vulnerabilities in applications.
Unfortunately, the bulk of vulnerabilities aren't disclosed via CVEs and sample exploit code made easily accessible to attackers. Bad actors need not work that hard to find targets in an environment where the same components and libraries are often in use by thousands upon thousands of web applications. Right now, builtwith.com - which tracks the use of technology used to build apps and websites - counts nearly 40,000 live sites that rely on Apache Struts. Most of us are aware of the successful exploitation of published vulnerabilities in Apache Struts 2 that led to a mild panic on the Internet. Similar panics have been caused by serious vulnerability disclosures involving other heavily used open source and third-party libraries, such as OpenSSL.
But it's not just the choice of whether we include libraries or third-party components or build apps on open source frameworks that's potentially problematic. Other choices we make during development can also have serious repercussions, particularly when they lead to insecure development practices.
CHOICES: TRADING SECURITY for SPEED
It is never a surprise to hear that security has been traded for speed. It has always been the case. A 2014 McAfee survey of 504 security professionals found that "roughly a third of organizations surveyed, operators admitted that they attempt to increase network performance by routinely disabling firewall security features."
Development, it turns out, is no different. Their focus is not on execution speed, but on pipeline speed. To meet demands for more timely releases of applications and updates to the market, many admit to skipping security during development entirely. A 2017 Arxan | IBM survey of mobile and IoT developers discovered that 26% of respondents do not test mobile apps at all for security issues, and nearly half (48%) do not test IoT apps. Pressure to deliver was cited by 69% as the reason security is often skipped.
A poll of attendees at our customer event, Agility, this summer reinforced this is reality. Over half - 62% - admitted they had traded security for speed in their organization.
And then there are the choices made regarding how organizations address discovered vulnerabilities. Black Duck's analysis revealed that 10% of applications scanned in 2018 were still vulnerable to the 2014 Heartbleed vulnerability. A ServiceNow study conducted by Ponemon found a disturbing 57% of breach victims disclosed they could have prevented the breach by installing an available patch.
CHOICES HAVE CONSEQUENCES
From day one of development to post-deployment, the choices we make regarding the security of the entire application stack are important. These choices aren't on par with having a burger or salad for lunch; they are decisions whose ramifications can reverberate not just through IT and the business, but to customers that rely on app providers' taking security seriously.
There are very few of us who can claim to have never received a "Dear App User" letter informing us that our data has been exposed. That isn't a license to be lax with security; on the contrary, we should all endeavor to do better by our customers in safeguarding personal, private information.
The best way to do that is to recognize that every choice from day one of development is an opportunity to improve the security of the applications we develop. Choose consciously and wisely.
About the Author
Related Blog Posts
At the Intersection of Operational Data and Generative AI
Help your organization understand the impact of generative AI (GenAI) on its operational data practices, and learn how to better align GenAI technology adoption timelines with existing budgets, practices, and cultures.
Using AI for IT Automation Security
Learn how artificial intelligence and machine learning aid in mitigating cybersecurity threats to your IT automation processes.
The Commodification of Cloud
Public cloud is no longer the bright new shiny toy, but it paved the way for XaaS, Edge, and a new cycle of innovation.
Most Exciting Tech Trend in 2022: IT/OT Convergence
The line between operation and digital systems continues to blur as homes and businesses increase their reliance on connected devices, accelerating the convergence of IT and OT. While this trend of integration brings excitement, it also presents its own challenges and concerns to be considered.
Adaptive Applications are Data-Driven
There's a big difference between knowing something's wrong and knowing what to do about it. Only after monitoring the right elements can we discern the health of a user experience, deriving from the analysis of those measurements the relationships and patterns that can be inferred. Ultimately, the automation that will give rise to truly adaptive applications is based on measurements and our understanding of them.
Inserting App Services into Shifting App Architectures
Application architectures have evolved several times since the early days of computing, and it is no longer optimal to rely solely on a single, known data path to insert application services. Furthermore, because many of the emerging data paths are not as suitable for a proxy-based platform, we must look to the other potential points of insertion possible to scale and secure modern applications.