As much as we take pride in our elegant design and stunning UI, we share the same if not more delight and dignity when it comes to the security of our app. CRED has always been on top of its security, our main motive has always been and will always be to provide users a beautiful and secure experience over our app. Security has become one of the pillars of CRED workflow from the beginning of its journey which directly comes from the top of the CRED leadership
As it is said “Security is a mindset, not a series of courses or a test you passed” and this mindset is pushed by the CRED management. The main ingredient of the CRED success is that its security is pushed from the top itself to hence create a proactive mindset where for us “Security is not an afterthought”.
Initially, for security at CRED, the journey has been thrilling yet challenging. Challenging because of the speed of development that is empowering its fast paced growth, the high number of releases being made, a large number of features rolled out to production. To cater to the CRED’s agile culture and speed, we need a security solution that can scale up to the pace of development for each and every release where we want everything which goes to our customer via our app to be end-to-end secure. If you have read our previous blog, one of the quotes says “Security is a facilitator, not a blocker” that hinders development, brings down developer productivity, and creates friction and that is what we wanted to be for our developers, customers, and everyone – A facilitator and not a blocker. We were aware that classic AppSec methodologies and processes won’t be able to scale to the securer ecosystem that we want hence the need for a modern AppSec platform that’s not only scalable but also reliable has been a big challenge for us.
We began with introducing security at every step of our Software development Lifecycle (SDLC) starting from the first step of designing to the last step of deployment. It not only gives a much better opportunity to see improved security outcomes in products sooner, but also saves time, effort, and overall cost of product delivery. We break down into the following stages (but not just the following) :
Each and every feature which is being discussed and laid down on specification and documentation first has to go through a security walkthrough where the security team understands what is being built, what tech stacks and frameworks are involved. It gives the security team ample time to think and suggest any tech or infra specific changes to be made at the initial step itself.
Product Design Review
This stage takes the utmost importance and without the security team involved during reviewing of product designing, the discussion never starts which shows how seriously and proactively the security team is taken into consideration. During this stage, the security team reviews the architecture and design of the new or revised feature or any enhancement planned to go live. With this, the Security team gets better visibility on the product and recommends security practices. The early call out of any security specific issue helps the product team to revamp it during the design phase itself and helps the developers from working multiple times.
We do effective Threat Modelling of every new product getting launched or any major changes planned to get released. Unless you fully understand the threats and vulnerabilities, you can’t be sure of what changes a particular change will bring. Threat Modelling helps us assess risk and the potential consequences of security threats to systems and ensure that the necessary protections are in place and are able to address evolving threats across platforms. Thus reducing Attack Surface. It also helps prioritize threats and mitigation efforts. Documentation of threat modeling is also important to note here.
Regular penetration testing is the heart of our application security process. As much as we focus on deploying tools to carry out effective penetration testing, we also give the same amount of importance to manual penetration testing where for any change going live, our dedicated team makes sure to leave no stone unturned. Both automated and manual penetration testing is done here. We also have a world class dedicated vendor who regularly picks up apps for comprehensive penetration testing, performing automated as well as manual penetration testing to find logical flaws and security issues in our app logic.
Continuous vulnerability scanning
“Security is not a one-off exercise” – To make sure we are continuously secure, we have to be very rigorous around the employment of a continuous vulnerability scanning and management program so that the vulnerabilities are detected in real time and remediated as soon as possible thereafter. We have deployed multiple tools and processes at multiple stages to make sure we are continuously scanning our application for threats and vulnerabilities. Finding a bug is only a job half done until it is fixed. We take remediation and mitigation strategies seriously to make sure whatever gets discovered is fixed also within the permissible timeline adhering to our patch management policy. Every bug which is discovered in our application is filed in our bug tracking system with appropriate labels and auto alerts for effective tracking and over a period of time, helps us collect a statistical view of how efficient our application security and remediation process is.
The entire APK scan for the release is done by the framework Adhrit and the final sign-off is given. It is our in-house tool that was also presented in Blackhat Asia, 2019, and adds to the feather of CRED security proud moments. It is an Android APK reversing and analysis suite. The tool is an effort to find an efficient solution to all the needs of mobile security testing and automation. Adhrit currently uses the Ghera benchmarks to identify vulnerability patterns in Android applications. It performs static analysis on any iOS or Android application in search of security vulnerabilities. It automatically identifies all changes to the APK from the last time and performs automated scanning. It also has integration with our bug tracking system to automatically file bugs with appropriate comments to track each and every security vulnerability to closure. This has a huge impact on the overall TAT and effectively helped in reducing the time taken for a security review by ~50%.
Another in-house tool that we have developed – Patronus which performs source code scanning. It effectively integrates with our bug tracking workflow. The moment we create a bug ticket in a specific security project, Patronus listens to it and fetches the code repository URL. It then performs the source code scanning and also attaches the report in the same bug ticket. So by the time someone from the security team comes to pick up the items, automated scans are already completed and reported. Patronus has already proven a highly efficient tool for us bringing about the reduction in overall TAT by 60%.
Automation – The key to Faster Review
The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency ~ Bill Gates
Our main motive throughout our application security process to make it effective and efficient. If there is a one-off exercise, we do it but if that exercise needs to be carried out again, we try to automate it. The same applies to our application security. We automate major time-consuming and repetitive tasks and make sure that they run smoothly without the need for human assistance. Thus freeing up a lot of their time to deal with real potential alerts and threats in a faster, more effective manner.
CRED Vulnerability Responsible Disclosure program
We always believe that talent and skill are variable and present in abundance in the world. There are people who are consistently trying to find security issues in various applications and websites and to create a platform for them to help us grow securely (because there is always a chance where something can slip past developers and a security team), we launched our “Vulnerability Responsible Disclosure” program to have crowdsourced security testing and create a culture of openness, transparency, and responsibility. It also keeps us proactive and predictive at every point in time. We welcome any opportunity to work with security researchers that practice responsible disclosure. The CRED Vulnerability Responsible Disclosure Program is an invitation to the world to participate in making CRED and the internet a safer place. With this program, we encourage security researchers, ethical hackers, and bug bounty hunters to submit vulnerabilities to us for a responsible coordinated disclosure.
These are just the first and foremost steps that we have taken to create a secure ecosystem that will facilitate building the application’s security pipelines. As we scale and bring in new team members and technologies into the system, we will have to strengthen our practices to ensure they hold up to the demands. Since security is a continuous process, we continue working towards strengthening the security of our infrastructure and apps through tools and processes. In the following weeks, we intend to capture our internal processes in more depth. Give us a follow to get to know more about them.
Huge Shoutout to Anirudh Anand for leading Application Security and we would also like to appreciate Akhil Mahendra, Abhishek JM, and Abhishek Jaiswal for their inputs throughout.
- The Cosmos of CRED Application Security - March 18, 2021
- The Peanut, Butter, and Jelly in Cloud Security - December 2, 2020
- How to build a security-first culture: lessons from CRED - October 9, 2020