Transcript:
I’m Daniel Carrion. I’m CTPO At Inspide, which basically means that I try to make sure that the product and the technology departments are aligned and work together to achieve the company goals. Inspide is a small Spanish company. We have been working for a number of years on connected car and road safety by means of connecting the different elements on the road. A couple of years ago, we started using telco data in our projects and suddenly we realized that telco data could also be used to disrupt other market so now we are also focused on out of home advertising and specifically on audience measuring and segmentation.
At Inspide, we try to keep a very consistent technologies tech, which means that we use only a handful of languages. We basically do HTML and JavaScript, specifically React on our front end and Python on our backend. We also use Spark for data engineering and also Python Notebooks for data science. And that’s pretty much it. We use AWS for our infrastructure. We try to use their services as much as we can, and specifically we use EKS for Kubernetes, which we use a lot. All of our applications are deployed in Kubernetes. And we also use EMR for Spark. We have a development cycle that lasts for five weeks. So we spend the first four weeks active developing the features that we have agreed upon for this particular cycle, and then we spent the last week doing the final QA and deployment to production.
Prior to Deefactor, we only ran some API penetration tests manually, mainly using Postman or directly in Python. We already had a very secure environment because, as soon as we started to work with telco data, we really had to upgrade all of our security infrastructure and procedures. But we were lacking a tool that would help us from the developer perspective. We had invested a lot on security from the point of view of the network or the site reliability engineers, but never from the software developer’s perspective. Before Deepfactor, searching for vulnerability in our application was something that was done manually by each developer and it heavily depended on how strict those developers were at that moment in time. A, it was manual, and, B, it was inconsistent across all of our applications or services because it heavily depended on this individual developer.
Again, before Deepfactor, developers would come across vulnerabilities, but probably they weren’t really proactively looking for them. To me, that’s the key improvement that we’ve seen after we started using Deepfactor. Developers, they want to write code, they want to do creative things, and looking for vulnerabilities just put too much friction on them to make it a task worth investing time on. And that has changed now with Deepfactor because they don’t have to look for the vulnerabilities, the vulnerabilities are clearly shown there, and they can focus on fixing them. Fixing is something that works for developers. Developers are happy with fixing things, but you have to make it easy for them. So one of the great things about Deepfactor is that as soon as someone uploads a Docker image to the repository, on our Slack channel they get all the alerts regarding the vulnerabilities that Deepfactor has found.
That’s just one step, but it’s a very big step for them because they can very easily see what’s wrong with their image and fix it even before going beyond the deploying process. And still, if they want to finally deploy, there is one final check that will make sure that they have at least addressed or assessed the different vulnerabilities. And if there is one that’s still there it is because they have consciously decided that specific vulnerability doesn’t apply for whatever reason. But there is a reason behind the fact that vulnerability is there so we make sure that everything is under control. Whether fixed or not, everything remains under control. We’ve deployed Deepfactor in a couple of different stages. First, we deployed a proof of concept so that we could make sure that Deepfactor was the kind of tool that we were expecting to have.
That was really straightforward because we deployed Deepfactor in our own Kubernetes cluster. But then when we decided that we wanted to move on and really have Deepfactor working for us in production, then things changed a little bit because of the strict security requirements that we had. That meant that we had to move Deepfactor out of the cluster and into its own machine in AWS and all the connections between that machine and the Kubernetes cluster, they were a bit challenging at times, but we ended up deploying everything. And after that, upgrading and everything has been really a seamless process, just the click of a button and that’s it. In terms of capabilities of Deepfactor for me, random analysis is the winner. It’s the clear winner. I think for us it has significantly improved the way we look at how our deployments perform and it has made us look into parts of the deployment that we had never looked at before in terms of security, specifically files that somehow changed permissions or got deleted, that kind of thing.
We had never had that type of thing in mind before. Security for us ended as soon as we deployed the image. As long as the image was good, all the security tests had passed, all the application tests had passed, that was good enough for us. We only looked at the run time in terms of performance analysis, but never in terms of security analysis, and that has changed. We’re a small company and so far we haven’t really had to certificate ourselves in security or get any type of security certification, but we know that eventually we will have to, and it’s not really embedded in our culture to understand how all the certifications work, all the different certifications that we have, and how all these vulnerabilities are classified. And suddenly we have a tool that basically sheds a lot of light on top of all that and suddenly we are comfortable talking about SOC-2 and OWASP.
Well, probably that one we knew about before, but it’s like it’s suddenly opened up a new world for us. It’s a new world that we know we have to get into, but suddenly we are in a much better position to do that. It’s great that Deepfactor provides our developers with a lot of context whenever vulnerability is found. But also, to be honest, so far we haven’t really found critical vulnerabilities or vulnerabilities that were extremely hard to fix. So once we knew we had a problem, so far the resolution has been pretty straightforward, which speaks well of our developers. But still, in general, you really benefit from understanding the context and getting at least a few hint or where to look in order to fix the vulnerability.
So with Deepfactor, I think the type of vulnerabilities that we’ve suddenly become aware of is the runtime ones. For instance, you could assess whether a process was going to be running smooth or not by just taking a look at your Docker file, but we would never, really, or at least not automatically confirm that, that was actually so, and the process wasn’t running as smooth and we didn’t have any other process running as smooth. So in order to track and triage vulnerabilities in Deepfactor, we used internal workflow that is attached to alerts. For us, that’s pretty much what we need, at least for now, because with that tool we can basically understand whether someone is looking at the vulnerability that has been found and if they’re working on it at some point we will know if they have confirmed the vulnerability or if they decided to ignore it for whatever reason, and the reason must be really clearly stated on the alert.
For now, that’s enough for us. Eventually, we might want to integrate Deepfactor with some of the other tools that we use, but for now it’s enough. Working with priorities in Deepfactor is really easy in general, just like the alert workflow is something that we use on a regular basis. So, at Inspide, we take security very seriously, but it’s true that, depending on the team, it’s easier or harder to make developers and engineers in general buy into improving their attitude towards security. We have a very paranoid SRE team. We don’t need them to buy into anything regarding security because they are already there. But, with software developers, it’s a bit different. Security generates friction on their daily job maybe because they need, I don’t know, to enter an MFA code every hour and that’s really annoying. I mean, it’s always a new hurdle for them whenever a new security process is put in place.
And suddenly, with Deepfactor, they have a way for them to improve how they deal with security that doesn’t generate a lot of friction. And, suddenly, security has become a first class citizen to them as compared with security being a first class citizen only for the paranoid SRE team. And that is even more so significant with junior engineers, because senior engineers, they already understand that security is a must and at some point it will generate friction on their daily work, but that’s okay. But junior engineers may not necessarily be so much aware of all of that. And I would say that’s where we’ve really seen an improvement after we started using DeepFactor.