Securing the Game: Navigating the Challenges of Product Security in Gaming with Rohit Selacha (Zynga)

Hello everybody. And welcome back to another episode of Build Amazing Things Securely. I'm your host, Laura Bell Main And today we have a special guest from the gaming space. Now I met this guest by literally stalking them on LinkedIn. I am not a good person. So thank you so much for coming on anyway. I'm very pleased to welcome Rohit to the show. Welcome Rohit. How are you doing?

Hey, thank you. Thank you so much for inviting me to this show. I'm really looking forward to sharing whatever little I know about security.

yOu're in good company. I think all of us would admit we know very little, but we try very hard. So as I do in all these circumstances, I'm going to ask you to describe yourself. Who are you the human?

I Would say I'm a geek. I love technology. I love anything, that's running on the computer or running even on embedded systems. lIke after my college, I was so interested in an embedded systems that I actually did an embedded systems course, but that's fine. Like I was from electronics and my background is from electronics but I have moved my career into computer and computer related technology and slowly moved into security primarily because in security I saw that you have the length, breadth, and depth of things. LiKe for example if you're, let's say developing a service or a product, the focus is only on that product or the functionality of that product. But in security, you have to look at what is the business functionality of the product? Where is the product being deployed? How is the product being deployed? What is the attack surface of the product what is the, business risks of the product, et cetera. So it's like a 360 degree technology view. I would in, in simple words, I would say I'm a geek, a technology

I love it. I love it. And I love that. Like most of our audience, most of our guests. Your pathway has been your own journey. I love that you come from electronics to security and that you love the challenge, the puzzle of it. Now, the reason I stalked you on LinkedIn and reached out was because you're doing AppSec in some very interesting places, and I think that's pretty cool. So when I first spoke to you, you were at Disney one of their subsidiaries, and now where are you? What do you do? What's your role?

my product security experience started with Disney plus hot star. Previous to that, I was more than a consulting role. But not so secure where I've delivered where I've created very really interest created and delivered a lot of interesting trainings around application security for developers, DevSecOps uh, and with Hotstar, I started my, my product security journey and currently I'm working with Zynga Games which is a subsidiary of TakeTwo TakeTwo Interactive as well.

What are the games that Zynga make that we may have heard of? I'm sure that there's games that we will have actually known from Zynga.

tWo of the very famous games is Zynga poker and Farmville. hAve you guys, have you played Farmville?

Ah, Farmville! I knew it was familiar. Who hasn't lost a number of hours to one of these kinds of games? Okay, what an adventure. So you started out doing training and not so secure has an amazing reputation. So it's a great place to be doing that. And then you've moved on into a practitioner role. Now that's a big shift moving from trainer to practitioner. And now you're in the gaming space. Now I want to, over the course of our chat today, really dig into what does security look like in a gaming company? What kind of things are you concerned about? What are the risks that you're trying to protect against?

I would say like from, for a gaming company or for an OTT company the product is maybe different. Everywhere it is always applicator, like the first layer is infrastructure, then is application, then is the data, right? So your entire product revolves around these three aspects. And these are the three aspects where the entire product security team is basically looking into security of the infrastructure. It can be container, cluster, cloud. Security of the application it can be a service, it can be a backend service, it can be a front end for backend service, like various different kinds of services. And then finally, it's the data. Finally, be it an OTT company, be it a gaming company, be it a SaaS company everything basically revolves around that data, right? So all the compliance regulations around it how to protect it, access, authorization, etc. So to me product security is basically securing these three aspects of of every product, which is absolutely common. Take it, take it, whatever example you want.

So I'd love to, let's dig into Farmville a bit. Now, full disclosure team, I'm not in any way stating that this or any other game is vulnerable, but I wanna use an example from this world, because for me, Farmville is like a, it's a casual game, right? There's a game you play maybe on your phone or a mobile device. As an attacker, zinger itself as a company, I get, but the app itself. What kind of things do you think about in terms of attack vectors via an app? What would they want to get from FarmVille? Surely it's not just free chickens.

There are various attack vectors that can be possible. People may want to grow their crops faster or maybe get to the leaderboard faster. Or maybe you can say is, get more coins without paying anything, right? So there are various different attack vectors that are possible. Again, it all depends on how you can manipulate the data that is there in the backend, right? So again, everything falls down to infrastructure application and data, right? So when we talk about data security, it's not just always about encryption. Data security can be also about manipulation. It can also be about integrity of that data as well. Confidentiality and integrity of that data as well. So yeah so these are the,

