Talk: Security analysis by example with Mina Boström Nakicenovic, Paradox Interactive

Enjoy a replay of The DEVOPS Conference sessions conveniently through the DevOps Sauna podcast. This talk is hosted by Mina Boström Nakicenovic, Paradox Interactive

Lauri (00:05):

Hi there, and welcome to DevOps Sauna podcast. Eficode has organized The DEVOPS Conference where it predecessors for a number of times. Last time in April 2021, over 10,000 people registered to the event. The DEVOPS Conference is a community event where attendees do not have to pay for the participation, and we are happy to organize it again on March 8th and 9th, 2022. You are all wholeheartedly welcome to join the event and register at thedevopsconference.com.

Lauri (00:37):

If you are a DevOps, Agile or cloud practitioner or decision-maker, I also encourage to review our call for papers. We are introducing a whole new community track to give more stage time for people with their personal experiences and insights. All of the speeches from the previous time are available online to watch, but to make it easier for people to enjoy these great speeches, we are also sharing them through our podcast. I hope you like them as much as I do.

Mina (01:09):

Hello everyone. So nice to see you in this digital online setup. So, my name Mina, and I'm the CTO at Paradox Interactive. But who is Paradox Interactive? Let's see. So, we are a game developer and game publisher, and here are just some of our titles. Maybe you have heard about some of them, Europa Universalis, Crusader Kings III, Stellaris or Cities: Skylines. What is a little bit special for Paradox is that we've found our own market niche, blue ocean, within video gaming industry. And we are creating a little bit special strategic video games. And usually they're combined with a lot of historical events.

Mina (02:04):

So if you like history, or you like that challenge of strategic thinking, I can really recommend our games. I really like them also. But we've also one very special game that is called The Surviving Mars. And it's not one of our most popular games, but it's very special. And even if you haven't heard about it, I can guarantee that you have heard the game. How? I can guess that many of you have been watching NASA's Perseverance rover landing on Mars, right? And in the background, NASA played music from our Surviving Mars game. So you probably have heard the game. It's a wonderful game and I can recommend that both in combination with Perseverance rover and without it.

Mina (03:05):

But now I have presented just Paradox and let's present myself a little bit. Who am I? So I have been working with the software development for more than 20 years. And I have understanding of that deep technology side for many, many years, working as a developer and an architect. But when I realized how business leadership technology and product strategy intersects and how I can leverage them for competitive advantage and creating the value for customers, I switched to the managerial path. And now I work as a Chief Technology Officer at Paradox Interactive. I worked for many, many years within FinTech industry, but with the Paradox, I entered that beautiful world of video games industry.

Mina (04:08):

Why is it so wonderful? Because when you work here, you feel like that you jumped into intersection of technology and art. So you feel like being kind of Leonardo da Vinci, because you try to combine technical innovation with that art experience that our players want to get. And it's not only about that. In order to create excellent video games that are really engaging for our players, you have to put a lot of other things in it.

Mina (04:48):

Maybe some of you have read what Elon Musk said once upon a time. Before his Tesla time, when he was a teenager, he created video games. And he said, "I was a true bookworm and reading a lot of books. And thanks to that, reading a lot of books, it helped me with developing video games. Because all that extra knowledge, strategic abstract thinking, you have to put that in games in order to have successful video games."

Mina (05:24):

So it's wonderful working for video games industry. I can really recommend that. And as I said, our main focus is to deliver the best experience for players, both from artistic perspective, but also from technology perspective. And what is interesting and relative for them it's security aspect, right? Our players must feel safe and secure when they play our games.

Mina (05:55):

So today maybe I'm going to disappoint you because I'm not going to talk about any juicy examples for video games industry, because we don't have any security vulnerabilities, but what I'm going to talk about, it's about security analysis and three important things; why, who and how. Why question I guess that it's an easy question. Many of you understand that, but let's repeat that again because of some extra reasons.

Mina (06:27):

When you talk to people, it's not so clear who should own that security questions. Many people are saying, especially from development team, sometimes I've heard, it's like, "Oh, security analysis it belongs to the IT team." Is it really like that? If we take a look about software architecture and its quality attributes, you're representing a lot of quality attributes and you agree that all of them are equally important in order to design a good architecture. It's stability, scalability, performance, but it's also security. So in order to create good architecture, security is a very important quality attribute.

Mina (07:14):

So that's why, when I'm talking about security and analysis and who should do that, where it should belong, I don't like to distinguish it should be on development teams or architects or special security professionals, or IT team. I like to use something that is called CIA model, because it takes a holistic view on the whole security question.

