How We Improved Information Security at Grofers

 2 years ago
source link: https://lambda.grofers.com/how-we-improved-information-security-at-grofers-292521f53a0f
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

How We Improved Information Security at Grofers

We, at Grofers always keep security first. We believe that information security is as important as any other part of an enterprise and should be considered the utmost priority. So to strengthen the same, we began by having a structured plan to make our infrastructure and applications more secure.
The challenge every startup or even a scaled company faces is to cultivate an InfoSec culture. To facilitate this, we began with a Security Awareness Program. This was a great way to educate personnel and to keep the company’s IT security policy fresh in their minds.It also makes them understand the risks and threats to the ever-evolving cyber world and thus help them to adequately protect the organization against security risks.

To drive the changes we wanted, we started the following initiatives:

Security Awareness Program

We conduct regular security workshops demonstrating the recent hacks, their impacts, mitigation ways and best security practices that need to be followed. Live demos and fixes are shown to keep the team more engaged.

Feedback forms are sent to find out where to improve, what’s missing and steps that could be taken to improve engagement.

To keep the employees aware of what’s currently happening in the InfoSec world, weekly security awareness mailers, newsletters, security updates and infographic emails are sent.

Integration of Security Testing in SDLC

We needed a continuous application scanning tool for which we evaluated several solutions like OWASP ZAP, BurpSuite, Arachni and a few more. We settled on Burp Suite Professional Tool for the same. In order to integrate it with SDLC, we set it up as a proxy server which Developers/QA engineers have to use while doing their usual sanity or QA tests. They need to just plug in the proxy scanner IP on their local machines and that’s it! Mobile applications have the proxy integrated into the build itself.

And in this way, the proxy scanner server will perform automated security scanning and report the vulnerabilities in the testing phase. While this goes for automated scanning, we give the same focus to manual security testing which is carried out weekly when our releases are going through regression testing.

Having a security testing during the QA phase will not only reduce the vulnerable sphere at the initial phase itself but also reduce the time/efforts spent later. We are expecting to find 70% vulnerabilities using this approach for any particular release.

Continuous Application Security

Application security testing should be a regular process instead of being a one time task. To make this a continuous process, we have scheduled regular application scanning of our domains and subdomains based on the application nature. For example, a B2C application is scanned monthly while an internal application goes through automated scanning quarterly.

Apart from the usual application vulnerabilities, we have in-house developed scripts which run weekly to check for common loopholes/mistakes (manual errors) like S3 bucket containing sensitive data made public, Git repo left with public access, unused CNAME to prevent subdomain takeover, sensitive ports left open on machines.

Automation in Web Application Firewall (WAF)
To protect our application from web application attacks, DDoS and bots, we brought in WAF in our environment. After some testing on our staging environment, monitoring it for anomalies and false positives, whitelisting, and setting up required rules etc, we rolled it out to production. The important thing for us to take care of was to minimize the false positives so that the firewall don’t block an actual user based on it’s blocking rules. We tried doing this by having a manual review for each IP blocked by WAF, which were extracted from the HTTP logs and checking the IP reputation.

This worked but to keep doing it manually would be very time consuming. To address this, we developed scripts which do the following in an automated manner —

  1. IP reputation review (gathering data from DNSBL Information)
  2. Whether any user account exist from the IP in grofers app

and some more factors.

Image for post
Image for post
IP Scoring Check

Based on these, we generate a score which can be used for differentiating between an attacker incident and normal user and whether or not we should block the IP/user. Implementing WAF proved to be of great impact to us as we saw a significant decrease in web application attacks, scraping and bots.

What next?

As we scale up our platform, bringing more and more technologies into system, the chances of having a security loophole become more and more real and hence the challenges to keep our infrastructure secure. Since security is a continuous process, we continue working towards strengthening the security of our infrastructure and apps through tools and processes. Keep following us to know more about them. Stay tuned!

About Joyk

Aggregate valuable and interesting links.
Joyk means Joy of geeK