if we look at those attacks you were mentioning there what strikes me is us as end users, we might go I just got some free coins or my crop crops grew faster and what's the big deal? Because, for me it was fine and it didn't hurt anyone else. But for Zynga as a company, that's part of their business model, right? It's a microtransaction type arrangement. And so if people are bypassing those controls, it's not just really about the farm. It's about the commercial impact of people being able to bypass those controls. Which, you really have to start thinking about it's not just a farm on my phone. This is, like any other payment system. You can imagine team who are listening at home whenever you're handling transactions, we tend to think all transaction systems look the same, like you're an online shop selling something, but. Even in a game, that's a transaction based system. There's still credit card details somewhere. So we've been talking with folks around the world and what we're finding is that we tend to have pretty large dev teams. We don't need to talk specific numbers, some folks have tens of developers, some have hundreds. And what we're learning is that. At a certain scale, folks don't have anyone who's looking after product security, so it's pretty amazing that Zynga has specialists in role doing that. And that scale, that provision of resource so that you can protect it is really important. How many, I'm gonna, I'm gonna, I'm really trying to help out here and not ask for specific numbers because I'm a numbers person and that's where I go. Okay, so how much time would you say that your development teams currently spend? With you talking about security, is is it a big focus? Is it a small focus? And what are the techniques and things that you do that you find work really well in this environment, getting people to care about security?

Yes people are quite excited and cautious about security. There is definitely some level of there is definitely a good level of security awareness that's there. And it's not just about Zynga, but I've seen across different product companies as well. Where, where security awareness, like basic security awareness is definitely there. Mainly the conversations that happen. Between the developers and the security engineers the security folks within product companies is around more around architecture, more around hey, we are doing this kind of a change or hey, we are planning to build this. What are your thoughts about it? tHe internal security team is, looked up to. To provide the security expertise or security or you can say the knowhow for for, changes that the developers think might have an impact on the, the application or the data or the infrastructure. So that maturity is is there in almost all product security companies, I would say.

Yeah, that's really good. It speaks to that almost internal consultancy model where you've become that trusted advisor. And I know there's a lot of teams out there who are working towards their dev teams coming to them and actively seeking out that assistance. How would you, I want to dig into your past meets your present, because I think that's a nice place for us to really focus this conversation. So you started off as a trainer. With not so secure. Fantastic. What kinds of things were you teaching then and how are the skills that you develop then useful to being a product security person?

Yeah actually I started off long back I started off as a Java developer in 2010. I used to develop in J2ME and J2EE

Oh, I'm sorry.

yeah but yeah, while one of the applications where I was working, it was it was a very critical and a sensitive government application and that's why there was a lot of focus around security of that application. And that's where it caught my attention as well because these folks who were reviewing the application they were looking at everything, right? All I knew at that time was how do I code a specific functionality. But these guys, they were looking at the servers, the deployments, the authentication, the authorization whether the credentials are configured properly et cetera, et cetera, right? There were, there was a multitude of various disciplines and things that they were touching, which is what really interested me. And and then basically I I was, I would say I was quite fortunate. To to have applied to a role that specifically needed someone with a little bit of security background, but a good Java background. And this is where I basically then moved into a security company in Mumbai Consulting. Now I think it's named as something Network Intelligence India. All right. It's renamed it a little different now. THat's the, uh, that I would say was my launchpad for security. And it was a terrific experience, amazing team. I learned a lot about security about web application security, mobile application security, which then I continued for about. Another four, five years doing and specializing in web and mobile application security. Up to a certain extent, even in not so secure when I joined, I was hired as a pen tester, right? So I was not hired as a trainer, right? I was hired as a pen tester to do a pen test of web application and mobile application. But from our pen test, what we realized was that developers are struggling in understanding security, right? And that's where we basically developed a training around application security for developers, right? And after delivering a lot of these application security for developer trainings, we saw a trend that was moving towards DevOps. And cloud and Kubernetes and Docker and so on, right? So that's where basically I I did some research. I was given time to do some good research around DevOps and basically me and my team we developed a training called as DevSecOps, right? And this is where basically, uh, Along with my cloud, along with my mobile and application security, I started developing a keen interest into cloud and cloud native technologies. And I started moving into into these different domains. After a certain period, I'm not so secure. I started realizing is that I now know a little bit about applications, little bit about mobile, little bit about cloud. A little bit about containers, right? So I thought that it's the right thing to do is to basically move into an an opportunity where I would be I would be responsible for all of these things put together. Targeting something individually is not something I was keenly interested. I was basically looking at the bigger picture. I was interested in looking at the bigger picture and securing it from the ground up.

I Love this story. I love that you've gone on the real like end to end journey. So from enterprise Java through to penetration testing, through to teaching web app security, but then onwards to realizing that you needed to research and teach new things, and now you bring it all together now that. That kind of journey and the skills you've picked up on along the way are a really good picture of what it takes to do product security, right? Because product security you walk into a team and it's not one technology. It's dozens. It's not one piece of code It's a lot and there's a lot of diversity in it. How do you find the diversity working with your current team? Is it hard to keep up? Is it easy? Which bits of this are really push you which ones are challenging you?

