Technology continues to transform at an unprecedented rate and the security of that technology is paramount to its users having a trustworthy and positive experience.

For years, companies have relied on IT to run their business operations, with software applications supporting essential business functions. Vulnerabilities inherent in these applications spurred a dramatic rise in the need for corporate cybersecurity programs, which are now commonplace. However, until recently, “product security programs” were not as common, as most of the world’s companies sold products that were not digitized in any meaningful way. This has since changed and now "technology companies” are no longer siloed in the technology industry. They reside across every industry vertical where products from light bulbs to vacuum cleaners to pacemakers are being digitally transformed through the addition of a software stack and networking capability.

Ten years ago, I estimate that more than 99% of the world’s software code was likely produced by less than 1% of the world’s companies – some of the largest technology companies that had decades of experience in developing software securely. Ten years from now, we should expect that more than 90% of the world’s code will be produced by more than 90% of the world’s companies, most of them will have just gone through the process of hiring their first developers and beginning to build software engineering programs. With this change, I expect the prevalence of insecure code to skyrocket, making product security programs more essential.

To address this new risk area, some companies are establishing Chief Product Security Officer roles, who work alongside their existing Chief Information Security Officers (those focused on securing traditional corporate IT applications). Others are leaving product security responsibilities to the product development teams. In both scenarios, product security often operates separately from the cybersecurity team, which create new risks and misses leveraging unique opportunities.

However, to more effectively reduce risk and capitalize on the capabilities, intelligence and experience of both the corporate application security team and the product security team, I recommend converging these programs. Once converged, the security organization will see immediate benefits. Let’s dig into why organizations should converge these teams and the benefits.

 

What is product security and why converge?

An organization’s product security team focuses on designing security into the products it sells and responding to vulnerabilities in those products as they are discovered. Ensuring a product is secure is no small task. It means taking security into consideration every step of the way – from the design phase all the way through development, delivery, implementation, maintenance and beyond. This is often instantiated through a Secure Development Lifecycle product engineering specification.  This process helps deliver a more secure product and when done well, it can deliver cost savings. In fact, it can be 100x more costly to fix software defects in the maintenance phase than in the design phase.

Let’s compare the product security process with application security. A core component of most cybersecurity teams is a strong application security program. This ensures corporate IT applications are developed to a high security standard and software vulnerabilities are identified and addressed as they arise. For organizations with corporate IT application development teams, the application security team will specify a Secure Development Lifecycle standard for IT engineers to follow as they design and develop new applications. They’re often paired with a vulnerability management team responsible for detecting and coordinating vulnerability response for company-developed and third-party developed IT applications.

Thus, these programs are nearly indistinguishable in function ­ both help developers design vulnerability-free software and hardware and respond competently when vulnerabilities arise. However, organizations often think about and implement them completely differently as one sits within the product engineering group and the other within the cybersecurity organization. That’s right, many organizations today have two different teams performing nearly identical functions that are strategic to its business, often in a disconnected manner.

This is why Dell Technologies formed a single product and application security organization. Like many organizations, at one point we had multiple, disparate teams operating separately. Through the convergence process, we leveraged the best capabilities from each team and formed a single, new entity responsible for delivering software and hardware security capabilities. The benefits realized by this have been numerous, as I outline below.

 

Products and IT are converging

One of the primary reasons companies digitally transform their product lines is to create more data that can be leveraged for better product experiences. Digitized products produce large amounts of data and machine learning algorithms are then applied to that data to extract insights that lead to more innovative and tailored experiences. The architecture to do this mirrors a modern IT environment, as it involves adding a software and networking stack to the product and pairing it with the IT infrastructure that resides on the corporate IT network or similar environments hosted by public cloud providers.

