Optimizing Your Approach to Securing Software Components
Optimizing Your Approach to Securing Software Components
Whether you use open source or proprietary components in your code, knowing how to secure them throughout the development process is critical.
Join the DZone community and get the full member experience.Join For Free
The business world increasingly runs on software. It's on computers, in machines and embedded in almost every electronic device available. Today, the typical enterprise runs 372 mission critical applications. Remarkably, data shows that 75 percent of third-party applications don't comply with OWASP Top 10 security policies, and 97 percent of all scans identify at least one component with a known vulnerability.
These numbers are alarming. They paint a somewhat disturbing picture of how big, complex, and insecure today's software ecosystem has become. Although most organizations attempt to ferret out problems with manual penetration testing and source code analysis tools, open source platforms and a lack of insight into vendor coding and security practices raise the stakes even further.
It's safe to say that securing software components has never been a more difficult task. What's more, as the Internet of Things (IoT) takes shape and billions of more devices wind up connected and interconnected to one another, the stakes continue to grow. Adding to the headache: a spate of new regulations and industry standards - everything from GDPR in the EU to PCI in the U.S. - are forcing organizations to become more accountable.
Optimizing a software component acquisition framework is no longer just a good idea - it's absolutely essential. Part of the solution is to establish internal standards and thoroughly vet suppliers and partners. It's also wise to focus attention on where the biggest return on investment exists. Still another way to improve a security framework is to collaborate on innovation. In addition, some organizations benefit by establishing policies and consequences for suppliers that don't meet compliance standards. Others focus on an approach sometimes referred to as "WIIFM," aka "What's in it for me?"
Finally, it's smart to align processes and workflows across a supply chain. This means identifying the relationship between value, expenditures, and responsibilities as they apply to application security. With this understanding, it's possible to address costs and who pays across enterprise borders. What's more, when disagreements or disputes pop up, there's a framework to address them. Similarly, standards and requirements must stretch across a supply chain so that business partners hold their suppliers to the same set of standards. Only then is it possible to establish a coordinated effort to address application vulnerabilities.
Putting a framework in place to address these application security risks requires an ongoing focus and commitment. It also means an enterprise must identify the key value points - and danger points - for third-party and even fourth-party code. Yet once this crucial step is completed, there's still a need to flesh out actual processes and practices. This involves getting the right people in the enterprise involved at any early stage.
Organizations typically benefit by establishing a cross-functional steering committee that taps security professionals, vendor managers, risk auditors, business unit representatives, sourcing and procurement managers, and others that touch application and code at various points in development and distribution. It's also critical to know who will oversee and perform security tasks and testing at various stages, including internal development, penetration testing, code reviews, and compliance auditing.
A Process for Evaluating Software Components
Ultimately, there are four core tasks for securing third-party applications:
1) Define a Vendor's Application Security Policy
Key issues include determining what type of security testing is required; identifying testing products or services needed; documenting the timeline and frequency of testing required; outlining the steps for every possible outcome; documenting vulnerability remediation expectations; identifying a mitigation process for coping with false-positives as well as mechanisms to deal with flaws; and fleshing out an exception and escalation process, including non-compliance penalties.
2) Communicate Vendor Application Security Requirements
There are several ways to maximize communication and minimize conflicts. Statements and decisions should come directly from the highest level possible within an enterprise - typically, this means the CIO or CISO rather than a technical support or middle level IT manager. Ideally, the statement clearly states the reasons behind the requirements. It's also wise to use in-person meetings or live conversations to present and discuss requirements, provide vendors with a clear understanding of the framework and benefits, and update terms and contracts periodically to reflect normal changes in partnerships and industry.
3) Address Vendor Commitment and Education
Vendor buy-in delivers additional opportunities. With participation, it's possible to deliver broader and deeper education about security practices, including in technical areas. This includes written guidance that instructs the vendor on all aspects of the analysis process, testing methodologies, expectations, and timelines. It's also critical to address intellectual property as part of this process. One of the sticking points for many organizations focusing on third-party code is how each organization safeguards its code.
4) Manage Third-Party Test Execution and Compliance
This is an extraordinarily difficult piece of the application security puzzle, but it's essential to analyze vendor software; issue and interpret test reports; prioritize vulnerabilities for remediation; specify how development teams make fixes; address how software retesting takes place. The latter is critical for ensuring policy compliance. One proven way to achieve all of this is with a centralized repository that tracks benchmarks and metrics along with important documents.
Outsourced Code Is Also a Concern
As organizations expand the use of outsourced code, it's also vital to address several key issues, including adopting a risk-based approach through threat modeling. Core factors include inconvenience, distress or reputational damage to the enterprise; financial losses or liability; harm to programs or stakeholders; the release of sensitive information; and criminal or civil violations.
It's also wise to establish and share security metrics and service level agreements with outsourcing providers - and to ensure that they align with internal requirements, conducting independent application security testing, setting a remediation time frame for outsourced applications, and outsourcing applications to providers that have obtained a security verification.
A holistic strategy that encompasses a process, organizational buy-in and the right technology increasingly determines whether an organization conquers or succumbs to today's software coding challenges. What's more, as the digital economy takes shape, code quality and application security emerge as competitive differentiators. Organizations that optimize security for components cut costs, improve agility, and establish a framework that allows them to unleash innovation.
Published at DZone with permission of Neil DuPaul , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.