 Hi, this is your host of Limhartiya and welcome to a brand new episode of our series, TFI Topic of the Month, a.k.a. T3M. And today, we have with us, Yakub Bilhar, Chair of the Zoe Technical History and Committee. Yakub, it's great to have you on the show. Thank you very much. I'm glad to be here and I'm looking forward to your questions. The focus this month is on security and compliance. We talked about security last year at the Open Mainframe Summit. We had a lot of discussions around that. Last year, in general, security was a big topic. A lot of compromises happened there. So talk a bit about from Zoe's perspective or from your perspective, the industry, the ecosystem that you play in. What did you see from security's perspective? And then we can later on talk about what the project doing. But I want to hear what are the general trends that you are seeing in the context of security. First, one of the more important areas that are happening right now is that the company started taking care of the security. Like before the last year, nobody really came to us as a Zoe and asked, hey, how do you do this? Or, hey, are you secure? Hey, do you handle this software secure development chain in any way? So the major change that happened according to what I'm seeing is that the company started to take care about how the open source software is developed, whether it's developed securely and how they can themselves verify. And this has a few areas that are inherently part of it. First part of it is what practices do we as a Zoe do in order to make sure that the code that we produce is safe and we've been doing a lot already for the last three years. So we are a bit ahead of the curve there. I can talk a bit more on where exactly and how later. And the second part is how do you make sure that the pieces that are the building blocks that you use in producing the software is safe. So basically the secure software chain. And I would say that right now, what we are seeing more is the second part. So the companies are asking, what are your building blocks? How do you know that these building blocks are okay? Why are you certain that you in? Integrated these building blocks into the Zoe itself. And we have some answers for sure. Like to help them understand and audit our sayings we do produce as bombs for us. So if you want to know what's in Zoe in term of our dependencies and what versions and everything we do provide this information. We do scans ourselves before every release. Actually, we do it more often. I think we are doing it nightly right now. But at least on every release we are cleaning up either all the dependencies that are problematic or we are really going one by one for the ones that are remaining through an approval process for the Zoe security work group where there are like the security experts from all the spots within Zoe. And they are discussing whether first figuring out whether we are actually vulnerable because for lots of the vulnerabilities in our dependencies, we are not factually vulnerable. It's just that there is a potential if it was used in a certain way. And then based on this, we decide whether, okay, this is something we can accept and therefore accept that we will release with this problem or potential problem or we can't and then we either delay the release or basically we delay the release and fix the thing in such a situation. If you look at mainframe, that equals, I mean, very, very secure. But when we do look at all those modern workloads, we talk about clouded view, we are still trying to solve it all of problems that the mainframe community has solved decades ago. So when we look at this new community or when we look at these projects or that option, what are some of the security vulnerabilities that you are seeing? What are the potential for security that are there that worries you? And they're like, hey, we have to solve this. So first I would like to say that it's more or less the same as in the distributed world. Like it's again, the privilege escalation. Lots of the attacks are coming from actually pishing and stealing the user's authentication credentials. Lots of the potential problems are coming from overflows. Even more so, I would say than in the distributed because most of the software on mainframe from where I stand is still written in C and high level assembler. So it's very easy to create a memory leak compared to like higher level languages like Java. So these are definitely the biggest one. Like for us, we as Zoey became a CV numbering authority. So we are publishing our own CVs. This year, we already published two of them, like both of them, one of them is very old and one of them is very low priority. But ultimately these were in the area, one of them was privilege escalation and the other one was about, well, basically privilege escalation via command line. So I would say that it's the same. The only difference that kind of improves the situation overall in the mainframe world is that the ESMs, the enterprise security managers, tend to be configured in a way that unless you have a very specifically edit privileges for someone to do something by default, you just don't have the rights. Which is kind of something I would expect in the distributed by default as well, but it's not always there. In mainframe, it's just how it is. Now, once again, since the open mainframe project, Zoey project, you do have the whole community, you know, the mainframeers out there. So there's a lot to learn from them. So talk a bit about what ideas that you folks have borrowed from them or to kind of set up some security standards for Zoey, which not only just help the Zoey community, but it can also leverage the other distributed words as well. I would like to say that there are lots of them, but one of the things that kind of distinguish the mainframe from distributed is that it still lives a lot in its own space. So one of the main defenses is that you just can't access it. And if you can't access it, like you can defend thing that nobody can access. It's far easier than accessing something that's than defending something that accessible over the internet. So I would love to say there are lots of things we learned from the mainframe community, but apart from few minor things, there is not that much. And the things that we did learn were more around how do we configure, how do we make sure that the people that are configuring the solutions get the information in a proper way? Like for example, for the mainframe products, it's typical to provide the sticks, which is a security guidelines where every possible point which touches the key security mechanisms within mainframe are outlined, explained why does this product touches it, what are the potential concerns and whether or not you are willing to accept it given the functionality that you are looking for. I would say this is one of the, let's say the biggest things coming from the mainframe itself. And then the second is the dependency on the mainframe ESMs, so enterprise security managers, because they do a lot of the work in background. And one of the areas that they do really well, I would say that in the distributed, we are now talking about observability, and this is similar, but everything that's happening on the mainframe is being propagated to a single flow of events that are known as SMF records, among others. And then these SMF records are used for auditing of anything that's happening on the mainframe. And when I say anything, I mean literally anything, it's on the level of touching the file. Like you really can get the full understanding on everything that's happening in the system. The other part is that it's typical by the mainframes, like lots of the things that are great in mainframe are that they are part of the platform and we don't have to care. Like for example, you get by default the end-to-end encryption for everything, for data in flight and data at rest as well. So things that we would have to implement if we were living off Z are just there and we don't have to care. They're just implemented, we don't have to do anything. Excellent, thanks for sharing that. Now, if you look at Zoyi Open Mainframe or the larger umbrella, which is Linux Foundation project, there are a lot of projects which focus on security. Do you folks like work with them or leveraging each other's works to like kind of improve the security posture for Zoyi? Yeah, we do a lot. Actually, we follow the open SSF, so open secure software foundation, which does actually a lot of work in the area and one of it is the specification of the standards and what is expected of the projects to follow. Another one is preparation of the education courses for the developers and engineers on the team to understand what does the secure mean? How do they develop a code securely? What are the potential risks that they need to face? So this is really useful and on top of that, they are creating tools such as scorecards. So open SSF is following, I think now it's around 1.5 million open source products and on a weekly basis, they run scripts that are going through the practices and verifying whether these projects are healthy, whether they are behaving in a correct way, whether all their configurations and setups are safe, or whether there is a risk of a supply chain security problem. So we are involved actively looking in these areas. For example, for the scorecards, we have a plan to integrate this information into our pipelines and into all the discussions that we are having about adding a new dependency to our chain and also about when and in what way we want to upgrade all the dependencies that we have. Like ideally, we would be upgrading everything just when there is a new version, but we have like 900 dependencies and it would take a lot of effort. So we are doing it more in batches. Can you talk about how much awareness? I'm not talking about the technical community within Zoey or Open Mainframe, but the ecosystem, the users, the vendor, how much awareness or concern there are in terms of security, because that also means that they will actually start adopting some of these practices. I would say that if there is anything that we can count on them asking actually about its security, if we are doing a security talks under conferences and shows, this is best attended, basically I would say always the best attended courses and best attended sessions that we have. So they do care and there are a few different groups of people that are getting in contact with Zoey. First are the actual engineers that are deploying the Zoey into the mainframe environment and they are asking questions like, okay, how do we make sure that it's okay? How do you prove to us that it's safe, that it's secure and that you are not breaking anything? And we have the answers for them, more or less. And if we don't, then we just fix it. The second group are the people that are actually using the Zoey. So application developers and people that are living within the organization and using that already deployed Zoey. And these people are asking us question about, okay, you are operating it, is it really safe? Who is going to get access to my data? How do I make sure that I'm not directly and providing a leak to someone? And also what are the benefits for me? Like, okay, you are claiming that you support the single sign-on for all the mainframe services. That sounds good, but how does it work? It's not just that they are trusting us that when we say that, okay, we do this. They're also asking, okay, and how do you do it and how do we, how we can verify ourselves? And then the third group of people is maybe not executives, but like people responsible within the companies. So it could be up to executives who are asking the questions like, okay, you are an open source project. So how do you make sure what your internal processes looks like? Where do we find the policies? How do you make sure that what these policies are actually followed? So we have answers for all these three groups. And if you want to take a look, the ones that are directly related to how we handle security-related issues is part of the Zoey.org. There is a security session section. Then we have as a TSC, all our policies published under our GitHub repository. So you can read everything on how do we handle new issues? How do we handle potential risks and problems? How do we release? In the world stage of release, who needs to approve the things? And on top of that, if somebody is ever interested, we are running a weekly security work group course where we are first auditing the things that are happening within Zoey, where there is a potential risk. So we are actually going really through all the events that had the potential to compromise the software we are producing and verifying that they were okay and that there was no malicious intent behind it. Yakub, thank you so much for taking time out today and talk about this topic today. And as usual, I would love to have you back on the show. Thank you. Thank you very much. Thank you for being here and I relayed it into your question. So looking forward to next time.