Mina (07:40):

"C" stands for confidentiality. It means that you should prevent sensitive assets from reaching the wrong actors and at the same time, allow authorized actors to access it. So it's regardless if it is your product, your customers authentication, authorization or the same applies for your employee accounts, for example.

Mina (08:05):

"I" stands for integrity. It means you should assure consistency, accuracy, and trustworthiness data over its entire life cycle. It can be data that are preserved in documents, but also all data from all your data pipelines, or all things that you send from one part of system to another part of system. And last but not least its availability. A guarantee over reliable access to the information from all possible perspective, both hardware, software. It Includes disaster recovery, business continuity, and et cetera. So, now we answered that question, why. And now we are moving to the question, how.

Mina (08:59):

So if you say that we don't distinguish who should do that, how should you perform security analysis? And here I just propose one model, one methodology that I really like to use. It's not rocket science, but I believe that it's very simple and due to that simplicity, it's easier to get by in from all teams within your organization, both development, IT security specialists.

Mina (09:28):

So we are going to go through that methodology and see which steps does it have. The first step is that you start with identifying all actors in your system. Who has access to your system? From all perspective? All your product, external system, internal system. And you should create a table like that. Probably you have employees, maybe you have some contractors that have access to system. Then you have maybe in our case, players or some other actors in the system. But when you list all those actors, don't forget to put untrusted actor, because unfortunately, there are actors of all systems.

Mina (10:16):

Let's continue with the next step. After identifying all actors in the system, you should identify all sensitive information assets that you have. And probably you have a lot of assets within your company, but only subset of these assets contains sensitive information. And they're relevant for the security analysis. For example, you have accounts, employee accounts, maybe customer accounts, probably you have some website, you have documents all over floating through your organization, source code, if you're a software development company, data and et cetera.

Mina (10:58):

So it's the second step. When you have listed those two things, then you start the real architecturing thing. You are trying to draw interesting information flow diagram. You want to see how these sensitive information assets flow through your systems. And when you're doing that, then you should point where you see some possible security vulnerabilities. You see, "Oh, I integrated this system with this system. Oh, there is a risk that some information leaks or it's not secure enough."

Mina (11:38):

When you have identified those points, you do the fourth step in this analysis, creating a security vulnerabilities table. So this table contains all sensitive information assets and all actors in the system. And you put points or crosses where it feels that there is a security vulnerability, where there is some risk for some attacks.

Mina (12:08):

Now we have identified all actors in the system, sensitive information assets, analyzed the flow diagrams and created this security vulnerabilities table. What is next? The next is to analyze all those security vulnerabilities because all of them are not equally dangerous, right? You should analyze them and create something that is called "threat matrix". What does it mean? I guess that many of you have seen that or used that, but let's repeat. What is the purpose with the threat matrix?

Mina (12:46):

You want to analyze all security vulnerabilities from two different perspectives. What is impact on business if it happens, and what is the probability that it happens? Because it can be some things that has a very low impact on business, although it's maybe big probability that it happens, maybe it won't be the first thing that you would like to fix in your system, right?

Mina (13:15):

So from the impact perspective, you classify business impact, low, medium, high, and very high. From probability perspective, you classify from rare, unlikely, possible to probable. And then you put different coloring because what are the severe security vulnerabilities? It's if it is high impact on the business, and if it is big probability that it happens, right?

Mina (13:44):

So that's why those things in upper right corner are red. So you translate all your security vulnerabilities and put that in the threat matrix. What is the next step? What do you think? You cannot answer? I know that you're answering in your head and I guess that many answers are right, but you want to mitigate these risks that you have just identified and you put them in your roadmap, right? And then fix the things.

Mina (14:22):

Are we done now? We did a big part of our security analysis, important part, but there're some things that are left to be done. What did we do with this security analysis? Which kind of security vulnerabilities we have discovered? We have discovered just known vulnerabilities, right? That you know. If I have a website, maybe I should test for cross-site scripting and et cetera.

Mina (14:54):

In order to explain it better, I will refer to Cynefin framework. I guess that many of you have seen that framework. Cynefin framework is used to distinguish, to take a look at your environment and the problem that you should solve and give you advice which things or which actions you should take in order to find a solution for your problem in that environment. And all environments are divided in four different categories, obvious environments, complicated, complex and chaotic.

Mina (15:33):

