What is Product Security?
The complexity of software is at an all-time high, growing more complex with every passing year. Our distributed systems are so large that even small teams of people can’t fully understand them. A single issue can cost hundreds of millions of dollars or take out an entire 911 system.
In this ever-evolving, complex world of software development, how can we make security a priority in the face of the coming software apocalypse? There isn’t a one-size-fits-all solution to address product security across all organizations. There are, however, a few best practices that many organizations have had success in implementing.
In this article, we’ll investigate why we continue to face the same types of problems when it comes to security. Security tends to only be prioritized later on in the lifecycle of an application. In a typical organization, the responsibility of ensuring product security is often left up to a single group. Security needs to be a priority across the entire product lifecycle and at earlier stages. So what can we do to manage security in the product development lifecycle?
Why Current Security Efforts Fail
In a typical organization, the responsibility of ensuring an application is secure generally falls to the development team. While developers are ultimately responsible for fixing any application security issues that come up, we can’t put all the responsibility on their shoulders.
Let’s take the example of a static analysis tool. A static analysis tool analyzes the code base to identify security flaws. While this can be useful, there are limits to the types of issues these tools can address. These tools will also generate a lot of findings, which means someone has to triage the results. This can take up a lot of time. Thrusting a tool into the development process without proper planning can create more problems than the tool winds up solving.
One of these problems is a desensitization to security issues that the tool reports. Triaging dozens (or hundreds) of issues that are mostly false positives will erode trust in the tool. When the tool doesn’t have a clear owner, other problems will appear, including real issues marked as false positives.
While the appropriate tools are quite useful, they can only help to a certain extent. Automated tools can’t find higher-level issues in the architecture of an application. When discussing design decisions, if security is not on everyone’s mind, mistakes will follow. Since, at this stage, many decisions revolve around the application’s interaction with other internal or third-party services, a mistake made here can be expensive and time-consuming to fix at later stages.
Where Does Security Belong?
Everyone knows security is an important aspect of development, but who’s responsible for it? Well, not to spoil the surprise (hopefully it isn’t a surprise), but the answer is that security belongs everywhere, and everyone is responsible for it. Why should security be just one team’s responsibility?
Let’s break down the common areas where security gets managed.
Operations
Application or product security often starts in operations as a byproduct of operational security. Network and application scans and third-party assessment reports all get fed back into the development process, where the developers investigate and fix the issue or determine it’s a false positive and forget about it. In many cases, the operations team either doesn’t have the expertise to triage the finding or isn’t empowered to ensure that the development team is taking security seriously. At this level, the bulk of testing is really just “surface testing.” Tests are not in-depth enough to find serious problems with application architecture. Manual assessments can find some of these issues, but since the application is already released (or close to being released), fixing issues at this stage in the product’s life is very expensive. Application security here is reactive, not proactive.
Quality Assurance
Quality assurance can take many forms, depending on the organization. Sometimes the QA team is only testing against business cases and often doesn’t have enough insight into the design and architecture of the product. This makes it difficult for the team to fully understand how it functions behind the scenes. If the QA team does find serious problems with the application, they can face an uphill battle to get any traction on having the issues remediated. Since security testing is closely related to other forms of testing, including security as part of quality assurance efforts may make sense. However, just like with operations, security as part of quality assurance is still reactive and not proactive enough.
The Development Team
The ultimate responsibility for resolving most security issues and ensuring that code is written securely lies with the development team. However, the development team often doesn’t have the ability to push back on schedules. They also may not have a lot of say in the architecture of applications. This is the first product life-cycle stage where it’s possible to be more proactive with security. Even if the architecture isn’t perfect or if there are design decisions that could be better handled, the development team is the last stop before work really begins. The weight of the development team’s input on these matters varies widely throughout different organizations and sizes. This is especially problematic when development is outsourced since consultants will likely be hesitant to bring up major issues.
The Executive Level
If an organization is large enough to have a chief security officer (CSO) or a chief information security officer (CISO), these figures play a huge role in the organization’s security practices. However, the person in this role probably doesn’t have time to dedicate to all the intricacies of product security throughout the development lifecycle. While this may not be true in all cases, if the organization is large enough to need a CISO, then it’s probably large enough that the CISO will need to be focusing on higher-level policy matters along with product security.
If it seems to you like there’s something missing, like there needs to be a way to incorporate security throughout all these stages, you’re right. Product security, like product management, is a cross-cutting concern that bridges the gaps between many other departments. A product security manager has responsibilities at all stages in the lifecycle of an application, from ideation and design to construction to continuous improvement of the privacy and security of the product post-release.
Moving Security to the Left…the Far, Far, Left
There’s a push in the industry to move security to the left, but what does “moving to the left” mean? If you think of the development process as a line moving from left to right—from design, development, testing, and post-production release—in many organizations, security only plays a role at the far right. This is usually through some kind of third-party assessment activity. Findings from the assessment are then fed back into the development process for developers to fix.
Often, the first step to move security to the left (i.e., earlier in the development process) is through integrating with static analysis tools. These tools search for issues in the code base during development so developers can fix them before the code even makes it to testing. Fixing any issues early saves time and money down the road.
This is a great first step to ensuring that security is on everyone’s mind when developing applications. However, there’s a problem with this approach. It’s a first step, not something to consider at the end. And though any kind of tooling in the development process is great to have, these tools have limitations. They’re only able to find implementation level issues, like SQL injection, cross-site scripting (XSS), and other code-level issues. Tools such as these will miss higher-level problems such as those involving authentication and authorization.
To be effective, security has to move even farther to the left. It has to move into the design and planning stages. These stages are critical in the product development process, and a bad choice here can have expensive implications after product release. This is where product security management comes in.
Introducing the Product Security Manager
In order to gain an understanding of product security, let’s take a look at the role product management plays. Product managers lead the cross-functional team that’s responsible for guiding the product, including setting the strategy and roadmap, all to ensure the product is a success. Additionally, their responsibilities may include marketing and budgeting activities—or in fact, any activity that may affect the success of the product.
Like product management, product security is a cross-cutting concern with implications at every stage of the product lifecycle, even in marketing. Social media plays a significant role in marketing, and no one wants to deal with account takeovers or hijacking.
The focus of product security is on not just protecting but also building. But where does this role fit in the development process?
Conclusion
Security is an ever-evolving process. It’s never done, and the landscape is constantly changing. It’s not possible to manage the product security lifecycle from within smaller groups of the development process. Product security needs someone to oversee all areas of the product’s life, from inception to post-release. This person needs to understand the complexity of software, along with best development practices. They also need to have a firm foundation in architecture and design. On top of all of this, they need security knowledge. The role of a product security manager is a tough one to fill, with knowledge needed across multiple constantly changing technical landscapes.
Despite the difficulty in fulfilling this role, it’s no longer optional. It’s necessary to consider a product security manager an essential part of a mature software development practice.
It’s time to stop leaving security for last.
