- Select Tickets
- Payment
- invoice
- Attendee details
Total ₹0
Cancellation and refund policy
Memberships can be cancelled within 1 hour of purchase
Workshop tickets can be cancelled or transferred upto 24 hours prior to the workshop.
For further queries, please write to us at support@hasgeek.com or call us at +91 7676 33 2020.HD
Himanshu Kumar Das
@himanshudas
Implementing security from day 1 at a fintech startup
Submitted Jun 6, 2019
Section:
Full talk
Technical level:
Intermediate
Session type:
Lecture
In this presentation we want to showcase how we simplified, prioritized and implemented security from day 1 to a product idea going to production at CRED.
Outline
Information security domain has become vast with lots of industry standards, frameworks, tools, etc. However, all business at the end of the day cares about is releasing a product securely with minimal friction and enabling tech to move fast while having security in place.
In this talk, we will touch base on the approaches as well as key decisions we took to ensure we have security in place from day 1 of our product launch. To keep understanding simple, I have segmented security into 3 following buckets
-
A cloud approach
-
A compliance approach
-
A product approach
A cloud approach: Most of our founding team members were well versed with a public cloud (AWS), hence, this was a no brainer decision to adapt an AWS heavy infrastructure.
Challenges(Security):
-
Due diligence of shared responsibility: All managed workloads would need to have a policy defined. E.g. An IAM role must not have an excess permissions or an admin user should not be able to delete a running ECS cluster.
-
Lifecycle of workloads/resources: E.g. Security groups for enabling temporary access across AWS resource needs to be revoked asap.
-
Secret/Key Management: E.g, Because secrets are not meant to be hardcoded.
-
Incident Response: E.g. Bitcion miner on a hacked EC2.
Approach:
-
Least Principle - OKTA as SSO on separate AWS accounts(dev,stage,prod,PCI, central) with distinguished user groups.
-
Continuous AWS Monitoring - https://www.cloudconformity.com/conformity-rules/
-
AWS Guardduty - Monitors Cloudtrail, VPC Flow logs and Route53 logs - SNS to Email for all alerts.
A Compliance Approach: Fintech is regulated business and industry standards are its consequence. During the first month of our product launch, we were required to become compliant to NPCI guidelines for a UPI launch. Followed by RBI’s data localization requirement(SAR) and then ISO 27001:2013
Challenges:
-
Onboarding independent auditors to the concept of credit card bill payments.
-
Onboarding consultants to view product/business from a different angle.
-
Creating a process oriented culture to adhere to various compliance requirements.
A Product Approach: Our founder wanted our product to be as secure before we launch.
Challenges:
-
Dealing with rapid code+design changes.
-
Defensive versus offensive.
-
Proposing secure solutions for end user application flow.
Approach:
-
Keeping track of changes in every alpha build. Sit next to developer and start with a simple code review. Need not be a tool based approach, for every API call, check the corresponding codebase and think what could go wrong.
-
Too many tools and framework to attack. Think on how to make every attack difficult. E.g. SSL Pinning, Code obfuscation( Proguard followed by Dexguard)
-
Review all application flow, look at application having user inputs. E.g. OTP flow in our app.
Speaker bio
Himanshu is currently repsponsible for overall security at CRED. He has spend most of his career into fintech domain at GrabPay, Flipkart, PayPal in building in-house security platforms and products, hence, his domain expertise. Having started his early career with security consulting for some of the well-known passport-visa processing firm, government organizations, start-ups in Indian e-commerce space. Himanshu has later lead bug bounty programme for PayPal. He participates in CTF with team SegFault, has won Nullcon JailBreak 2012 and been an architect for managing and hosting HackIM CTF. While away from computer, he spends his time playing console and enjoys cooking.
Login to leave a comment
Zainab Bawa
@zainabbawa Editor & Promoter
Thanks for the submission, Himanshu.
Here is the consolidated feedback from review:
Talking technicalities of security is not of value if business choice and design defeats this. For example, UPI payment exposes valuable data to third parties by design. What is the level of awareness of CRED's customer base of this design choice and it's impact on security? This tightly couples with privacy, but relevant in context of security as well.
What are the data sharing and protection of PII? Since Cred's business model depends on leads, how do third parties utilise their customer's data?
Pure play DevOps style security talk fits cloud security, developer practices etc works for enterprise data, not for consumer data. Since "Information security" is mentioned here, the product's approach has to be explained.
Data security is complicated for CRED when it comes to data and when business depends so much on data. Therefore, security is/has to be tied in with the business/product's approach. Third parties having access to that data defeats the business. Hence UPI integration is questionable purely from business perspective. Did CRED have real choice to skip UPI?
Devops becomes liable as much of this is likely to be automated via shared APIs or regular data dumps.
This has to be addressed in the proposal, especially point number 3.
Srikanth Lakshmanan
@logic
I would like to add some comments from the perspective of 'offline' OpSec that goes into the Engineering, product design and practices that you follow to ensure information security is complete, because security is not just a function of Cloud, Compliance and Engineering processes, but also product / business design.
On product design perspective, does the user know what information is shared from CRED to various third parties(Explicitly naming the entities) during the course of payment, something that could help users know how much data is going to whom - during the course of using CRED. Bonus points would be indicators of security (infrastructure + ops + ideological) of those 3rd parties. I say ideological because, we live in a country where culture of denial when it comes to incident response is being made norm and definition of what constitutes data breach / security breach is heavily polarized. I am sure from a product / technical design perspective CRED would have done due deligence before integrating 3rd parties, but not making the user involved / adequately aware compromises information security. Because IS is not just function of Cloud, Compliance and Engineering processes; but also extends outside of it.
On the business front, how do business choose vendors and what role information security factors during that would be interesting to hear. To give an arbitrary example, how do you ensure your logistics provider doesn't end up with CRED user database and sells it to your rival?