 Thank you from everyone for coming. My name is Miguel Reguero, this is Rodrigo Núñez. We work for BBBA, the number one financial entity in Mexico, number two in Spain. We have over 65 million customers in 35 different countries, but more specifically we work for IFRS, it's the company that creates cyber security products for BBBA. You should have seen our booth, it's right outside this room, but if you haven't come talk to us, maybe if you're looking for a job, maybe we'll have it, so come chat us up. Okay, before we start, let's talk a little bit about us. We are a pretty big company, and actually on top of having around five data centers around the world, we have entire parts of a bank living in the cloud, in different cloud providers, with different accounts, and making all that stuff secure can be a pain in the ass. We are not hackers. Cyber security is not about hacking, exploiting vulnerabilities, all that stuff. In fact, it's just a very small part of it, and all of these things is our work. Our job is to take care of everything else. The world is moving to a paradigm where continuous integration and continuous delivery is a must. In this new world, we as the security guys are falling behind. We are always slow, always stopping the development teams and such. We need new tools to make this security faster. We're not stopping everyone. Be there in every step of the development cycle. We create an application for that. This is Kimera. Kimera focuses on three different points in the development lifecycle. The first one is called Agile Security. It's a complete overview of your project during every step of the development. It provides an additional security pipeline for you to check every security need for your project, and then you can integrate it with your own pipelines. You have your continuous integration pipeline, and then in one point of that, you call Kimera, Kimera checks your code, sees everything is okay from a security point of view, and then says, okay, you can go, okay, this is bad, come back and fix it. For that thing, it uses patterns defined using BDD. From a functional point of view, we can check out of the box your code, see if everything is okay, and then go ahead. Also, it integrates an additional third party app to get a risk assessment from your project. You want to put your project into production, and then the application says, okay, for your application, you're going to need a web application firewall, a reverse proxy. You have to change this configuration or that configuration in one of your machines. Maybe you don't want to log in using root, insecure shell, et cetera. And then we have all that from that application. And then, okay, you have your project, you have the development, and you want to go to production. Then that's the second point of Kimera, which is called deploy provision and hardening. Deploy provision and hardening provides us with this risk assessment, we can check every step of every needed from a security point of view and do it for you. Okay, you need a web application firewall, okay, we'll deploy it, we'll provision, configure it for your project, link it, okay, you're good to go. You don't have to do anything. We do it for you. You have to change any configuration from your machines for your service. Okay, no problem. We connect them, we log in, we change it, we fix it. We harden every machine for your project, for you. You don't have to do anything. Using security policies defined from our company, we do it everything without having to change everything at hand or everything. Kimera do it for you. And then, okay, you have your project is secure. You can be 100% secure, but almost you have every piece needed. Okay, you are in production, but you may need additional security services on your production life. Maybe you need a new authentication, authorization, cryptography, et cetera, et cetera. Maybe additional security. That was the third point of Kimera, what we call cloud security foundation. Cloud and Kimera integrates additional security services for you with only one gateway. So you have to integrate only with Kimera. And Kimera provides every services needed for you. So you want authentication, you have it. You want a cryptography, you have it. Everything you need from a security point of view, additional to your project as an additional service, you have it with Cloud Security Foundation. Even if we change one of our application providers from the inside, okay, we found a new authentication application and it has better futures and it's better and all of that. We can change it from behind. And you don't have to change a line of code. Okay, it's transparent for you. Kimera does all their work for you and you have only to talk to Kimera and Kimera does all the work. So that's what we do to work with every step of the way on your development process. But what happens next after that? Okay, so with all this stuff about the cloud and continuous delivery, continuous integration, another situation arises where you might not know where your servers are and I mean not physically because they're in the cloud in this magical place where everything just works. But we mean virtually. You have to know exactly what do you have and where you have it, what's visible to the outside and what's not because if they're vulnerable, you might not know where to fix it. You might not know exactly what you have. So you have to keep a good inventory of all that stuff. Maybe you have a team of people whose purpose is to keep up with the news of vulnerabilities. Maybe they manually check all your servers. But that's boring and it's very inefficient. So we created another app. And the first issue we tackled with VATS was that as a bank we have many regulations imposing very strict restrictions to ensure that your data is safe. And the way we do this, VATS allows you to create security policies which helps you enforce them by snitching on all the servers that don't follow the norm. But if you follow the set of rules and policies that doesn't really mean that you're secure because maybe you're vulnerable. New vulnerabilities and other threats are being discovered all the time and that's not going to stop anytime soon. So you have to prioritize your work because not all vulnerabilities are as critical as others. Not all your servers that are vulnerable are open to outside and exploitable. And if you give a list of 500 vulnerabilities to your ops team they're going to say, what am I supposed to do with this? So that's when having a real time inventory of your servers comes in really handy. But keeping tabs on all your infrastructure is not really easy. Especially in our case if you have many different data centers maybe many different cloud providers. So one approach to solve this is having a department of people whose job is to make sure that everything goes to them. They're the one that creates machines. They're the one that updates their inventory. But that really stumps agility. It makes people not have the freedom they need. I want to create a server with. We have to wait a week because the ops teams have to create the machine. They have to secure it and such and such. So we created what we call an agent. It runs on every single machine that's deployed. It comes pre-installed. And it reports the server to keep track of all the machines that are alive and reports the different vulnerabilities and problems that might appear in the future. But you might be wondering, why are we telling you about all this stuff? What do you care about Kimera? What do you care about bats? So the thing is it's completely done with Python. We made both of them with Python. And here's a small list of the different technologies we use. We use a bit of Python 2.7. But we started a long time ago, but it's mostly Python 3.5 and Django and Tornado. Okay. Mainly, Kimera is done everything with Python 3.5 and Tornado and uses MongoDB and Therry. So as a data store and as a job scheduler, and bats is using Python 3.5 with some points in 2.7, mainly Django, some parts of Tornado, MariaDB, MongoDB, Therry, a lot of things. And also, we don't have only these technologies. Okay. We have a lot of them working only for those two applications. We can see PyOpenSSL, PyCrypto, PyWin332. Okay. We do our Windows services for this agent and as a real pain to work with Windows. So a lot of it, both of three, to connect with Amazon Web Services, RevitMQ, Redis, Sentry, LK, and MAP, OBSCAP, and CIVOL, a lot of it. And we are only this for two applications. We have a lot of more applications coming out, not only of Python, it's a lot of languages. So this is just a tip of everything we do it. So thank you everyone for coming in. And if you have any questions, we are here to talk. Hi. So thanks for your presentation. Can I go please one slide back? Yes. Okay. So what are you doing here? I mean, it seems like you are just collecting technology stack. Is there any reason you would use, for example, NanoMessenger with RevitMQ and so on? Oh, yeah. It's, I mean, here we're talking about both applications. Okay. It's not really the same. NanoMessage, we use it for internal communications. And Revit, we use it for docking with Celery. And so, yeah, it's just two different parts of the application. And NanoMessage was really the, it was much easier to use for the specific case than Revit. So that's pretty much it. Okay. Thanks. So I find one of the interesting challenges that you have when you have a really big stack yourself, and you seem to have it, especially in the light of you providing security-relevant application, is how do you make sure that what you're using is actually secure? Because the more dependencies you have, basically the amount of potential vulnerabilities explodes exponentially. Yes. So you're asking how do we make sure that... How do you keep up to date? Well, basically we... I don't know how to say it. We check all the time the vulnerabilities, and if some of our dependencies is vulnerable, we search for a different option, or we try to patch it ourselves. I don't know if that answers your question or... Yeah. Yeah. I don't know. Maybe I come from... Maybe my question has to do with my own frustration with how hard it is, because sure, you can go to every website, like check for news or security disclosures, maybe browse the CVEs, but the problem that I see in the Python ecosphere, there's not really a service that does it for you. I know from the Node.js world, there are actually these SaaS out there that basically scan your package requirements, and I tell you, okay, you've got a vulnerability right there, so you basically have people that dedicate all their time to staying up to date. So I was actually wondering whether you know any service like that. Well, actually that's what we do. So what we do is precisely check every new vulnerability that comes out. We are updated with the vulnerability services, and if a new vulnerability comes out, we know it because that's precisely what our application is made for. Yeah. Also, our own applications are used during our development. So we check every vulnerability using bots. We deploy our own application using Qmera, and on every step of our internal continuous integration process, we check the last version of every dependency, we check if any vulnerability is available for that, and then when everything is okay, it's implemented already in the new package or the new version of every application. So we have everything almost under control, because if we develop it from the bank, but also we use it internally. Hi. So I was wondering if, since you're focused on security, what good patterns are you using internally to make sure that there aren't some funny stuff going on, like do you have a policy where you have to always use context managers which handle various resources or how do you manage things like that, and how are you then reviewing code? I mean, if somebody has for some feature connected to, let's say, RabbitMQ or something like that, do you have some automatic procedure that checks that all the resources were closed and how do you manage memory leaks or resources leaks? I'm not really sure I understood you. Your question is if we have internal guiding styles and people who check our code in case we... Okay. So I imagine you have some internal guides. Yes. But my question is now how do you enforce them? Do you have like pull requests, code reviews? Yes, yes. We have pull requests, code reviews. Nothing goes into production or anything if it hasn't been checked by the people who development and the security team inside our company. Okay. But could you talk a bit more about good practices, especially related to Python? For example, I mentioned context managers. Okay. So I mean, good practices. Some of them are, I mean, use SSL. Context managers are a good idea, but not every... Not everything you use has context managers. So maybe you can do them for that. You can do them for yourself if you require it. I mean, just basically code properly. Do profiling of your application... I don't know. Answer your question. One simple question. What tools do you use for code reviewing the pools? For code review? Yes. Okay. Okay. For code reviewing, we have... In one side, we use GitHub as our mainly code repository. Then we have a complete branching system with pull requests, code review from more than two people. But also in the first point of Qimera and agile security, we have a complete stack for code reviewing. We call internally EGL. It's a piece composed with Jenkins, SonarCube, and also additional tools for making code review. So even if we pass from the pull request from GitHub, we also check it with Qimera internally using our own code review stack. You didn't mention directly any... The code reviews part. Yes. Yeah. First, there's a part that is automatically doing with pattern checks. But you can also do it manually with a person or a team of people. Actually internally we have... In the pull request, we check it with people manually. We also have automatically. And we also use technologies like Sonar and static checkers for code. I have the... It's not a question. It's an answer for his... There is a service that is called gemnastium.com that usually it takes a search for vulnerabilities on gems for Ruby projects. But it seems that now they also support Python projects. Thank you for your talk. I have a simple question. Does Qimera support our handles, incident response, and things like that? Excuse me. Does Qimera support incident response? Qimera mainly focuses just on... ...backup, but does not check for incident response at the time. Okay. Thank you. Any other questions? Now thank you guys for the presentation.