The diversity that we generally find is mainly around the languages and the platforms that that people use, right? Generally, what we've, what I've seen is people generally use the same container technology, the same cloud technology, the same cluster technology uh, applications as well. Some services are built in PHP, some in Java, some in NET, some in Python, et cetera. That is a place where maybe we might have to invest some of our time in identifying. How can we help people do secure development in Java or how can we help people do secure development in PHP, right? Because one size does not fit all, right? I've tried in the past to create a common ground but that doesn't work, right? As soon as I start a training on Java security or I give some recommendations on Java security There is a Python developer who's I'm doing Python. I don't know about Java. I don't care about Java, right? So that is a an area where I think product security professionals have a lot of ground to cover specific to, to create to create guidelines, to create best practices around. Around the four C's, as I call it, right? Code, Container, Cluster, and Cloud, right?

I love it.

yeah, and some organizations also have have they go beyond four C's, right? There is configuration also. There is a huge amount of configuration that goes in, right? There are zookeeper and there is a lot of different stuff that's there secrets management, et cetera, right? So for product security professionals, I think everything revolves around this, these four C's that are there and to bake in the contextual information about the product as well, about the organization, about the culture of that organization. into into the their security strategy, right? For example, if you see Netflix, right? Netflix started with a checklist based approach, right? And majority of their checklists was something that was, so they basically identified a huge chunk of common functionality of that checklist and then they created their own application that I forgot the name. That does authentication, authorization, input validations, and a lot of bunch of different things at the central layer, right? Every product organization, I would say should basically start with something rudimentary, a checklist, but then mature towards automating the the major part of it.

I think that's really good advice. So we've got listeners from every end of the spectrum, from the less mature to the mega mature. And wherever you are, you're there now. So starting out with something like a checklist is a really practical step that's not going to cost you anything. A little bit of time. But then you can turn into something more. So can I ask, I'm going to ask you for an opinion and don't dodge it. I'm sure you can do it. So in your view, not that of your employer is it good for security if we restrict the number of languages our products can be written in? Should we be more forceful to make it a smaller set of technologies or is it our job to adapt and really embrace the variety of. It's technologies and software.

What I've realized in product security, being in product security is that you can never use the word called restrict

True, true.

Because the engineers and the developers, they need the freedom because that is the freedom that drives the business to be mounted, right?

This answer. That's such a good answer.

Yeah. And it is the work of the security team to align with the engineering teams and the development team to, to basically create guardrails and not gatekeeping. That's a very common statement that a lot of security practitioners already give out. But being in this domain I actually feel that we have to create guardrails, right? And not. Create gatekeeping, right? Gatekeeping will slow down the business which is not in the best interest. So yeah, so I would never restrict any, anyone to do any, any restrict anyone from using any specific technology, right? Like I would say, okay, fine. You want to use this technology? No problem. You give us some time. We will shell out the best practices for that from a

That's awesome. That's really cool. And I like that, I'm half engineer, half security nerd, and I know that there's definitely part of me that would really resent. Having boundaries put in place and my engineering instinct would just help me work around them because that's what we do. So I'm going to ask a little bit of follow on question. Do you have a favorite language? Which language do you love working with? Are you like, Oh, great. It's a project in that.

So I'm not actively done any web development or any application development as such. But I'm still, I would be, look down upon too, but I still like Java.

Oh, there's no shame in still liking Java. There's a lot of Java in the world. That's awesome. And I

People might think I'm a bit oldie in that space. But I would still like Java because I still inherently understand a lot of Java to a certain extent, but then for a lot of my, for a lot of my automation I use Bash and Python a lot. Yes.

And I think that's a nice thing about, if you go meet any product security folks, especially ones who've been developers in the past, have these kinds of conversations, find out what their history is, because you might find that, that they have a shared root as you, or that there's a language that they have a soft. Spot four that you can bond over and that creates a good relationship. So you can then really, work together on security. This has been really interesting, right? I've got lots to think about and I love the flexibility that you're bringing to things and that pragmatism that even if you're in a gaming company, it comes down to the same key elements as anything else. And so now that tells us two things. It tells us that security matters and is important. And it means that in every context, we should be applying those basics. And just to repeat your bit of guidelines, think about building a checklist team. If there's something you want to make sure is happening in your code, from a security point of view, a checklist, isn't a bad place to start. You don't have to spend any money on it and you can change it until you're really certain that's going to help. So thank you so much for your time today. It's been a pleasure talking to you. Thank you for taking time out of your schedule.

Thank you. Thank you, Laura, for inviting me. It was great chatting.

And perhaps next time you're on your phone team who are listening at home and you're playing a casual game, I know you will do it and I don't judge maybe you'll think about. What would security mean here? What kind of cheats would I do in this game and how would they impact the overall company that provides it? Because just thinking about that triggers that bit of muscle memory and you start thinking about security all the time, right? Thank you so much everyone for joining us and subscribe and all of those things you're supposed to do and we will see you next time.