What does it mean obvious environment? It means that it's those type of problems, when you see the problem you know directly the answers. It's: known knows. For example, you get a task, two plus two. You know directly it's four. You don't have to analyze or to do anything more, apply mathematical formula of course, for adding, but it's always in your head.

Mina (15:55):

Complicated environments, it's called known unknowns. What does it mean? You don't know the answer directly, but you know, if you have analyzed the system, applied some formulas or algorithms, you will get the answer. And it's exactly what we did with this security analysis, right? We did not know all our security vulnerabilities in the beginning, but if we knew if we apply these steps, we are going to get our wanted outcome, our threat matrix. But by applying this security analysis, you just covered half of environments where you can reside.

Mina (16:38):

Then we have complex environments with unknown unknowns. And recommended way for discovering or find the answer, it's not by analysis because you don't know what you should analyze, but you should try out some things and then sense, see the outcomes and then create some actions on that. And it's exactly what we are doing with our penetration tests. Maybe with some crowdsource testing, right, or paying for some bug bounty initiatives. We don't know in advance what we are going to discover, but we are doing these activities in order to discover those unknown unknowns. We are just trying things, and when we got the outcome results, then we can act on that.

Mina (17:29):

And finally, we have chaotic environments. It means unknowable, unknowns, unpredictable unpredictables, or so-called black swans. The term came from Nassim Taleb. And I know that many of you are familiar. And furthermore, we experienced two, at least two black swans last year, unpredictable unpredictables right? COVID-19, starting working from home, almost all companies worldwide. Also, another unpredictable unpredictables happened in Sweden in December when Google was down for 45 minutes. Do you know how big impact it had on the whole business?

Mina (18:26):

So it's just example. And can you prepare yourself for black swans? Maybe. Because if you take that threat matrix that you kept creating by analyzing your systems and list some of the black swans, and I know it sounds very naive to say mitigate black swans, mitigate unknown unknowns, but after things that happened last year, I think when a black swan happen, you can maybe not mitigate the black swan directly, but you can mitigate the consequences of that.

Mina (19:06):

So create a list of all scenarios or possible black swan scenarios that came out of that, combine with your threat matrix that came from the pure analysis of your system and put everything that in your roadmap. And when you have completed all these steps, then you are ready to create policies.

Mina (19:31):

I've also noticed that at some companies, people are creating policies before they apply the whole security analysis, and it should be vice versa. And now you understand why the policies should come as almost the last step. And now we are approaching the last step in this methodology. It sounds simple, but in fact, it's the most complicated step. At the end, you should establish DevSecOps practices at your organization. But before we dig in, what does it mean and how I explain DevSecOps and what are the challenges with establishing such a concept? Let's see some adverts, that's some break now.

Mina (20:31):

This year it's 20th anniversary of Agile Manifesto. I was lucky because at the same year when Agile Manifesto was published, 2001, I met my husband, and he told me about Agile Manifesto at our first date so I could be an early adopter. And I was applying Agile practices since then. But for you who are a little bit younger than myself, and maybe you didn't have a chance to talk to your partner 20 years ago about Agile Manifesto because at that time you were maybe only five or 10 years old, let's just repeat some basic things, the most important things from Agile software development.

Mina (21:25):

And I know we don't have time to dig in the whole Agile. Now Agile has so many layers and perspectives, but one of the most important thing with doing Agile software development, it's to do an iterative development. What does it mean? Didn't we do iterative development with Rup methodology, for example? Yes. But here is not only focused on short iteration, but also the focus is on fast feedback.

Mina (21:58):

That's why you are doing iterative development and short iteration, because you want to get fast feedback on everything that you do and use that outcome in order to improve the things. It can be software, it can be product or business idea, or so on. From the Agile perspective, I think we improved a lot from many perspectives: continuous integration, continuous delivery, product leadership. We have a lot of new methodologies, which are really focus, how you can have those short iteration cycles and processes, how you should combine that fast feedback and know the direction, how you should develop your product, build, measure and learn, pivot, or persevere.

Mina (22:46):

We have a design experience how you should work altogether, developers with the UX designs, user research, product, people, testers, et cetera. But if you go to basic, to the main software architecture and quality attributes question, some quality attributes, we are really focusing on them very much, like performance. We are measuring all the time. You are putting all the time KPIs, have that fast feedback and place in process to react if your performance go down or not. Right?

Mina (23:25):

But what can you say about security? If you do penetration tests once per year, is it really Agile? Is it really an iterative development with the short feedback cycles that you are incorporating all outcomes in order to improve that quality attributes? No.

