Product security has become an essential aspect of cybersecurity, especially in the age of IoT, smart devices, and complex software applications. This interview aims to delve into the evolving landscape of product security, discussing challenges, strategies, and best practices for building secure products from the ground up.
Biography: Jayesh Singh Chauhan
Jayesh Singh Chauhan is a security professional with over a decade of experience in the security space and he is the founder of Cloud Village. He has previously been part of the security teams of PayPal, PwC, Sprinklr Inc. and currently works as the CISO of CoinSwitch. He also founded Cloudurance Security, a company specializing in providing security consultancy and training for companies looking at securing their Cloud Infrastructure.
He has been a trainer at conferences like Blackhat, nullcon, OWASP NZ and has trained the defense forces. He has also authored Cloud Security Suite, OWASP Skanda, RFID_Cloner, and has presented his work in BlackHat Arsenal (USA, EU, Asia), DEF CON DemoLabs, HackMiami, c0c0n, OWASP Global, and OffZone Moscow.
The Interview :
Section 1: Introduction to Product Security
Q1: Could you introduce yourself and give us an overview of your background in cybersecurity and product security?
- I have been in the CyberSecurity space for more than 13 years now. I was a developer for the first 6 months of my career. My pivot to security happened when I got introduced to the null community(India’s largest open security community) by a friend. In the first meet up, I knew that my career had found a new home. The amazing folks I met in the community helped me create a learning path for myself and successfully pivot my career to a security professional within a year. My first stint was with Paypal’s AppSec team where I learnt new ways to find security vulnerabilities, help bring down phishing pages, test critical encryptions, validate incoming bug bounty issues and write code to automatically detect vulnerabilities like CSRF. I wrote my first research paper on SSRF Scanner in PayPal and presented it in an international conference which later became an OWASP project(OWASP Skanda) as well.
I spent a brief 1.5 years in PwC doing pentesting for clients in the beverage and payments industry. In that time, RFIDs and their weak security caught my attention which led me to build my own code which could use cost effective hardware and clone RFID cards with a $20 setup.
Post PwC, I joined Sprinklr Inc. where I was their first security engineer. I spent 6 years there and did a journey from the first security engineer to the Director of Product Security. During this time, I built the team and took care of global security needs of the organization. In the same tenure, the company did the journey from raising funds to successfully doing a $3.7 billion IPO. In this time, I went through the whole 9 yards of Product Security like chartering to client’s security needs, mature the security process across the org, building robust defenses, bypassing firewalls and anti-viruses, implementing cloud security controls, SAST/SCA and DAST needs to name a few. In the process, the company achieved PCI and FedRAMP ready compliance as well. My time in Sprinklr also gave birth to Cloud Security Suite(open source) which has had the capability to scan cloud misconfigurations since 2017. It was actively developed till 2020 and has been presented across various international conferences like Blackhat(USA, EU, Asia), DEF CON, OWASP Global, nullcon, etc. During this time, in 2019, I started a Cloud Security Community in DEF CON called Cloud Village where folks could actively create a learning environment by gamifying it and latest Cloud Security specific research could be presented.
Post Sprinklr, I went on a corporate break and founded Cloudurance Security, a boutique company that provides bespoke security trainings to companies wanting to train/upskill their engineers in security. These training courses were delivered in conferences like Blackhat(USA,Asia), nullcon, AppSec NZ. The company continues to provide hands-on training to various companies including the financial sector.
In 2023, I joined CoinSwitch as their CISO. CoinSwitch started as a crypto trading company and a Crypto Exchange with 20 million users. In late 2023, the company also branched out in the FinTech space with a stock brokerage app. Product Security is something I have done throughout my career but my time in CoinSwitch has helped look at compliance in a new light. I am happy to say that as of 2024, the company is ISO 27001 compliant too.
Q2: What does “product security” mean in the context of cybersecurity, and why is it becoming increasingly important in today’s digital ecosystem?
- Security in a nutshell is “Abuse of Functionality”. As long as there is a certain functionality, hackers will have an opportunity to abuse it. A Product of any kind provides a set of functionalities which solves a problem for a certain market and that’s the reason it essentially sells. So basically, the number of functionalities in any product is directly proportional to potential abuses the product may have.
In the current digital ecosystem, the pace at which functionalities/features are built, it would be a recipe for disaster if the company doesn’t have plans for handling their product’s security. Business heads, Product Managers and developers have their roadmaps and timelines and they will always build the product on that front. They are not the Subject Matter Experts of securing the product hence a plan with dedicated resources to handle product’s security keeps hackers at bay and your users safe.
Section 2: Challenges in Product Security
Q3: What are the most significant challenges companies face when trying to secure their products, especially in industries such as IoT, automotive, and healthcare?
- I believe that the most important challenge is not having security from the get-go. Unfortunately, many new companies overlook security until they grow to a certain size. By then, the product has grown to a certain size and has quite a few attack vectors in it. Security engineers/consultants are hired with the thought that they can clean up issues. While they can find security issues and provide guidance on fixing, the fixes are still to be done by developers. As there has been no security culture until now in these types of orgs, these issues end up sitting in the backlogs and don’t get worked.
The biggest challenge Product Security faces is building a security culture in the organization. If security issues are not given the required attention, they are a ticking time bomb waiting to explode. We have seen many organizations shut shop because they couldn’t recover from a security breach.
With the IoT, automotive and Healthcare world it’s a further concerning problem. It’s easier to update softwares with OTA updates but with hardware it’s a bigger logistical challenge. A very few percentage of them can be updated over the internet, in most of the IoT and automotive cases, it requires recalling the devices and updating them at the service centers. And with healthcare, you can’t really replace an implant. If a pacemaker is vulnerable to wireless attacks, you can’t really bring it to the service center and update it.
Rigorous security testing and architectural foresight should be exercised while exposing these devices to new technologies(aka functionalities).
Q4: How do emerging threats, such as supply chain attacks, impact product security, and what measures can organizations take to mitigate these risks?
- Lately, Supply chain attacks have been quite prevalent. While the third party tools/services risk was always present, some major breaches in recent times have made the world pay serious attention to them. Every organization should dedicate time to know their attack surface which includes their vendors(tools and services). The existing vendors should be assessed by the Risk team by categorizing them depending on the criticality of data they have been accessing. The categorisation will help in dedicating resources towards doing an audit on these vendors. For example, if a tool is doing analytics of how many clicks happen on a product, you can go easy on it. On the other hand, if a tool is accessing code or customer’s PII, a more rigorous security testing should be performed as this tool becomes a critical asset of your organization.
Also, all new vendors should go through this assessment as part of the onboarding process and all existing tool should be reviewed with these guiding principles at least once a year.
Section 3: Designing Secure Products
Q5: What role does “Secure by Design” play in the development of a product? Could you provide examples of how this approach can prevent vulnerabilities?
- Secure by Design takes care of two crucial pillars: One, it makes the product secure from the get go. Second, it saves those precious developer hours which will get wasted when a security issue gets reported later and they have to fix it while keeping the code optimally functional. In my experience, this is what dev teams dislike the most.
Security is a multilayered concept. If the security journey of any product is starting at the design phase and a regular feedback loop is there in place in every step of the way, the product goes through multiple security lenses all the way till it’s deployed in production. With this process, bad security designs are caught, secure coding practices are enabled, pentesting becomes the part of the cycle and security gets integrated in CI/CD pipelines as well.
Q6: How should organizations integrate security into their Software Development Life Cycle (SDLC), and what frameworks or methodologies would you recommend for this?
- Secure SDLC is not complicated if the engineering culture is aligned towards making the product secure. It can be achieved in the following steps:
- Identify the current security posture of your Product
- Onboard SAST and SCA scanner to know how secure your code is written.
- Run DAST Scanners to identify low hanging security issues
- Get Penetration Testing done by hiring a good pentesting firm.
- If not already present, hire good security engineers. The numbers depends on the organization’s size.
- Validate the reported issues and weed out the false positives.
- Get bandwidth allocation from the engineering stakeholders for the issues found.
- Once that bandwidth is in place, get buy-ins from the stakeholders about making security as an integral part of the SDLC so that the org doesn’t land in the same place again.
- Have security checkpoints from the point a new PRD(Product Requirement Document) is received. Get threat modeling done.
- Get SAST and SCA scanning done for the new code being shipped and get those issues fixed by Devs.
- Make sure your infrastructure is also scanned and tested
- Do a mandatory round of pentesting of all the new features before they are deployment ready.
Section 4: Product Security Strategies and Best Practices
Q7: What are the best practices for conducting a comprehensive security assessment of a product, both before and after its release?
- The before release part, do everything which is mentioned from the point where a new PRD is formed. For the after release part, make sure that there is a round of testing on the production system as that’s where the real hackers will attack. The crucial part here is to encourage the PenTesters to go as deep as they can and if they are going to try something nasty like delete a table/file, they should get their manager’s approval before they do so. We don’t want the system to come down without warning but no stone should be left unturned to exploit any vulnerable scenario.
Q8: Could you elaborate on the importance of threat modeling in product security and how it can be effectively implemented within development teams?
- Threat modeling helps in identifying security issues very early in the development cycle. More importantly, they help save a lot of developer bandwidth as fixing security issues while the product is being developed is easier as compared to when the product is finished and ready to roll out.
To implement it effectively, you need to gauge the number of products/features being built and hire the correct number of engineers to support the bandwidth of making every new feature go through the threat modeling exercise. Enrolment of development leadership into this exercise is very crucial for its success.
Section 5: Security Testing and Continuous Monitoring
Q9: How crucial is security testing, such as penetration testing and vulnerability scanning, in ensuring the security of a product? How often should these tests be conducted?
- Penetration Testing is very crucial as that happens when the whole feature is ready. A lot of time, multiple teams collaborate on a product or a feature. While these various teams will be writing code separately and all of it will go through various stages like threat modeling, SAST/SCA scans; the final product has all the pieces integrated well and working properly.
The final product shall always go through pentesting as that’s where all functionalities including the code written across the team has to work together and that has a tendency to give birth to new vulnerabilities which might have escaped the previous checkpoints.
Q10: What role does continuous monitoring play in maintaining product security, especially after a product has been deployed?
- Continuous monitoring from a security standpoint helps you understand the different types of attack which are encountered by your product. It can happen both on the application level as well as the infrastructure level. Monitoring helps you proactively gauge into your product’s defenses and enhance them whenever the need presents itself.
Section 6: Compliance and Regulatory Requirements
Q11: How do regulatory requirements like GDPR, HIPAA, and NIST affect product security practices?
What are the critical steps to ensure compliance?
- Yes, they definitely have an impact on the product security practices. If security is not part of SLDC then it’s a bigger nightmare to implement.
Many of these regulations are in place to safeguard customer’s data. If the security team doesn’t know the data is flowing across the product then securing the leakage of that data to unwanted entities is quite a task.
Organizations should always have a dedicated compliance team or a third party compliance partner which can educate the engineering team on how to ingest and process data. Regular audit shall also be conducted by this compliance team to keep a check on development practices from the compliance front.
Q12: What are the key considerations for organizations when developing products that must comply with multiple regional and international security regulations?
- Most of the compliances want the organizations to be responsible with the data security of the consumers. It’s important to understand the product your organization owns and the kind of data it ingests. Depending on the industry you belong to, it’s crucial to know what are the different compliances your org has to adhere to.
Once this understanding is gained, movement of data and security in that perimeter should be defined and acted upon. It’s very important to get specific compliance based audits done periodically as any non-conformities to these compliance can lead to business loss.
Section 7: Incident Response and Security Patching
Q13: What are the best practices for setting up an incident response plan specifically for product security issues?
- Having a Security Operations Center(SOC) in place is very important. This involves setting up a SIEM in place. This can be done by going the traditional route and setting up an incident response-house incident response team with an industry leading log aggregation tool with correlation rules.
All important product logs like application logs, firewall logs, infrastructure logs, etc. should be piped into this tool and periodic exercises to improve the correlation rules should be completed.
An org can also hire a managed SOC vendor who come in and understand your product and set up right log ingestions in their SIEM tools and monitor it 24/7/365.
Q14: How should organizations handle security patch management for their products, especially when dealing with a large and diverse user base?
- It’s always important to categorize the user base into various categories. Critical patches should be tested well and should be rolled out starting from the general user base to critical users while ensuring no downtime.
The testing of these patches shall be done in all environments so that there is always high availability maintained at all time. If not done well, security patches can sometimes lead to downtime which is never good for the business and reputation of the organization.
Section 8: The Future of Product Security
Q15: With the rise of AI, ML, and quantum computing, how do you see product security evolving in the next five to ten years?
- Future is going to be very interesting. Quantum computing will definitely make cracking encryptions and passwords easier so more robust mechanisms will have to be invented as the world evolves.
In regards to AI and ML, the machines will be more capable to find security issues if the right context is provided to them. As this areas grows, we might be looking at the world where machines would be able to fix vulnerable code on their own which then would give rise to more sophisticated attacks primarily on the lines of bypassing the AI/ML algorithms.
Q16: What advice would you give to organizations and security professionals looking to stay ahead in the field of product security?
- Security is always a continuous “Cat and Mouse” game where the race is to stay on top of the attackers. If your defenses are not built well there will always be a creative hacker who would get into your systems. Having continuous security in place, hiring the right talent and creating multiple layers of security at every juncture of a product journey will always be a good approach. The technology will always evolve but the foundational principles of understanding the functionality and finding ingenious ways of abusing it will always be the core of hacking. Product Security will always be about how far ahead you are in this game.
Conclusion:
Q17: To wrap up, what final recommendations would you make to companies that are just beginning to build their product security frameworks?
- Building a security first culture should always be the focus. While Product Security might seem like a technology problem, it’s primarily a people problem. Getting the right stakeholders in a room and making them understand the importance of dedicating bandwidth to security across different functions can set your organization for a much secure future.
Closing Notes:
Securing a product is a dynamic and complex process that requires a comprehensive approach involving design, development, compliance, monitoring, and continuous improvement. Organizations must integrate security at every step of the product lifecycle to ensure robust protection against emerging threats. Thank you for taking the time to share your expertise with our readers. Your insights will greatly contribute to the understanding and advancement of “Building Trust in the Digital Age: Strategies and Best Practices for Robust Product Security”.