Whether you call it shift-left security, baked-in security, or security-by-design, forward-thinking enterprises today understand that they need to make security a consideration throughout the entire lifecycle of not just individual applications but the business product that they support. To do this, an increasing number of enterprises are using product security teams and product security officers as a way to effect this change.
Product security expands the scope of traditional application security well beyond testing and into the realms of advocacy, collaboration between business groups, design thinking, threat modeling, architectural planning and true risk management. “By actively participating in each stage of the development process, the product security team helps embed security considerations into the software’s design, architecture, coding, testing and release to production,” says Chris Roeckl, chief product officer of Appdome. “This proactive approach is a virtuous cycle and minimizes the risk of vulnerabilities and ensures that security is an integral aspect of the final product.”
When done right, product security becomes an important lever to make good on the promises made by DevSecOps advocates for years now.
How application security and product security differ
While application security and product security share a singularity of purpose–to help an organization release and maintain secure software–the role that each function plays in achieving this goal is different. “Appsec really focuses on the testing, validation, and toolchain, while product security encompasses the business rules of the entire SDLC, including those squishy human parts of software development,” explains Michele Chubirka, staff cloud security advocate for Google.
Additionally, while the application security team takes a deep dive into each individual application they’re tasked with hardening, product security takes a big picture, end-to-end look at the security of the entire stack that helps serve up a given product. “Product security is an extension of application security. Application security concentrates on securing the code and functionality of a single software application,” says David Lindner, CISO at Contrast Security. “Product security takes a holistic view of the entire technology product, considering the broader environment and potential attack vectors that may emerge from the communications between various components.”
This broader environment could include numerous applications at once, hardware components, and associated services. Product security accounts for their security posture as they’re deployed together.
For some companies product security may focus solely on external customers but others consider even internal projects like critical back-end financial or HR systems to be within that product security umbrella. Either way, the product security outlook is more all-encompassing, explains Sam Rehman, CISO at EPAM Systems, a global software development firm. “This involves a broader scope, encompassing operational and technical controls, the overall environment, client identities, as well as mechanisms for detecting and responding to potential issues in the service,” he says.
One way to think of the difference is to imagine applications as cakes, says Christine Gadsby, vice president of product security for BlackBerry. Application security is akin to examining a single cake to be sure that it looks safe and is free from contaminants before serving it to someone. Meantime, product security is the process of improving the way the bakery makes the cakes and the tools they use to ensure that every cake is safe and tastes good. “Product security is more of a ‘big picture’ approach – the entire baking process from start to finish and ensuring you build in the right actions and process at each step to ensure the cake has exactly the correct composition, meets your customers’ delicate and maybe sensitive pallet, and remains ‘fresh’ over its lifetime,” she says. “As an organization, a product security team must consider the security of an entire list of products or systems and what customers use them, which may include several ‘ingredients’ or several cakes.”
Why product security is building steam
The fact that product security has worked its way onto enterprise organizational charts is not a repudiation of traditional application security testing, just an acknowledgement that modern software delivery needs a different set of eyes beyond the ones trained on the microscope of appsec testing. As technology leaders have recognized that applications don’t operate in a vacuum, product security has become the go-to team to help watch the gaps between individual apps. Members of this team also serve as security advocates who can help instill security fundamentals into the repeatable development processes and ‘software factory’ that produces all the code.
The emergence of product security is analogous to the addition of site reliability engineering early in the DevOps movement, says Scott Gerlach, co-founder and CSO at API security testing firm StackHawk. “As software was delivered more rapidly, reliability needed to be engineered into the product from inception through delivery. Today, security teams typically have minimal interactions with software during development. Product teams, on the other hand, engage throughout the entire lifecycle,” he says. “Incorporating security into their skill set and integrating it from product inception to release results in a quicker, more secure product delivery cycle. It’s about putting security closer to the products early on.”
At the same time, product security does not usually supplant traditional application security. Application security continues to play an important part in securing software, ideally within a well-coordinated product security framework. “It’s important to note that product security relies on appsec practices to limit and reduce vulnerabilities within the application,” explains EPAM’s Rehman. “Without addressing application-level vulnerabilities, no amount of additional security measures around the product can ensure a high standard.”
Product security teams can promote security culture
Product security plays a pivotal role in the implementation of security by design principles. It is integrally involved during the design phase of a product or service, according to Rehman. “This involvement extends to defining robust product policies and controls that are intricately woven into the product’s architecture and functionality.”
Defining product policies is just the start, as product security stands as the practical facilitators for collaboration between engineering and development, business stakeholders, and security leadership. Organizations frequently use this team as a change agent for driving the ever-elusive security culture for which so many software security gurus have advocated for ages.
“Product security teams can help create a security-conscious culture where everyone understands and prioritizes security in their daily work by regularly communicating security updates, successes, and challenges,” says Gadsby. “[They] develop clear guidelines and standards, provide resources to educate employees about best practices, and work with development teams to integrate security into the software development lifecycle.”
While product security does do a fair amount of advocacy and policy work, the best product security teams don’t just pile burdensome security requirements on others’ shoulders without supporting them. They should be there to help reduce friction, says Jamie Boote, associate principal Security Consultant at Synopsys Integrity Group.
“One particular type of friction that can obstruct security in an organization is cognitive friction–the mental effort it takes to understand and solve a security problem,” Boote explains. “Prodsec can reduce cognitive friction that developers, architects, engineers, and other stakeholders experience by providing training, clear requirements, reusable solutions, and secure-by-design components that teams can adapt and use with minimal effort.”
Leading the charge by heading up education and training of everyone with a hand in designing and coding relevant aspects of the product is a key component in product security’s role as security culture change agents, says Rehman. “Non-security professionals often lack the inherent instinct to think defensively or anticipate potential attacker perspectives–a concept I refer to as the “check every corner” mindset,” he says. “Sharing plausible scenarios, not with the intention of inducing fear, but to illustrate the potential actions of attackers is critical in fostering a security culture within the organization. When individuals grasp the possible scenarios and the assets at risk, they are more likely to adopt the correct mindset.”
Who’s in charge of product security?
All these duties and goals of product security are purely aspirational if an organization doesn’t place the right people on the prodsec team and set up an empowering reporting structure for them to successfully affect change. The best product security professionals need to have a decent mix of both technical proficiency and the soft skills that will help them foster collaboration; this is not the place for those rockstar techies who don’t like talking to people. Similarly, they’ll need a head for security and for the business and engineering aspects of delivering profitable product. “To spearhead effective product security, it’s imperative to appoint an individual with a solid blend of product knowledge and profound security expertise,” says Rehman, who advises that they’ll be empowered to communicate effectively across four key stakeholder areas: IT, the office of the CISO, development/DevOps teams, and governance, risk and compliance.
Reporting structures will vary a lot according to the needs and culture of the organization. “Some prodsec teams may be embedded in the engineering or product organizations if their larger organizations are built around products. Additionally, some teams may report to legal or compliance depending on regulatory or legal exposure,” says Boote. “But some will usually still report to someone in the CIO/CTO, CISO, or VP or director of security.”
Rehman says the most common direct reporting lines are typically CISO, CTO, and CIO. “In cases where the security organization is technically adept and robust, my preference leans towards reporting to the CISO,” he says. “Alternatively, reporting to the CTO, who oversees technology strategies, can also provide an effective home for a product security role. The choice ultimately hinges on the specific dynamics and goals of the organization.”
For her part, as vice president of product security for BlackBerry, Gadsby reports directly to the CISO. “This ensures product security efforts are aligned with our corporate security strategy and that we’re consistently implementing security measures across all products and services.”
Regardless of whether product security reports directly to the CISO or just has a dotted-line relationship, all the experts agree that CISOs should be setting the strategic vision for product security that the team executes against. “CISOs shape and guide product security teams by defining the strategic direction for product security initiatives. They consider how security will be integrated into the product development lifecycle and align it with the company’s overall objectives,” says Gadsby. “CISOs also ensure product security teams are made up of skilled professionals who can address some of the complex challenges associated with product development. There’s a lot of collaboration with other departments to ensure security measures are seamlessly integrated, and they work to establish security policies, standards, and guidelines.”