 Can I put it here? Great. We'll be starting in one minute, counting down 60, 59. So last time I checked, I don't think I acknowledged or know anybody of you, so I'm not going to skip the first part kind of introduction myself. OK, we'll be starting now. Good afternoon. So it's my pleasure to be here today. The topic of today is an agile approach to thread modeling for securing Ajax Foundry. In this talk, I'm going to share some knowledge and lessons we learned during our journey of Ajax Foundry development. So before we start our session officially, please allow me introduce myself. Of course, my name here, King Yuzung. I'm working based out of Raleigh, North Carolina, or specifically Research Triangle Park, if you are familiar with the area. As a security architect in the IoT platform division of the Dell technology, I've been involved into a couple of open source as well as commercial products. In the open source project Ajax, I'm one of the major code contributors for the security component. And currently a co-chair of security working group. Before taking the position in Dell, I was a principal engineer in RSA security where I got involved into a couple of security products, including data loss prevention, or thread detection, and response. OK, after wasting about one minute of you guys, so let's go back to the business. This is today's session agenda. We will start with the first question, what is Ajax? The answer will be covered in the section one. Just like every open source project, the Ajax is facing all kinds of challenges here. So in section two, we are trying to just go over the security challenge we have. To address the challenges, we'd better to invest the tools that work. Thread modeling is one of the kind. So in section three, we are going to cover the thread modeling. Like what is thread modeling? What can we do with thread modeling? How can we perform thread modeling? So after section three, we have some ideas about thread modeling. We are going to use Ajax example. And trying to apply the background information knowledge we learned from the section three into the Ajax project to address the challenges we have. OK, this is section one about Ajax Foundry introduction. So we are going to answer the questions like what is Ajax and why we developed Ajax and what are the principles we are trying to follow during our designing and implementation of Ajax and how Ajax works. It is vital, important to understand the background information here before we bring the security into the table. OK, Ajax Foundry, where we call the Ajax most of the time, is open source, vendor neutral project. In Ajax, we are trying to build a framework that provides the interoperability and compatibility for the Ajax computing. So it is a platform independent. Means it supports both x86 and ARM architecture. And it works on Windows, Linux, or Mac, if you like. And it supports the customized plugin module. Those modules could be written with different languages. We support them through the common REST APIs from the framework. So the motivations behind the Ajax framework in today's IoT world, it is very noticeable that there are so many platforms available. It could be good or it could be bad. Depends on your viewpoints. So Ajax is trying to get into the place where we build and promote a common framework unifying Ajax computing. So it encourages the community to create ecosystem of plug and play. So any part of the platform could be replaced, could be upgraded, or it allows the security, the service to scale up and down based on the security, the services, capacity, and user cases. And it's very helpful to provide the tools to create Ajax-based IoT Edge solution quickly. So in the same time, collaborations between the open source projects and the standard group will benefit the industry as well. So as we see here, that is the high-level architecture of the Ajax. In the center of the architecture, we have the core service. So this mark is the grid. The dark area, those are required components that serve the foundation of the system. So it includes core data, command, metadata, registration, and configuration service. On top of the components, we are having replaceable or reference service, such as the scheduling, alert, notification, and the distribution service. So these are loosely separated. And we are trying to define the northbound and the southbound over here. The northbound here refers to the cloud side mainly, either the public or in-house. The southbound of the Ajax, that is, we are the devices, sensors, meters, thermostats, rest. System management and security are the service kind of cross-bounds, as we see here on both sides. And these are considered as a part of the underlying infrastructure. How the Ajax works currently. So Ajax is composed of a dozen of microservices. Mostly are written with Go language, with a very small portion implemented with the script currently. So each microservice is responsible for a single feature of the system, such as a sensor data collection or data persistence, data exporting, system scheduling, et cetera. So the microservice communicates which is other through the address API interface. That's providing the maximum flexibility over here. The Ajax can be deployed through the Docker or Docker compose file, or snap distribution, which is another container system, if you like. And even the Ajax can be run over the native system. If you would like, just kind of a binary will build out of those source code. Okay, so this is the agenda for this section two. So every project has a challenges, and every project has its reward. In section two, we are going to discuss the challenges in the Ajax project. So focusing on security part. Of course, this is probably a major topic here. So Ajax roots in the IoT field. So it faces a similar challenges as other IoT projects. Ajax is open source project as well. So it has similar challenges as other open source projects. So we are in need of a strategy and track approach to respond to the challenges over here. So the power of the IoT device is improving rapidly in the past year. What could be done with the big bulky system in the past can be implemented into a very tiny chip right now. However, compared with the computers or other device, it still has very limited storage or processing power. And not like the PC or mic. Update of software could be just a click away here to upgrade an IoT device. Sometimes it requires multiple steps or even physical access. Authentication, authorization and secure communication are big issues in IoT as well. So taking example of the smart thermostats that send the data and receive the commands to change the temperature setting remotely. How could we just know the reading are authentic and the command to change the temperature is not from malicious users? And how we make sure the data reading would be stolen by some other unauthorized users. Those are questions we have to face and we have to answer. Security challenge exists in the open source project as well. This code base available for all the public. So we wish anybody who is interested can just step up and do the code review trying to catch the defects before adopting that. However, unfortunately, this is not the case all the time. And it is challenging to review the code base and identify the security issues in a short term without help. So nowadays it is almost impossible to find a software that doesn't depend on the third party modules. These modules bring potential security risks as well. And like any software development, a switching hands of the developers in the open source project is available and the design could be changed later as well. The security loopholes could be introduced around the same time. So to address those security challenges mentioned above, we introduce a threat modeling into our project. So threat represents a potential danger to something value in the system. The modeling is just a procedure to identify these value resources, recognize a potential tax against the resource, plan and implement some sorts of methods to reduce or remove the dangers. For the contributors of open source project, it provides guidance on security compliance. For the end user, it helps understanding what and where the potential attacks might happen. Instead of a band-aid style security plaques, it provides a progressive and practical approach to enhance the security of the project. So this is the section three we are going to cover. As we mentioned previously, threat modeling provides so many benefits for a project. So the next question that comes out is, how do we do it? In section three, we are going to find out the formal definition of threat modeling and when is the time to do that and who can do that or how can we do that? So here's the definition of a threat model and threat modeling from the open web application security project OS dot org. As we can see here, threat model is defined as a structured representation of all the information that affects security of application. The threat modeling here is a process of capturing, organizing and analyzing all the information and it enables the decision making about the risks. The output of threat modeling is a prioritized list of security improvements to the concepts, requirements, designs, or implementations. Basically it covers the whole scope of the software development. When should we start threat modeling? So just like the software development, the best time to start threat modeling is before we write the first line of the code here. It is time to recognize the risks and build the solutions into the system and it's cost efficient to make changes easily. However, it is not realistic for a lot of projects currently. So with agile development, whether adopted, it is a good idea to have the threat modeling at the start of each sprint to make sure the proposed new features are not introduced in the potential risks. At each milestone release of the project, having threat modeling with product roadmap will display much clear picture of the product and gaining as confidence on the security improvement. So in nutshell, performing the threat modeling when the system has changed, if you can. So who can do that? While there may be understanding, there might be a misunderstanding here that we have to have a security expert to the threat modeling. This is not true. So think about who is the best person to understand the product or the module in your team. The person could be in your team already. It is not very difficult to perform a threat modeling as long as the proper procedure is followed. So the goal would be far away and reachable. What if the project includes millions of lines called and too big to handle that happens all the time as well? So start from a smaller module, applying the threat modeling approach and expanding the coverage. So you will reach our goal sooner than you think. Okay. Let's go to the steps for the threat modeling here. The first type of threat modeling is to understand the system architecture and create a model that reflects the architecture and trying to bring down the smaller piece. So this type can be iterated further until each piece contains a small single feature. It is okay to have some abstracts for hiding the details so that it can be viewed as a whole during the one iteration. Next step, we utilize data flow diagram or whatever data flow graph you like to expose interaction between those components. So this is where we draw the trust boundary. With the trust boundary of the component, the communication is considered safe and reliable. Another important factor to be identified in the step here is called asset. So this is something we are trying to protect and attack from my interest at least. Having those information in mind, so we can move to the next step, which is identifying the potential attacks. Okay. Probably quite a few people already seen those triangle before that represents confidentiality, integrity, availability, or as known as CIA tried. So these are top three fundamental property of security in the threat model. So the confidentiality ensures the information can only be accessed by authorized individuals. Integrity ensures that the information is authentic and reliable. And availability means the resource accessible to meet a business need. In threat modeling, that's one more thing we have to think about. That's called non-repudiation, which means someone cannot deny something he has done. A good example would be data signature. A lot of people have been using that, which means your digital signature can only be used by the individual who send it. Okay, so taking those security factors and think from the opposite direction means how these properties could be violated. Then we have one of the most matured classification tech model here, Stride. Stand for spoofing, tempering, repudiation, information disclosure, denial of service and elevation of the privilege. This was promotes by Microsoft about data's goal and it was widely accepted as one of the practical methods of threat modeling. Because it answers very basic question, but very important question, how will my system be attacked by the hackers? Spoofing means an individual could pretend to be someone else other than himself. Tempering means an individual could modify something and the repudiation means an individual could deny what he did. Information disclosure means providing information to an unauthorized individual. The denial of the service means absorbing the resource so that the service is available for legit users. The elevation of the privilege means an individual in a lower privilege group could access the resource that are available for the higher privilege group user only. Once we identify those trust boundaries of the component, a set of need to be protect and the strike model, a strike threat, we are moving to the next step. That means we are trying to mapping these threats against the components. Let's imagine a user case that a module reveals temperature reading over a port and store the data onto the disk. The data will be our asset to be protected and the trust boundary is identified as a port. So based on the strike attack model we discussed before, is proofing possible? Yes, anyone can send data over the interface. Is tampering possible? Yes, the data could be modified before arriving at the port. How about a non-repudiation? Is it possible? As well, because owner of the device could claim, oh, we didn't send out the data reading at all. Information disclosure? Yes, of course. The reading data belonging to one device could be obtained by another un-threat user as well. And how about the denial of stories? It is possible. Because millions of requests can be sent to the port to use up all the resource over there. And how about the last one, the elevation of the privilege? Yes, the data could be constructed in a way that is to be used to change the user's group. Here we are recognizing all the potential attacks from multiple viewpoints. And next time we are trying to just reduce or just remove those threads. For reduce or remove the threads, we call that thread mitigation. So this is the stage of the thread mitigation as we displayed here. And if the threads are exposed during the design stage, which is pretty good, and we have the great chance to update the system design, adding the security enhancement or improvement over here, if they are exposed during the milestone release, which happens as well, it is good approach to include such information and possible solution in the project roadmap so that the user developer understand what we are going to address regarding security next step. So if a solution is not available, where the risk is considered very low, so it is not uncommon to accept and document the risk. And the last resort, probably not pretty, just transfer the risk without fixing it. This looks like city, whatever. However, if you read a lot of the term, service or license agreement of the software, you will find out, they do that way. Okay, this is our section four. We already understand what is thread modeling, what is thread model and what steps. So we are going to just use our project adjunct as an example to see how we are going to apply them. So this is a common practice. We can use that for any project if you like. When we go back to the high-level architecture of the adjuncts, so we learn from the top most level, as you can see. So this is kind of what they were divided into a different categories and loosely divided as the southbound and northbound over here. On the southbound over here, the sensor data is collected by the device service from the thing. And it is a place where adjunct interacts with outside world. So we define as trust boundary over here. The trust boundary is identified on the south side. On the north side, that is, we are connecting with the enterprise or cloud system. So which is another place where interaction with outside world of the adjuncts happens. So this will be another trust boundary we are defining. So in this level, our site are the rest API and points that could be consumed by the external entities. And those are the resource we are exposing to outside world. And those are the resource we are trying to protect in this level. When applying the strike model, we mentioned in the previous section on the site over here, we have the attack tables. As we can see here, we have assets we are trying to protect on this level and we have the threat against them and we have possible method of such threat. And even we have a severity level associated with those information. Those table gives us a clear and trackable list about what we are going to start regarding the security improvement of the adjuncts. Taking example of the table over here, we have a device rest API. The threat is spoofing and the method here is the attacker sends the data with a fake identification of the IoT. And we think, okay, this is severity is high, which we need to just address or just fix it. And the same device service rest API and it's facing the threat of information disclosure. One of possible method for information disclosure is manage the middle attack and the severity is high as well. And that's what we are going to protect. By following these steps, you are identifying the assets, you are identifying the threats of possible methods severity and the next step, let's just try to fix them. Once the threats are recognized, it is time to reduce or remove them. In the architecture level, we decide to adopt various technologies for the mitigation. So for example, in our projects, the rest API endpoints need to be protected. So we utilize API gateway to reduce attacking surface. A metering mechanism can be implemented in the API gateway to prevent the denial of service attack. And we implement the JSON web token, JWT, as well as all authentication with API gateway to mitigate the threat of spooving. Such steps can be performed in the next level of the smaller components. So let's go back to this architecture diagram here. We notice the dark side, again, that is the core service and the service around them are optional. The data is passed to the core service from the local persistence and the commands are passed over the core service for device and meters. So when we draw the trust boundary around the core service, we are identifying a new attacking surface and new assets. So for example, here in this level, we notice some microservice need a credential to access the database. So these credentials become the new assets we are trying to protect. And applying the threat model, and we are learning what kind of attacks may happen and what mitigations we need to adopt. So this approach can be applied repeatedly to the lowest model of the system to maximize the benefit of the threat modeling. With such least threats and mitigation strategies, the security is no more a hassle but a manageable and trackable approach. So in conclusion, with your threat modeling helps the team understanding and evaluate the security threats and the solutions quickly. And it is a practical approach to expose threat in different stage of development. So threat modeling is adapted in different level of the scope of the open source Ajax. We encourage every team to try on threat modeling and share the result with the community. At the end of the presentation, this is the least of the reference regarding threat modeling as well as Ajax Foundry. And these include books, technical talks, and links. More details of threat modeling can be found over there. And here we are just open the QA session, please. Can I just repeat the question a little bit? Yeah, so basically, we're assuming you're interacting in the larger world, what's the practical... Okay, so his question is what kind of a guideline we are finding where we feel that's helpful for those connecting between the Ajax and other device, probably northbound device or southbound device, right? So that's... Or some kind of horizontal. Yeah, horizontal is another topic as well. So the approach we are trying to get here is we are trying to just reduce the connections of the Ajax here. If you have an open model over there connecting from all around the world, so it's very difficult to detect. So in security means you'll have an open attacking surface which is not good at all. So one of the approaches we have here is just trying to reduce the attacking surface. And we open very limited port from Ajax. As you can see, we are opening quite a few REST APIs. That is either for the northbound side, but the southbound side, you'll see, they have different MQTTE or zero MQO, all kinds of connections. So in the Ajax, what we are doing here is we are trying to have a device service. So the device service is a single point to connect all those things. And if we decide the security trust boundary inside Ajax, that is another layer of the security trust boundary we connect, we are trying to define between the device service and the core part. We are trying to protect over there. If you define the trust boundary outside the Ajax, which is outside the device service, so you are facing all kinds of protocols MQTTE, zero MQO, and basically that's the problem, that's probably you have to kind of analyze the device and make sure those connections are protected. For MQTTE, you have those password credentials or for others you probably have applied the SSL or GLS. So basically that's the approach we are doing here. This, mm-hmm, yep. Okay, so this is probably a bigger topic we are not gonna cover here. Lynx Foundation has a project called A-Edge. So I'm not sure if you're familiar with that part. The Ajax part of the edge, the edge project starts at the beginning of this year starting from January to address those unifying the platforms where the kind of what you describe here as a far and edge, those smart device stuff. So Ajax here is serving as a center part of the framework. What you are describing kind of little bit of far and we have other project to address it. So think this as kind of our gateway to connecting all the information here. And there's other products trying to just intercept the traffic inside the Ajax. So they are analyzing the data as you describe just now. Those smart things, the traffic, they might be heavy but on their side the computing power is really, it's weak. So we cannot rely on them to just kind of detect attack. So instead we have to just kind of push a little bit higher on the Ajax side to just detect those malicious behaviors to detect attacks. So every project has a scope. So for the Ajax foundry is in the center as kind of a gateway part. So on the other side, I would say right now we are not going to cover that. We can just detect that. We can just tell probably and use the, okay, there are some malicious behavior on your IoT device side, but probably that's it. That's the scope for the Ajax foundry currently. I think if you're talking about the data center of the cloud side, the target side is kind of the local. It's not on the north side. So what you are describing the TVC part as I described back to the scope here on the north side. So we have an interface. It's called export service. Those are the place you're connecting with your cloud, with your maybe in-house data warehouse. And for this part, Dell has a hardware Dell gateway. So this one sits over there. Of course you can install this on different gateway system, not necessarily Dell or probably from Cisco for others. So this is not as powerful as the cloud side but it's not as weak as the far end of the edge. So it's set in the middle. So think that like described just now, think that as a gateway or half. So this is the kind of a deployment scope. I hope that answered your question. Okay, sure, no problem. Yeah. Mm-hmm. But this will be a variety of different examples. Okay. I think there's a one deployment scope, which is, you are describing here for the Ajax, means you're probably running multiple Ajax box, currently and they are connecting with each other and they are changing data, things like that, right? So I think this is something we are going to address during our next release. So we have the Ajax 1.0 release June of 2019 for the next roadmap. I think it's in coming October. Probably we can find more information over there. So the roadmap and the architecture and that's open to public. We are on the, let me just go back here. The last part that is a weekly page. So we can find there and we have the working group meeting weekly. So anybody is open to join. So I think the questions you have here could be answered there as well. Thank you. Sure. No more questions? Okay, thank you very much.