Mina (23:47):

And now I'm just going to present, what does DevSecOps concept for me? I know there are a lot of definitions, but for me, DevSecOp concept, it means that security is everyone's responsibility. All teams who develop software or are responsible for software and IT systems should feel, "Security's mine." Not that they feel, "Oh, he's responsible. We have that security expert or IT team." That everyone is aware and take that common ownership as Agile recommends.

Mina (24:24):

Then to have such processes that you include security analysis, mitigating risk, that it becomes a part of your iterative development, that is not standing on the side, doing separately with separate people, or just as I said, once or twice per year. So as we are saying in Agile and Lean world, when you developed product, you should build the quality in.

Mina (24:52):

The same goes for security. You should build security in. And that's why in order to explain that you should think about security from the very early beginning, this approach is called shift-left approach. That you should not have approach you develop your systems and then apply testing on the end or penetration tests or so to analyze, but from the beginning, that you should think about all these analysis about all your security vulnerabilities, that you're constantly including mitigation of security risk in your backlog, so that you work actively with the threat matrix and the backlog.

Mina (25:37):

What does it mean? It means also that you should apply that little bit TDD: test driven development or in security world, it's called STDD: security test driven development. It means that when you write your epic or story for some new feature, that you should always think, "Oh, in parallel, maybe I should add an abuser story, which explain the possible vulnerabilities that I can introduce with implementing this story."

Mina (26:12):

So it belongs to that concept that you should always think how you can hack yourself from the beginning before hackers can hack you. For example, you're building a website and you want to build a feature that all visitors can leave their feedback on the website. So for example, the user story explains that. What would be abuser story that is linked to this user story? It's for example, possibility or opening vulnerability for cross-site scripting.

Mina (26:45):

Of course, when we are thinking about security and adding all those things, stories, there is one con of the whole approach. It's that if you add a lot of those security stories or assuring security, that it would slow down your development, and that's very true. But that's why you should find good balance, trade off between good speed of development, but also security, so that missed security does not cost you much more at the end. But of course, like with every everything in life, it's that a good trade off. And you should create resilient systems and organization.

Mina (27:34):

What does it mean? It means that you should not only think, "My system should be completely secure that no hacker will manage to hack the system," because it's not reality. You should think like that, "If my system is hacked, do I have a resilient systems and the organization to recover quickly from that hacking?" So we should make a switch in mindset. Of course, we should secure our systems and solve security vulnerabilities, but at the same time, think all the time have that approach: "We can be hacked any day. Do we have all disaster recovery, business continuity plans in place that we can recover quickly from these hacking?"

Mina (28:23):

It's something that Nassim Taleb described when he introduced that term antifragile systems. You can divide all systems in four different categories. Fragile systems are systems when they're exposed to shock, they break directly. Robust system, when they're exposed to shock, they can stay robust for time and then break like stone.

Mina (28:48):

Resilient system when they're exposed to shock, resilient system get disturbance but then after a while, it goes back to the previous state. What are the antifragile system then? It's not opposite of fragile. It's not only resilient system, but it's systems which should even more evolve after exposing to shock. What does it mean? That you are not only resilient and go to the previous state, but also that you have learned something from that, from that black swan that just occurred or so on.

Mina (29:26):

So I would emphasize also the importance of that way of thinking, not only to build the security in, but to think all the time, "If my system get hacked, do I have a resilient and antifragile systems that can recover quickly? And then do we learn quickly from that so that we'll be better next time." That you have all disaster recovery plans in place, contingency plan, business continuity. Because with disaster recovery, it's only that resilience thing, but you want to continue your business, and so on.

Mina (30:03):

I just wanted to show you again, my security analysis methodology with these eight steps. And I think it's very easy to think about that, and to introduce some parts of that in your iterative Agile process that you apply like on ta sprint basis at your company.

Lauri (30:28):

Thank you for listening. To register to the DEVOPS Conference, go to thedevopsconference.com. If you have not already, please subscribe to our podcast and give us a rating on your platform. It means the world to us! Also, check out our other episodes for interesting and exciting talks. I say now, take care of yourself and see you in The DEVOPS Conference.

Mina Boström Nakicenovic
Chief Technology Officer, Paradox Interactive
Linkedin: linkedin.com/in/mina-bost
Twitter: @bostrommina

Watch all recordings from The DEVOPS Conference 2021 on the event's page: https://www.thedevopsconference.com/speakers