Modern cybersecurity methods must be applied to effectively secure these environments, just like a corporate IT environment. Thus, product security requires modern cybersecurity skills and capabilities to perform well. Additionally, product architectures frequently cross into the existing cybersecurity team’s remit as they contain components that reside in the IT and hybrid cloud environments that the cybersecurity team is already charged to monitor and protect. It is foreseeable that many future attacks on products will be perpetrated by first breaking through a company’s cyber defenses to gain access to the IT infrastructure that those products trust and rely upon.

 

Talent is scarce – don’t duplicate your efforts

The war for talent is real. The 2020 ISC² Cybersecurity Workforce Study estimates a current shortage of 3.1 million trained cybersecurity professionals. The skills required to effectively secure a product are very similar, and often the same, as the skills required to secure a corporate application. Organizations must thoughtfully consider how they utilize this scarce labor to maximize leverage and scale. One of the easiest ways to do this is to create a product and application security center of excellence, where employees with these skills are pooled and their efforts focused on building tools and processes once and using many times thereafter by the product and IT application teams. This also enables a consistent and unified training motion to ensure staff retain modern skills, often by leveraging industry best practice development resources, such as those offered by SAFECode or FIRST.

 

Unify your technology approach

Product security and application security programs use many of the same technologies to perform the same functions. From static code analysis systems, to threat modeling applications, to fuzzing software, the technology used is highly specialized, and expensive to procure, train and operate. If you ask any security vendor in this space, you will commonly hear of companies paying for two or more licenses, as multiple teams in different areas of the company buy, learn and use the same technology. Not only does this result in a suboptimal license volume negotiation, it means that multiple different teams are spending time and money trying to implement these technologies, often in different ways, in a duplicative manner. Not only is this a waste of resources, it often results in inconsistent security outcomes for the customers of companies that sell multiple product lines.

 

Maximize the agility of your developers

Today’s digital organization is constantly fighting to acquire developers with modern skills. Once developers are on board, the goal is to minimize the amount of non-development time required for training and other administrative needs. However, every time developers switch teams internally, they are faced with new development environments, tools, and in most cases, security requirements and associated processes. By converging a product and application security program, one can provide a single set of consistent hardware and software security requirements, the tools and processes to fulfill those requirements, and a training program to understand them. This is particularly important as engineering departments increasingly move to a “developer pod” model, where developers work on multiple product lines and are organized according to skill or specialty, rather than product line.

 

Product security impacts cybersecurity, for those who drink their own champagne

Most companies make a habit of using their own products at the office. If you walk into a Coca Cola office anywhere around the world, you are not likely to find a Pepsi vending machine. As companies increasingly digitize their products, they are now plugging them into their own corporate networks. The product vulnerabilities that may exist now present cybersecurity risk to the corporate network. By unifying these programs, potential gaps and risks are reduced as cybersecurity teams understand and can account for product security standards, especially as a portion of their corporate cyber landscape is increasingly comprised of their own company’s products.

 

The vulnerability landscape is interdependent

A cybersecurity program will be negatively impacted as vulnerabilities are discovered in the company’s products. By integrating vulnerability management functions, teams can respond with a unified vulnerability response motion, from the point of analyzing the vulnerability, implementing temporary mitigations, and developing and deploying a final fix. This results in a more timely and effective response to vulnerabilities, for the benefit of the product security and cybersecurity programs.

Many modern products include an extensive set of third-party software components. And these third-party components are incorporated into applications that IT uses. As vulnerabilities are announced in third-party components, it’s not uncommon for these vulnerabilities to require response and remediation from both the product engineering teams (as a product vulnerability is introduced) and the cybersecurity and IT teams (as an application vulnerability is introduced). Where these teams operate separately, they’ll both need to resource labor to analyze the third-party vulnerabilities, devise mitigation options and coordinate remediation efforts. But when they’re converged, a single team can be dedicated to monitor for new vulnerabilities, gather intelligence about them once announced, and devise best practices for how to mitigate and remediate any impacted products or applications.

 

 

The challenges of convergence – just because it’s the right thing to do doesn’t mean it’s the easy thing to do…

