 Hey everyone, so today we, I'll be presenting about set modeling and yeah, like I'll start with my dad, like my dad is a great third modeler. So we will learn set modeling with the reference of my dad. So first thing first, something about me, I work as a security engineer at Pinot. I suffer from voluntary stress because like I, like you can find me volunteering with almost every conference working behind the scenes. I'm more of a security rankler than engineer. I live on the principle of working around and finding out the landmines in the organization infrastructure and architecture. You can always find me on Twitter and discord. So let's start. Okay, so as once Dan Kaminsky said during deaf on 23. Who are we who are the hackers like we are the people who manipulate how systems really work, not just merely how they are supposed to work. And that does not always mean we know how they work. It helps, but we don't always know, and not knowing how things work, tends to cause them to fail. And we hackers just define the failure condition as a success, success condition, when every engineering team fails security team wins. And like we in security thing that's people other people can make mistakes and fall into pits but we security folks are immune to everything. But we believe every screw things all the time, but we just have an attitude about it. So that modeling, what is set modeling, like by definition, that modeling is a structured approach of identifying and measuring risk or prioritizing them, determining the value that potential mitigations can reduce or neutralize those threats. In general, when we when we proceed to that modeling, there are four questions which comes in our mind. First is what are we building or what we are looking at, but could go wrong, either it's an infrastructure application, or maybe a physical building, you're like you can fit model anything, any infrastructure, anything. So it reminds me of last week I was attending the initiative virtual conference and there was a talk about that modeling your mental health, unlike it was a superb talk. Then we can identify threats by thinking what could go wrong. And then when we recognize states, then we need to understand what we are going to defend to defend us against those threats. The final step will be like, if we know that we are threats, we know from whom we have to defend ourselves. Now are we acting on those trips or not. If we have acted then what's the result of this now. I'll start with some boring frameworks to get the basic understanding. I won't go deep on to them, I promise. And like, as, as usual, no one likes doing things in theory. So let's start with Octave. Octave is more like practice focus set modeling framework and full form of Octave is operationally critical set asset and vulnerability evaluation framework, which basically defines the risk. Like which basically defines strategy based on risk assessments and planning techniques, like Octave is a self directed approach when you are starting with Octave. It just gives you variation of tailored limited means that you have unique constraints, limited to your organization size. And one more variation of Octave, which is like Octave is, which is used for the teams less than 100 people and having a threat modeling function of only just three to five people. This strike strike is mostly works with in reference with ERM and what ERM is enter ERM is enterprise risk management. So it mainly works as a risk management tool within this framework that models are used to satisfy the security auditing process. The threat models are based on requirement model and the requirement model established the stakeholder defined acceptable level of risk. Now what this acceptable level is, we'll talk about it later when we will be talking about risk acceptance and installments. The analysis of these requirement model is a threat model from which sets are enumerated and assigned a particular risk values, which ties to the businesses. Then third stride stride is quite popular, and it's mostly a developer focused at modeling technique stride stands for spoofing, tampering, repudiation, information disclosure or denial of service and escalation of privileges. So it is just a model of threats used to help reason and find threats to a system. It is used in conjunction with a model of target system that can be constructed in parallel. Like, like other threat modeling models stride do not works as a works only in ideation phase or just at the end cycle, but stride is like stride is applicable during the whole product life cycle. Like at every step you can think what we are building, what processes we have but data stores we have what data flows we have and how we are creating the cross boundaries between these, all these data sources. Today it is often used by security experts to help answer a simple question, what can go wrong in the system we are working on. Then we have pasta, pasta is basically a process for attack simulation threat analysis. It's a seven step risk centric methodology just like strike. It also works on to risk management thingy, but like it measures business impacts more from the attacker's point of view. The intent of this method is to provide a dynamic threat identification, enumeration and scoring process. Once the threat model is completed, security engineers can develop a detailed analysis of the identified threats. Finally, the security controls can be enumerated again, the methodologies intended to provide an attacker centric view of the application. So that's all about frameworks. Now why we are thinking so much about threats? No one likes threats, no one does. But we cannot protect against anything we do not know about. So we need to know threats if we want to defend ourselves from those threats. So basically threat modeling helps us to have a mitigation strategy and techniques based on the identified and documented threats. You basically identify and address the greatest risk, you prioritize threats, which threats you can assert, which threats you can circumvent with another technology. You increase the risk awareness in your organization. Then you basically, once you have threats and once you know how, how your risk exposure looks like, you benefit from cost justification and support for needed controls. You can use artifacts to document due diligence for each software project, each infrastructure project, any kind of project you have in your organization. Then some examples like how threats look like basically and like we will be talking about examples only in the text of stride, because otherwise it will be a lot of examples if we start picking every framework. So stride, as I said, stride stands for spoofing, tampering, repudiation, information disclosure, DOS and elevation of privileges. Like every, every keyword in stride impacts a particular parameter of paradigm of information security. So spoofing impacts authenticity, tampering impacts integrity, repudiation causes non-repudability, information disclosure is breach of confidentiality, DOS is breach of, like there is no availability and elevation of privileges, breach of authorization. So what is spoofing? Spoofing is basically illegal access and using that access to have, have information which one or not supposed to have. The basic example can be cookie hijacking, like for example, if you have an application in your organization where you can, if you reuse cookie of another user, then you can basically log in into the account if there is no 2FNM. So, so that's a spoofing fit from that particular application. Then we come to tampering, tampering is more about integrity and like example can include unauthorized changes made to a persistent data, such as that held in some database and alteration of data, or maybe alteration of data when data isn't flow from an open network to a computer like man in a middle attack, you intercept thing and you manipulate it to a proxy. Then we have repudiation. Repudiation gets a bit complicated, like repudiation is associated when you cannot, repudiation can be, can cause non-repudiation, which is like when you cannot backtrack the actions of a user, backtrack malicious actions to a user. For example, if you have an application in your organization, which can only have single admin, and you have three system administrator, and what they're basically doing are they are using single set of credentials between three of them. If one of them poses, like is the insider set to the organization and they do some malicious action, you cannot use the audit logs of that application to backtrack the activity of the malicious user because all three users are using the same set of credentials. So when there's a non-repudiation, logs becomes useless. So it is considered as a risk. And then there's information disclosure. Information disclosure is just breach of information which should not be exposed. And it can be accidental share of files externally, like if some files are confidential to your organization and they get shared by human error or by insider set outside the organization, then basically it's an information disclosure. In some cases you can reduce human error factor, for example, if you have shared drives in your company and human error can happen that one user accidentally shares your confidential data with someone external to just a single click. You can enforce controls that like you can have DLP policies on your shared drives that you can restrict external use, external share at all. So even if they make that error, it won't happen. Then there's denial of service. Denial of service is basically denying the service to valid users. For example, making a web server temporary, unavailable or unusable. So we have elevation of privilege and unprivileged user gains that privilege access and then compromise the security or destroy the entire infrastructure. So yesterday I was having an interesting discussion with a friend about elevation of privilege that if if we have a project in an etiquette management tool. And if we want to restrict that project from admin of that particular tool, then it's it's nearly possible because admin can always give themselves privilege to have access to that project. It's an issue. Then when to now we know what is that modeling, how to do that modeling now when to do that modeling. Mainly that modeling is done as a top to bottom exercise, then certain benchmark service. For example, if you have plan, if you have plans of launching new set of features. If you have been developing new features, or you have like your acquiring some companies. So maybe you want to hit model the coming entity, or you might be having a compliance requirement. Or you might be needing a regulatory approval so that modeling matters because it gives you the risk score of a company which ties back to which ties back to finances of the company. And like when the one use case which I always think is like if a engineering team is if an engineering team face some incident and they're doing root cause analysis. Then they, they can do that modeling during during our CS as well, because even when the root causes of more pedestrian nature performing a root cause analysis can get the right people thinking about potential fits. They may have ignored previously or they never considered them, or maybe by patching that particular vulnerability, they might propose new dependency which may introduce unexpected security issues. And otherwise in my opinion that modeling perspective should be the way of life for every security engineer or like engineering team, as it promote security by design from every aspect. A day comes when you don't have to do that modeling exercise anymore because you are designing everything from the third modeling perspective you are thinking security before doing things. And it is applicable from application to infrastructure infrastructure to your physical even physical security. So now when not to do that modeling we just said that we should do that modeling by default but then not to do it. Basically, I can think of only one thing when not to do it when you have plenty of things in your environment. And those things are critical you cannot just ignore them and find more fire hazards in your organization as once our vice men said that you don't go and look for more fire hazards when your house is already on fire. Don't overwhelm your engineering team so they stop caring about the threats. And once you find the opposite, it is a mirror of security gaps but cyber threat is mainly a reflection of our weaknesses. Then my dad, my dad is a great third modeler. And that's a good thing. But what he's doing wrong. He's doing this. He's making the same mistake but almost every security engineering team makes, which is third modeling. Being good at modeling is one thing and dealing with the outcomes of it is another. So if you're doing that modeling, you're getting reports. How are you dealing with the results? Are you becoming overwhelmed? Are they becoming overwhelming to you or like what's happening? So basically two wrong things happen. Usually when you deal with the third modeling reports, first is either security teams becomes too paranoid or engineering teams stop caring at all about them. And those are like usual cases and they happen in lots of organizations, why they happen. Mainly security engineers when get too paranoid, they become a bottleneck for every processor, everything coming. So we can start with risk acceptance. What is risk acceptance? So risk acceptance is like amount of risk your organization is willing to accept and just after it is like capacity of risk, they can like diverse kind of risk your organization can accept to achieve its business objectives. Organizations basically recognize that they cannot remove all risk from the business. And like we exist in world full of risk and for achieving our business goals, we need to require accept some risk and mitigate them or either transfer them. We can have, we can have compensating controls around the threats to reduce the threat and have then residual threats, which is like off lesser risk factor. And then what is this tolerance? This tolerance is the amount of acceptable deviation from an organization's risk appetite. By risk appetite is a broad and like strategic term. This tolerance is much more of a tactical concept that identifies the risk associated with a specific initiative or a specific project. By risk appetite is organization's appetite and this tolerance various project to project. One way to understand the solution is I was reading an article by Tech Target and they presented it like where for example, when driving, driving at very high speed on government roads is like, is a high risk for the driver and to all the other drivers on the road as well and government creates speed limits designed to control the system. The faster a car drives, the more risk is created. So the lower the speed limit, the lower the degree of overall risk to the every driver on the road. However, lower speed limits, lower limits also inhibits the flow of traffic preventing vehicles from quickly reaching their destinations. Governments balance these concerns and determine the appropriate rate of speed, which is like government's risk appetite. Like how much risk they are willing to take to strike the balance between risk and fit. Then fun part, how I built a fit modeling function with just three people, including me and our team. And like it's totally doable just just give them a perspective just make them think and just make them think how things can go wrong and tell them to spread that mindset. Like when I started in the organization we were just three people, loads of features in product were coming, we were reinventing infrastructure we were migrating to different technologies. Hence that modeling was needed everywhere we were waiting on regulatory approval we were waiting on compliance requirements. We be hard to do that modeling at every every step and there were so many line land mines in between. So in my experience frameworks are good for for to give you a mountain site of perspective when you are new to that modeling. But with time you develop it like frameworks becomes a bit hard to scale up or become a bit complicated for a big organization. And it's it's sometimes hard to go by the book all the time. So you can have your own framework and you can decide how you want to measure the thread and link it to the response. Then once you are proficient at it modeling that you pass on that mindset to every team then every team, every engineering team learns to set model of what's coming and even gets better as they understand the product more than you. They understand the infrastructure better than you as they're working on infrastructure all the time, and they see the gaps just better than you. Like I've been on calls where I used to do that modeling and now those developers or those infrastructure engineers are doing that modeling way better than me because they understand how it is working. I have to first understand the technology to find to highlight the test, but they already know how it's how it's working in detail. They just need that mindset to look into things what what can go wrong and imagine every worst case scenario. And as I always say that that modeling is more than just an exercise. It's a mind mindset or a philosophy. I'll conclude my slides with like thanking to Max and who helped me bring storming ideas and curating a raw idea about the third modeling and like supporting me into building the whole function in just with just three people. So any questions, you can always find me at Twitter and discord and I'm quite active there and always open for chat. Thank you.