How to secure your product effectively

Product security is now more in demand than ever before and this blog is connecting the needs of keeping in touch with the iterative nature of the product lifecycle and not only the traditional waterfall lifecycle. The need for the security of the product generally comprises all the steps of your product lifecycle.

Team Formation and Training

The selection and training needs of the project/product according to the resource management plan should consider how the development/engineering team and security team or administrator should interact at the different processes of the lifecycle. The onboarding of both the teams should be the same so the security team is well aware of the key factors involved in the product and can implement customized security solutions, in spite of just putting standard security procedures which could leak data if not planned properly as per the dynamic nature.

Shadow Engineering

The term shadow engineering refers to applications and systems that bypass engineering guidelines and never get a security review. The shadow-engineered systems often have security leaks and non-standard forms of development.

To avoid this problem, the need to maintain a good relationship between the engineering team and the security team becomes crucial. We need to think of strategies according to the risk analysis of the product and assign high profile risks to the combination of a security person to the team of engineering which would ensure that all the security modules as also taken into consideration while development. The combined team should be in the same scrum meetings.

Penetration Testing

Often avoided/procrastinated test method which involves generating direct hacks on your system by various ways which leak the possibilities of hacks which were never even discovered before. Penetration testing allows the system to know what are the unknown vulnerabilities which could take a toll on millions in the future. You can consider penetration from an expert consultant or a third party depending upon your security strategy. I personally like this method as in the past I have seen many leaks in good products that claimed to be secured but had many leaks. This gives a real-world scenario of what we have and what should be.

Not only this, but it would also reveal the issues in the cloud security strategy and can save you a lot of money in the future.

Access Management

We have a large no of teams working together sharing codes, transferring proprietary systems over the period of development. And these transactions need tight security procedures in place. We need to be using a proper hashing system that makes sure the production environment can only be touched and modified by specific individuals. All the resources with the cloud should be maintained with a key management system for each developer team role, ensuring proper systematic transactions would protect the company's proprietary data and the leaks won't be due to misplacement of such proprietary data.

As in past, we have heard many times over, where actual user's data has been leaked only due to mistakes like these.

Team Size

As your organization grows, product security needs to grow. If you want to achieve 100% coverage of your engineering organization, there is an ideal ratio is somewhere around one product security engineer to every twenty engineers. Of course, your risk appetite may allow for less coverage. For instance, you may not need to have full coverage over internal-facing tools or code that does not go into production, like test cases.

Manual Code Review

You could define a procedure for manual review as you can't expect to inspect every line of code. You could take help of senior staff to give pointers, flags and high priority items to be passed through reviews. There are points where senior staff can directly point to where the security leaks could happen.

And never underestimate the risk of memory and performance testing, I don't see many product lifecycles including this. I have seen a product go down and just to find a memory issue it lost more than half of its users as to find the problem it took somewhat around a week.

Continuous Integration and Continuous Deployment

While usually an unlikely threat, it’s your product security team’s job to ensure that after code is written, it stays secure the entire way from an engineer’s terminal to a production server. That is to say, code is not manipulated in any way that may allow an adversary access to production data. Version control, build hosts, integration testing, and deployment pipelines are all in scope.

Start with the basics, including all your standard host security controls on these machines and collect the right telemetry to detect malicious behavior. Then focus on code integrity, design a way where you can prove that code on production matches version control. This is typically done with a code signing or hashing and maintaining a provable chain of custody. Remember to consider ways around this system: you must revoke root access from engineers to testing and production systems.

Third-Party Libraries

Third parties can bring in many risks which include bringing vulnerabilities in the first party code though this is not a common case, thirds parties could be breaching legal requirements and you not being aware of it. Third-party libraries can be compromised as well. A very careful analysis and selection system should be in place for such libraries.

Your product security team may be responsible for all these risks. The best way to tackle them is to start with a catalog of third-party libraries. Assess the risk for each of these outcomes with each library and monitor and assess the riskiest libraries.

Risk Mitigation

More often than not, your team is going to discover more vulnerabilities that can be patched while engineering can still hit product milestones. It’s important for your product security team to help the organization balance vulnerabilities against features, and not only advocates to fix vulnerabilities. If a complete fix for a vulnerability will take too much time, consider mitigating controls instead to reduce the risk.

Ultimately, it’s security’s job to help the organization balance the risk so the company doesn’t go under due to breach and still has enough resources to do the things that make them money.

Training and Documentation

Engineers should go through some sort of product security training once a year and when they join the organization. This training should cover everything engineers need to know about working with security, including when to submit design reviews, code reviews, and new third-party libraries for review. It should include secure engineering guidelines, advice from infrastructure security, and recommendations on what needs to be logged and how. Any common security libraries or anti-patterns should be documented for engineers to refer to without having to ask product security.

Shadow Trend Analysis

A trend chart could be used to track the security and risk analysis over the period to check how the team is progressing and how many processes are being passed through shadow engineering which creates vulnerabilities in the product. This metric is designed to let you describe how well your product security team is at working with the engineering organization. An increasing trend represents improved trust between product security and engineering. A decreasing trend is generally bad, but could also represent engineering following security guidelines with additional information.

A consultant could help to go through the product lifecycle smoothly and makes your life easier. You can book a free session to know how your product can be planned for best security practices and make sure the objectives are achieved in an effective and efficient manner.

Rohan Girdhani Your Sherlock Holmes