Product Security for Software Products
As a software product grows in users the product security requirements grow. The security requirements become more critical as customers become bigger too. With rapid growth of the installed base, product managers are challenged to keep up with the product security requirements. Putting in a little time each week to focus on product security can let product managers harness the power of the whole organization.
Product Security Checklist
By focusing on a few key items, product managers can stay ahead of product security requirements. The key areas for product security on a software product are:
- Regular vulnerability testing of the product
- Static code scanning
- Incident handling process
- Documentation on security
- Cross-functional security team
Penetration Testing to Find Potential Vulnerabilities
Having a security expert run vulnerability tests against your product after a major release is the first step in a product security plan. You need to use an outside expert to execute penetration tests on your product because the outside company stays up to date on typical security exploits. Your engineering team sets up the product in the typical configuration and the the penetration tests are carried out.
The security experts prepare an internal report on their findings with a risk assessment of each vulnerability. Engineering reviews each finding to validate the level of risk and clarify any findings. After the engineering review is finished, then you can use your incident handling process and backlog management process to put the vulnerability findings into your backlog.
One other key item from the vulnerability testing is an external report for customers to understand your testing. This report expires after one year. You might need this report as a condition in closing a sale.
Code Scanning
Code scanning is handled by tools that check source code for authentication problems, access control issues, or other potential security issues. If open source code is used in your product, then code scanning is important to spot potential vulnerabilities before the product is delivered to customers.
Ideally you’d like to have code scanning running on every build of the product. This might not be feasible as many code scanning tools flag items that need to be investigated.
Incident Handling Process
Defining a process to handle security incidents across the product team saves time for product managers. The key items in the security incident handling process are:
- Definition of the levels of security risk from low to critical
- Fix response time objectives by the level of risk
- Customer communication requirements by level of risk
- Identification of the cross-functional team that responds to potential security incidents
Investing a little time to define and approve this 2-3 page document can save a product manager a lot of time. When there is a potential security incident, the team knows what to do and handles the incident quickly.
Documentation on Security
Documentation that covers product security comes in two types:
- Frequently asked questions about product security that come up during the sales process - these questions relate to customer data that is retained, security incident handling, encryption and authentication methods. A FAQ with vetted answers help sales teams support security assessments by prospective customers quickly.
- Operational security documents - documents that support customers deploying your product securely. Operational security items are:
- Information on all interfaces including ports for firewall handling
- Information on any data that the product collects on the customer
- Any known requirements for secure operation of the product such as encryption or authentication
Product managers can save time by gathering this information from engineering and prioritizing the maintenance of this information.
Cross-Functional Security Team
Depending on the criticality of the product, there can be a few to many ongoing security issues that need attention. Having a regular check of potential vulnerabilities and incidents encourages the affected team members to focus on security. This allows a regular time to discuss a shared list of security plans. The goal is to close vulnerabilities before any customers are affected.
Conclusion
Most product teams rate security very high and then find it hard to invest in security. This leads to product managers being pulled into product security issues after customers have escalated a product security flaw. Taking steps to put in product security processes when planning each release saves product manager time and prevents customer security issues.