While the benefits of converging product and application security teams are numerous, organizations should prepare strategies to mitigate the foreseeable challenges.

 

The cost of change

Any organizational change comes with a cost of planning and implementation time, communications overhead, and process re-engineering within the new organization. Usually, a percentage of employees will not be able to adapt effectively or will not enjoy the new organizational model as their responsibilities or the team culture shift, and attrition can be expected. Thus, this cost of change must clearly be weighed against the benefits. In the case of converging product and application security functions, the benefits are expected to far outweigh the change cost, but this inherent change cost needs to be considered as with any organizational change.

 

Differing cultures

Product engineering organizations often have significantly different cultures than corporate IT organizations, and the ability to partner with and influence these teams often requires security professionals who understand these distinct cultures and can operate successfully within them. Companies can mitigate this risk in a number of ways. We often hire product and IT application engineers into our security program and train them in security. In fact, some of the most effective security professionals are those who previously worked in the organization or function that they are now charged to protect, because the cultural fit and understanding is already tight. An added benefit is that it helps us mitigate the hiring challenges we see in the high-demand security market. Additionally, we host joint forums between security and product/IT teams to discuss our collective initiatives to increase common understanding amongst the teams. Further, when we develop new security requirements or initiatives, we form working groups that include the product and IT professionals who will be held to the new standards, resulting in a more adoptable and well understood set of requirements upon launch. Finally, we regularly host “voice of the customer” sessions where we proactively solicit feedback from the development teams that we serve and look for ways to continuously improve our service model.

 

Proximity to learn and influence

By moving product security specialists further away from the product engineering organization, their ability to understand and influence the product teams can be impaired. This is a risk, as often the converged security organization is sitting within a corporate headquarters function rather than the product group. To mitigate this risk and accelerate the adoption of our product security program, we pair our centralized product and application security team with a distributed set of over 500 product security engineers and specialists who are embedded within the product engineering teams as “security champions.” These champions are directly responsible for ensuring the security of those products by leveraging the training, tools and resources of the central product and application security team. This hybrid approach not only mitigates the organizational risk created by convergence, but it creates a more business-aligned security program as the security champions are able to influence and inform the central product and application security team to ensure they remain well versed in the business strategy that they support.

 

Vulnerability response

While I’ve discussed the extreme commonality that exists in how one secures developers and their code, irrespective of if they are developing a product or IT application, there are often real differences in vulnerability response. For products, vulnerabilities are often customer impacting and visible, may involve negative media publicity, and require tight orchestration between the public release of information about the vulnerability and actions needing to be taken to protect customers. IT application vulnerabilities most often only impact the company itself, are rarely made public, and can often more easily be mitigated with internal security measures as the company controls the environment surrounding the vulnerable IT application. For these reasons, product and application vulnerability response processes must be very discerning in where to leverage areas of commonality through shared process and tool excellence, while remaining sensitive to not artificially unify processes that are solving different problems on different timelines.

 

Looking ahead

There are numerous benefits to converging cybersecurity and product security programs, which clearly outweigh the challenges. Convergence benefits organizations of all sizes in all industries. As organizations increasingly digitize their product lines, having a strong product security program is no longer a “nice-to-have,” and a converged program is the best way to do it. Converged security organizations are more efficient, more effective and provide businesses the agility required to manage risks and opportunities in a rapidly changing world.

Organizations that have disparate product and cybersecurity teams today are encouraged to consider convergence. The opportunities are great as each disparate team today is not likely benefiting from the standards of excellence that exist in the other teams, and gaps or overlaps might exist where the product and cyber landscape is increasingly converging but the teams protecting that landscape are not. At the end of the day, hackers don’t form and fund separate organizations to target companies depending on the specific product or application they’re hacking. Why would we ever think we are more efficient or effective defending against them in this manner?

Stay tuned for the next article in our series on security convergence, where we explore the benefits of converging privacy and security programs. You can read about the benefits of converging resiliency and security in our last article.