 So good morning. Good afternoon. Good evening depending on where you are. I hope you can hear me loud and clear Thanks for having me here. It's a delight to be here at open source summit once again This is my second time at open source summit after that happened in Shanghai last year Unfortunately due to COVID-19 all of the talks this year are virtual And I hope many of you would have you know taken this as an opportunity to attend as many talks as possible And I'm really glad that it could join into my talk. I'll be talking about IOT developer's guide to building a secure IOT devices so But before we begin a quick introduction about me I'm your guest and I'm from Nepal. I work for a company called Tata Consentancy Service India Where my primary research and work focus in IOT security hardware hacking and mobile application security? Apart from that, I'm passionate about car hacking and robotics as well When I'm not working on security, I'm probably building robots for fun. I'm also an active speaker in the community I've spoken in front of several conferences like cyber week a great hack and Kazakhstan mainly and security I sometimes write in medium as well. So you can find me in medium as medium.com slash at Yogis Oza So that's pretty much about me. Let's look into today's agenda We'll begin with introduction to IOT a boot spaces failure stories which we followed by current security challenges in IOT After that, we'll talk about threat modeling where threat modeling is very important for developers and how to build one of them The other topic where I'll spend a lot of time talking about is the wasp top 10 vulnerabilities If I'm not aware of what wasp is it's a nonprofit organization that releases the top 10 vulnerabilities that has been observed in the last couple of years They do release this document for developers and security guys and you can have a look at them Probably you can use it to train your developers about the security issues as well We'll also talk about the best practices in terms of security towards the end of this talk We have a lot to cover today a lot of material to cover today So let's quickly dive into the talk and see what's going on with IOT security So the goal of this talk the talk is intended for developers to help them understand the security issues Within the IOTM and this talk is probably you know after this talk probably It'll help you implement the security in your IOT SDLC as well But before we you know begin the into the dive deep into the world of IOT security I think it's better. We talk a little about Internet of Things So the Internet of Things is basically the network of physical objects Device building vehicles and other embedded electronics and sensors that enable this object to interact with each other Extends data and make smart decisions based on the data that has been gathered from the environment Also an IOT could be any device connected to internet irrespective of Computation power price and the size of device So what you see on the screen is the schematic of Internet of Things on a high level if you look at the schematic of Internet of Things it consists of a hardware or software and a cloud The hardware may consist of sensors your processing unit embedded CPU or a microcontroller and storage We now have software now this software might contain the firmware mobile application and the web application Depending on what your IOT device does with it This may have network communication as well with most of the times it's a bidirectional communication And a device may interact with other other little components using protocols like blade with low energy or ZigBee as well So now now let's look into the IOT architecture component And if you look at the IOT at a broad range the hardware that we spoke about the software that This device is carrying and the application can be aggregated into a layered architecture This is very important to know because when we talk about the security issues Understanding the architecture will help you correlate the common pitfalls of IOT within the layers And they could be solved within the layers as well So you could find many architectures for IOT this varies from company to company people to people and many Based on the requirements many of the architectures are based on one common architecture And that is divided into physical device is and the platform Physical device could be anything that could be identified as things in the Internet of Things This physical device also have some computing power that and and the chances are that it is directly attached to actuators or controllers Depending on customers demands and capabilities the processing power and connectivity may vary Then we have is with consist of sensors and actuators and at last we have platform Which is the centralized component that manages the flow of data This also in a broad term can be classified into application layer data processing layer Network layer and sensing layer on a normal iot device. Let's take an example of a fitness tracker The mobile app so the mobile application in your android ios that you use is in the application layer the data processing layer consists of a CPU That calculates your daily activities your fitness performance and and does the analysis on top of that, right? So on a network layer you could have seven protocols like a bledged low energy Bledged classic or mqtt running on top of that So the remaining components like the pedometer the sensor the gps are in the sensing layer So this probably would have given you a brief idea about uh, you know Uh about the architecture next we look into the evidence cases and come on pitfalls for iod device So now if you if you look at this now you've got this smart If you talk about the things in the internet of things you have got everything out there You have your smart coffee makers. You have got a door locks even smart guns fitness trackers and many more You also have the healthy devices as well One common thing between all of these devices are that they all have connectivity They all have a tiny little cpu and sensors that work together to perform some action The other really common thing between all of these devices are that they're poorly designed with no security in mind They all have history of being hacked They there are many reasons where these devices are poorly designed with no security in mind Which of course we're going to discuss about it later today Uh, now let's talk about the iot failure stories Uh, if you if you remember the things in the internet of things We have had the variable implants that the healthy devices, right? They're also known as pacemakers They're used for people that have slow heart rhythm This was found to have weakness in the transmitter allowing potency need to Change the pace battery depletion and even suck in other words that it was there The other the other fairly iot failure story that cannot go unnoticed is that uh In the mirai boat made back then in 2016 This was probably the biggest distributed denial of service that ever happened And just to make things even more interesting for you. Um, uh, there was one case back then in 2018 This among uh, this is one among many cases where the vulnerable iot devices Were used to compromise or you know target the companies for the very first time This is a very interesting case back in 2018 where the attackers used a thermostat that was connected into a feast tank Um, that was placed in the lobby of a casino to gain access to the casino's high roller data mix And and these kind of attacks keep happening. One of the major problems with iot is that they are very basic and cheap Various reasons like the time to market the cost and many other reasons these devices like the thermostat The refrigeration the smart bulbs and several other smart home components. They often do not include the added security And as we keep on to add up more and more iot devices We are just increasing the attack surface And what it is true that many people are working on to secure these devices But still we are a long way off from having the secure iot devices As we move on to integrate more and more devices move more We as we move into more and more connected future. We need to understand the root cause Are we trading off the security for the sake of convenience or not? The very common pattern when I work with customers we tend to identify the root cause And and and this root cause belongs to developers and the vendors The consumer in an industry is always looking for secure iot devices without trading of their convenience Well, on the other hand developers and vendors are worried about their complexity Many times developers are not aware of security issues The vendor are not aware what to do next when something wrong happens Or even what can be done to achieve security without complexity These are constantly they are constantly looking for suppliers That can provide them devices and hardware at a level of assurance that they can bring in security without complexity A root of trust has to be established between all the parties and entities Also security must be considered early in the design phase early in the marketing and engineering development cycles of devices As well as services. This is because when I'm talking about iot I'm not just talking about the tiny little hardware box rather. I'm talking about the entire ecosystem The entire mobile application the the mobile application communicates to the the web interface the administrative administrative console and a lot of components inside your ecosystem The web application dashboard the tiny little sensor attached to it and a whole lot in the ecosystem, right? So it is very cheap for developers and for companies and vendors to Identify and mitigate the issues early at the design phase rather than after the production So the current situation, uh, if you look at the current situation of iot, it's it's a little worrisome The security is actually missing from iot, which I really believe should never have happened should never be the case I do not see any fundamental or groundbreaking reasons why security should never be a part of iot Somewhere down the line I feel that security and iot has been discarded by developers for the sake of convenience and on the vendor This has been discarded for the sake of early time to market Currently the competition on market is is is for early time to market Is for is for early time to market competition on safe and size And dimensions right but not really on security That currently millions of connected devices and billions of sensors Surprisingly the numbers are growing rapidly and all of them needs to be secured Hence it is important that a well-designed security iot architecture are most requirement And if you have been looking at the attack vectors where the threat actors have been attacking it's everywhere They have been attacking a device gateways the firmware or the operating system the software even even on the software system and many more So a vendor can't just secure a hardware device and call themselves a secure We need to check on the gateways the sensors the firewall that they have implemented the mobile application The operating system the software system and many more So vendor So and and and if you look at the current situation as I said it's a little worrisome But there is a lot to act and there are a lot of challenges as well I think we have had enough of problems in iot. Let's focus in the current security challenges and and and look at the ways to solve them By now you must be already asking. Hey, there are billions of devices But what is the problem where all this began right when I work with vendors and companies One of the major problem that I have seen with companies and vendors is that People and companies think that iot security is all about device security Still many people think security in iot means securing the physical device Which is not true When we're talking about security in iot it is all about securing the entire ecosystem Your ecosystem includes you as I said it includes your mobile application your cloud communication your device device communication Your web application and various other component if any of these components are insecure This may lead to the compromise of the entire ecosystem and not just a physical iot device So next time you hear somebody saying iot security is all about physical security You need to correct them then and then And developers need to focus and secure securing the entire ecosystem rather than the device alone The other problem is that the dependency issues You so what what happens is that your one vendor may rely on the several other vendors It is pretty tough for one single vendor to build the entire ecosystem So they might rely on the several other vendors It might so happen that your mobile application might be procured from one vendor And the hardware components might be procured from another summer in china right and the vendor summer in china The next question that arises is that how secure are those vendors? Do you have any controls over then do you have any idea where your customer's data is being sent? If the answer to this question is yes, then you might be doing a great job in securing your iot ecosystem But what if one of these components is not in your control? This is where things get serious and and this actually I think it creates a major problem The other problem that I've seen in the industry is that the never-ending growth So the number of devices the number of component keeps growing at an exponential rate IOT technologies are not match your yield and there are many challenges to overcome There is no way we can control the growth of these devices And I don't think we should be as the number of devices continue to grow There is a lot of attack surface as we keep on to integrate more and more senses as we continue to integrate more and more Interfaces we are increasing the attack surface And also as I spoke about the dependency issues. What is the vulnerability lies in the third party vendors hardware? And the vendor has no way to provide the pads How are you going to handle this? And and these are the kind of questions that are developer must always be prepared before building and secure Uh building an architecture for your secure iot system The other problem that I've seen in the industry is that there is too much a cross between all the components So what what happens is that the solution to this is implementing the zero trust philosophy? So implementing a zero trust philosophy in iot network could be an essential step in securing the entire ecosystem So where this is important? So what happens is that in a traditional architecture, uh, the traditional architecture believes that even if you compromise any components in the network Rest of the component will treat you as a granted Since you have already since you are already inside the network you remain to be authenticated, right? So rather a zero trust philosophy implements much strong authentication and requires strict verification Even if one of the component or the device in the ecosystem gets compromised What this does is that this prevents the lateral movement inside the network Even if the even if your iot device gets compromised So like the one early in the 2018 case of casino Had it been a zero trust inside the network the attacker wouldn't be able to gain lateral movement inside the network, right? So we have spoken a lot about challenges. We have spoken a lot about the problems Let's let's try to focus on the trial and and the ways to solve it. So, uh Those are the pretty much challenges in iot security and of course there are plenty of them We're not going to discuss all of them, but you can consider them as a primary challenges Now to understand threats much better in their counter measures We'll first look into the threats correlate them with the cia trial and focus on each of the counter measures So on a typical iot device common security threats are unauthorized access physical physical destruction information decays Illegal data modification denial of service attack malware based attack and and this can pretty much be correlated to cia trial so If you're wondering what cia trial is it's a fundamental to information security So so what happens is anytime your data is leaked Okay, anytime a system is attacked or any any number of other security incident occurred You can be certain that one or more of these principles have been violated So we evaluate threats and vulnerabilities based on the potential impact They happen the confidentiality integrity and the availability and based on the potential based on the evaluation We propose a set of security controls to reduce the risk So let's let's quickly focus on each of these security requirements and let's have a look at them So we'll begin with confidentiality. So confidentiality is a property roughly It's related to privacy Any attack and data at first data in process and data in transit could could occur in loss of confidentiality Some some common attack that could hamper the c in the confidentiality is that the man in the middle attack and the replay attacks and the security requirement For preserving the confidentiality in the iot device is that the transmitted masses should be encrypted to prevent the man in the middle Snapping or eaps dropping Similarly, the other counter measure could be taken to preserve the confidentiality is that the device should be tamper resistant The requirement tamper resistant is put up because the sensitive data that developers show inside the hardware chips Also detection and defense against the malware based attack are also important for preserving the confidentiality Now we have now the other thing that we have got is integrity Integrity is a property that maintains the consistency, accuracy and trustworthiness of data over the life cycle One one simple requirement to put up is that the data in transit must not be modified This in terms of iot can be simply put up as applying data integrity verification to avoid the data forageries, right? So similarly for former abuse developer must cryptographically take the former integrity before Obviding the former or applying the pads This ensures that the developer has actually built and developed the former and no modification has been done on the former otherwise Similarly other attack on operating systems like modification of system configuration to gain privilege escalation and also can be classified into data integrity There are simply an effective solution to preserve the integrity like sexums You know, uh, take me the former update or or you know or any data in transit or you know Even even cryptographic sexums can also be implemented There are of course challenges in implementing the encryption or crypto on a constraint Hardware for example 8-bit microcontrollers with limited RAM It could be really tough, right? So the encryption should be implemented directly into the hardware What integrity or has it has to be attached to the data payload or in the application layer This reduces the load on the constant hardware exponentially And now we have got the other property called availability and and and this ensures the high availability within the ecosystem This ensures that you're that you have done a pretty much good job in protection against the denial of service hardware failure Power outages and and the updates as well last but not the least we have authentication authorization This involves giving any access to only legitimate users and providing them access based on the role This also involves password management authentication access control issues Not only the application the authentication, but the device level authentication or device level security is also equally important hardware security chips like tpm allows devices to Securely authenticate themselves using you know public key infrastructure the pki also known as pki So this is this not just ensures the authentication is done But also ensures that the aftermath aftermath as well So let's look into the wasp top 10. I hope you have had a clear picture of what requirement have to be put up Now let's look into the top 10 pitfalls that developers make mistake. Well, uh, that developers make mistake and it's a much much worse I think I explained already in my slide what wasp is once again If you're not aware of what wasp is wasp is a nonprofit organization that releases the top 10 common security pitfalls to wasp for They do this periodically and update the list and of course wasp does a lot of you know good stuff and dev ops DevSecOps stuff as well But releasing the top 10 common pitfall is one of the major things they do So the wasp top 10 list is published once in every two years So hopefully sometime in 2020 uh end of 2020 We should be able to see the new update and take a look at how things have changed since 20 since 2014 When this was first released, right? So We'll talk about the top 10 security pitfalls. What are the kind of Pitfalls that keep appearing and this will help us to identify the vulnerabilities inside our iot application at an early stage So the first on the list we have is a weak guessable or hard-coded password It is no surprise that weak guessable or hard-coded password is on the top list As a security analyst, we have been uncovering this weak and guessable password since the day one And it is quite easy to figure out where this is even in the list This is because how manufacturers and developers use different passwords within the web interface root access or your secure cell access Or the telnet passwords, right the different passwords have been put up there This is also on the top because the attacker won't even bother about testing other component that could lead them to bypass the authentication It is evident that once the attacker has the authentication bypass pretty much every other security measure that we have implemented is obsolete So they won't bother about how fancy or secure or active to all with them are pretty much everything else is obsolete And not just this we have seen iot product that comes with a default password And do not allow the interface for users to change the default passwords So the key takeaway for developers is that do not assume that the users will ever change the password until and unless they are enforced to do so So all you have to do is provide an implemented interface through which user must and should change the default password Probably when I see with the default password and on the first boot ask the users to change the password compulsorily This also this this also includes any api keys that has been exposed inside the ecosystem any api key that has been hard-coded inside a mobile application Right or any unauthenticated api within your web interface The second on the least we have is insecure network services So the second on the least we have is insecure network services This includes any leftover ports any services that you have with debugging ports or the secure cell access or the 10 line Services or any other open port that are left over which are unused Remember always one thing as a developer you should note the note down is that The the very moment when you open open of these ports and network services You are opening up the entire attack surface. You're increasing the attack surface And and and sometimes due to the quick and easy implementation of insecure services Developers prefer using ftp instead of secure ftp or tell it over Secure cell access and if you talk about numbers 75.0 for percentage of attacks at on iot originate from telnet protocols This is how serious is it not to use the insecure services? The third on the least we have is insecure ecosystem interface This list includes all the vulnerabilities that lies inside a mobile application In a web interface, you know api is in a cloud console and the witness on any other ecosystem component The list of vulnerabilities are long but most commonly found are the cross-eyed scripting remote code execution or the operating system command Execution are known as os command execution also known as C surf or on web interface On the api things like unauthenticated api SQL injection You know overprivileged apis are relevant one on the mobile application side This includes hard coding of sensitive information inside binaries So insecure components and insecure apis are also prevalent inside the apis as well So now the fourth that we have on the list is the lack of update mechanism On many of the iot device simply the former integrated sake lack of insecure former delivery delivery of former updated Former that has been signed on stdp caused this kind of issue also many times this developer's device This iot devices have in sick inefficient anti rollback mechanism This is important because when there are critical vulnerabilities in the version x suppose that there has been uh, You know recently discovered a critical vulnerability in the version x You might roll out the version y but due to the inefficient anti rollback the developers will anyways downgrade to the version from y to x It's it's pretty common. Why it's obvious So always remember that the inability to update the device itself is a security weakness Failure to install the update means that the device remains vulnerable for the indifferent at time So the fifth on the list is the use of insecure or outdated component This holds very much true for industrial iot where the huge number of legacy systems are still being used This is because legacy systems are often expensive and technically difficult to upgrade One one vulnerable component Can cause and can make it all the security mechanism that you have implemented So it's very important to keep track of vulnerabilities occurred on the component or the libraries that are being used so the next The next one we have is inefficient privacy protection So this list equals all other vulnerabilities and all personal data must be stored and transmitted in a secure manner Which iot device have commonly failed But this this particular case considers privacy in a deeper sense to solve this problem You need to know exactly what data is being collected by the iot device What other iot device have sorry You need to identify what data are being exactly collected By the mobile application by the cloud interface and you need to make sure that the data necessary for functioning of device is only Corrected those data needs to be checked and whether there is a permission to show Personal data and then do you comply with any other compliance like GDPR or not should be said and and should be protected Whether it goes against those kind of compliance issues or not So what can you do about it? What can developers do about this simple solution store as much Sorry store as little information as you can As little personal data as you can even if you have to implement a data protection policy And for and for unfortunate situations this had ahead the incident response plan So this might help you in case of any You know attacks or in case of any data exposure The last few on the list are insecure data transfer and insecure in the lack of device management This both commonly deal with the device issues which talks about lack of encryption And access control in regard to handling sensory data and implies to both data at rest and data in transit What's the lack of device? lack of device management talks about managing the iot device in production If in case they have to be decommissioned if in case they have to be You know out of the production. How do you do it? Many of the iot device currently lack this feature And and this is very common in industrial iot as well The other we have in the list is insecure default setting This holds true because default settings default password configuration at iot devices default configuration on iot devices Are often insecure and this is slowly changing some lawmakers have been fighting for this For example, the california has a law that requires iot device manufacturers to set the pre-programmed password Or require users to change the password before even using the device If these kind of little security measures finally security measures are implemented Then I think we have we have reduced the attack surface by a little The last on the list we have is a lack of physical hardening this talks about tamper detection Hardening the physical debug port and easily accessible iot device in public places are what to be looked out for But developers your assumption must always be that your users will always open up the device inspect and modify it Not all users, but some users will definitely do that and with enough motivation. They'll most likely break a device So you must focus in You must focus in you know physical hardening as well not not only on the software component, but on the physical hardening as well So, uh, I think we we have covered up all the top 10 vast vulnerabilities Now since we have identified and launched all the common vulnerabilities, let's architect the security model for an iot device The one that you see on the screen is is based on the arms threat modeling for iot device And we have a huge topic today to cover up about threat modeling that comes ledger There are a couple of things to do before actually making the threat modeling. So let's let's quickly have a look at that So when you're when you're you know defining the security Secure architect for your iot device the first step that you always want to do is asset discovery The first thing is to identify the asset and keep a track of it If you're on a mission to identify the threats and I didn't always stress The first thing that you always want to do is identifying the asset the very next question that you might want to ask yourself is that What are the most valuable asset for you? Is it the former hardware? Is it the former or the hardware component in most important for you? Or is it the software component? Is it the sensor attached to it or what is it? So this asset discovery phase answers those kind of questions Identifying the asset will help you gather or say find out the potential entry points for an Attacker so so the next question is what consists of an asset? It could range anything from firmware to a sensor attached It could be anything within the ecosystem from a web application to a mobile application as well The next thing is that generating the attack surface once you have identified the asset You would want to generate the attack surface the attack surface is all about mapping out what parts of the asset or the system Needs to be tested for security vulnerabilities The point of attack surface is to understand the risk associated with the iot application The other point of attack surface is to help developers and security guys be aware of the parts of the application That are likely to be attacked and of course find out ways to mitigate them as well And finding the and finding the change in attack surface is also very much important When you add new new asset when you add new You know when you add the new asset finding out what happens to the existing attack surface is very much important What happens when you add the new component? What happens when you add the new asset? Does this increase or decrease the attack surface? Suppose it might so happen that if you introduce, uh, you know, uh, secure cell access You are increasing the attack surface But similarly if you're implementing a firewall, you might be decreasing the attack surface, right? So this would have questions that you that you must be ready for Once once you have identified the attack surface The next the next thing is that you're looking at the pipeline is threat modeling threat modeling helps you identify Is the potential risk which of the components are exposed to certain threats? At this stage it is assumed that you have a clear picture of threats and exposed Uh, and all the exposed thread you you have a clear picture of that Uh, you you also have a clear picture of all the entry points to which the threats are applicable Performing a threat modeling is very important because this helps you understand the security requirement and identify the threats before the bridge occurs And of course, there are a lot of threat modeling and I feel this is a missing missing puzzle in most of the organizations The other one that we have is animating the threats once the threat modeling is done One needs to identify the severity of the threats. What needs to be mitigated first? What alliance with our security requirements and what does not? This also helps you achieve the security objective and and address the threats that needs the immediate attention We use something called a common vulnerability scoring system also known as cbs is It's a scoring mechanism between 0 between 0 to 10 that tells how severe the vulnerability is Suppose if a threat or a vulnerability gets a score of 9 to 10 we classify them as a critical And of course this needs to immediate attention Now once you have identified all this the last one in the step The last one the pipeline is generating a threat summary table Once once the threat have been identified and enumerated the next step or the next action point for the For you for the developers is that to generate a threat summary table This threat summary table will have needs to have what threats you have what mitigation mechanisms could be and how do you How do you enumerate those threats and how to remove those threats right so those kind of threat summary table has to be done So this threat summary table will help you bridge the gap between what vulnerability you have and what are the what are the mitigation mechanism So a threat mod once the threat modeling is done Making a threat summary table is also equally important So now let's let's go back to the basics and visualize each of them So earlier we spoke about identifying the asset right so let's visualize what kind of asset that you need to identify So your component will include any hardware peripherals the sensors the communication The mobile application this also includes any sort of networking device you have far well as well right So I actually believe the asset discovery must be a continuous process scanning the asset passively Meaning avoiding any unwanted traffic will help you keep track on each asset So anytime anytime you release a new product or you release any update for your IOT device or IOT component. You're not missing out any of the asset You're not missing out any any API calls. You're not missing out any components on the cloud or any communication protocol So it is very important that you do this on a periodical periodic basis and on a continuous basis The second step is to build, you know the second step in building secure architects of IOT is identifying the attack surface Uh wasp also releases the non-exhaustive list of attack surfaces and the attack surface that you see is a part of it I do not want to spend a lot of time talking about this probably you can take a picture of this And of course you can find an wasp website as well Um, because anyways, we are going to visualize this in the next coming slides So let's focus on the slides. Yeah So visualization of attack surface, um, so if if let's put put all those attack surface that we recently saw into several stack layer and visualize each of them so that we could We could figure out the mitigation mechanisms based on the layers The most bottom layer is the hardware and secure boot services The common attack surface includes the open debug ports the plain text communication bus the insecure storage tamper detection and and side channel attacks If you see the bottom layer is the most fundamental level and must be protected at all costs Because it is the fundamental basis for all for the trust on all the higher layers This layer provides the secure boot services and the critical components as you as you go to the top As you go to the top of the layer The attack surface increases dramatically because there are so many ways that a malicious attacker can attempt to compromise the system The key to build secure architecture is that is to have a really strong layer one and layer two This is because the attack surface is very Small in this layer one and two and it's very easy to mitigate them And since the entire process of the system lies in the layer one and two I think it's it's important that you identify and mitigate the Uh, you know the uh mitigate the attack surfaces in the layer one and two very important As I said as you as you move on to the top the attack surface increases in this layer the former and core services The attack surface includes the former the upgrade mechanism the local data storage and the pass management The most common vulnerabilities include missing encryption Hard coding of sensitive information the hidden back those many times developers leave all the hardware certificates inside the former itself And there are several ways with ways with with with which an attacker can gain the former So if an attacker gains the unencrypted former you you have pretty much everything The other most common vulnerabilities that I have seen is that developers hardcore certain sensitive URLs Apart from that we also have seen n-person keys being stored inside the former itself The other is that the communication layer where the attacks like man the middle the replay attacks and jamming based attacks are relevant This is this is the communication layer now on the application layer This is by far the largest attack surface that you might ever encounter your mobile application This this includes your mobile application your web interface your administrative console the vendor backend apis hot party apis You know your uh, you know, uh, you know your cloud interface They all combinedly serve the largest attack surface And the attack on this layer consists of the sequel injection the cross-site scripting c-surf Week password and on the web application there and many more as well Similarly on the api you you you would find issues that you know unencrypted Personally identify information being leaked being sent over the sdp Which causes the privacy issues and this also sends the user location sometimes So you need to check out on those issues as well Now the on the last we have is the authentication authorization part now on the authentication and authorization part This carries a significant risk and also provides a larger attack surface The most common issues the most common issue that I've noticed among the developers is that the developed unauthenticated api But debugging proposed and leave them unattended and leave them, you know off in the production as well This most of the times allow the higher privilege access The reason why I've kept this on the top is because when authentication failed pretty much every other security issues Are also failed right so Take out on these kind of issues as well the issues like missing authentication the privilege escalation. So make a checklist of all checklist before sending out on a production that whether you have mitigated all of these attack surfaces are not So I think somebody has asked the question. What's your recommendation? When you have to trade up between security and product cost, I think the next couple of slides is going to answer those questions So to do that, let's quickly, you know Classify the type of attack that we have encountered and divide them into their respective category And and will then use it to compare against the cost to attack versus cost to secure So this is pretty much self-describing. You have you have got the four main types of attack the attacks in hardware The attacks and communication the software components the attack and software components and the cryptographic attacks We also have got any type of attack, which is not there in the list that is a side channel attack If you're not aware of what side channel attack is This these attacks are based on a side channel information that can be retrieved from a device This allows an attacker to measure power consumption voltage fluctuation or other side channel information such as temperature and sound You know side channel attacks make use of some or all of this information to recover the key The device is using it is based on the fact that logic operations have physical characteristics that depend on the user input data So the example of side channel attacks into the timing attack power analysis attack You know fault analysis electromagnetic attacks and environmental attacks as well But on a broader meaning they can be classified into one or more of these So the next slide that we have is cost to attack versus cost to secure So I think this is the same question that I'm this is this is this slide answer your question Let's talk about cost to attack versus cost to secure, right? So security is always about finding out the economic balance Economic cost in balance, right? So it does not make any sense in applying $50 security for the $5 fitness tracker But it makes sense for a $500 smart home equipment and also security is of course also dependent on the Valuable dependent on the value of the asset as well. So a good security architecture also includes the analysis between the cost to attack versus cost to secure Suppose things like communication attacks man the middle and sniffing that cheap to attack and cheap to secure But will this bring and value to an attacker? Yes, but the value is very less Rather the attacker would be impressioning more expensive attack that brings in more values and it makes sense For him or her to spend more on securing those attacks And for and it makes sense for developers to spend more on securing those attacks rather than on cheaper and easier attacks As you move on to the software attacks and not invasive. They are they're costly to attacks And costly to secure but but but this brings more value to the attackers the software attacks like malware attacks and social engineering attacks They've got this cost them a huge effort, but the damage caused by them is also large Similarly the physical attacks on iot device are boss-proving attacks and z tag They are also difficult to pull off at the same time difficult to secure So it makes a lot of sense for you to actually divide your security budget based on these factors and finding a Good balance between all of the components Now let's finally get into thread modeling So thread modeling is a cost effective way of implementing the security in the design phase of sdlc And of course, it's a great way to build depth sake of culture as well So it is a structured approach that enables you to identify quantify and and you know address the security risk associated with an application There are a lot of reasons why thread modeling is important A few of them could be is that it is cheaper to identify and fix the vulnerabilities during the design phase rather than to fix at the production Many other times after production you have a very little or no options left And it's also a great way to proactively identify potential issues and address them at right at the design process and notify the potential issues for developers Thread modeling actually answers questions like what really can go wrong? What should you do when things go wrong? These are these are the kind of questions that thread modeling You know answers This also helps bridge gap between the security and development cycle And is often regarded as a critical step in understanding the security requirement of a system The thread modeling start by analyzing the operating environment Understanding and documenting the ways this device should be attacked This tends to answer questions like what are my most valuable asset? What are the potential threats to my device? What kind of attack is most important for me to prevent at this period of time? And most importantly, how severe are the threats once the device has been developed and ready for production? You could verify if a device has made all sort of security Requirements are not have you addressed all of the threats are not any visible attack surface that is likely to be attacked Has then has this been prevented or not So thread modeling if applied on a sdlc can improve your security posters drastically The other one the other benefit of thread modeling is that you understand the security requirements Suppose if you have identified a thread like like man the middle Possibly that could occur in the apis right? So that could that could give you a security requirement to implement the stdps on production So without thread modeling it is quite impossible to walk on mitigating the threat You'll only you'll only identify the threats after the bridge But thread modeling helps you identify before even a bridge So there could be many standards for building out the you know threat models But one of the very common and widely accepted is Microsoft stride model There are many other models like the vast the great and the octave But we have been using stride for a very long period of time and it works really well with our customers In short you'll divide the threats depending on Depending on what the harm it can cause to this could either be classified all the harms that it could cause Could be classified into either spoofing at the tampering reputation information disclosure Denial of service or elevation of privilege These are the mnemonics for the classification of threats or the classes of threats So how do you build a threat model for yourself? This is a multi-step process that includes searching for threats building differences and eliminating the threats and evaluating the model The first step is to search for threats This is done by identifying the protein cell target To be protected and then defining its boundaries defining its boundaries and external system that it interacts with The next step is to identify the data flows within the target So if you remember earlier I spoke about the CIA trial, right? So this is when it comes into pizza identify the security requirements Based on the potential impact that it can cause on confidentiality integrity and availability The next step is to search for threats. This is mainly based on the enumeration This step also includes determining the known vulnerabilities here You also need to create an attack scenarios and probably play like an attacker The next step could be conducting a risk assessment And also access the likelihood of the attack So if you if you have found out and you know definite risk associated with your IoT application You need to access the likelihood. How likely or how how how do you think it is likely that the particular particular attack could be exploited particular threats could be exploited, right? So once you have identified and accessed all your threat, you need to build differences against it This includes mitigating and eliminating the threats that we recently had discovered The last is that the evaluation of model It is important to determine what is your highest priority or to look back at if you had missed out any vulnerabilities The evaluation model is important. The evaluation of model is important because in a larger team Not one single person will be handling everything, right? So your engineering team will have a good understanding of system, but not everybody The evaluation combines all of them engineering operations and security team All of them need to think like an attacker and evaluate the entry point for the potential entry point of an attacker Trace those path and probably mitigate them This ensures that all the team are on the same path and the team has a clear idea of what's going on in the threads and the possible mitigation So if you are not using threat modeling, I would strongly urge you to do this as this helps you understand the security requirements for your team If you're convinced and interested to learn more about threat modeling For IoT system, I would recommend a talk from Dan Garnel from OASP AppSec Europe 2018 This talk this entire talk is about threat modeling for IoT device And I think it's a must watch for you if you want to implement in your in your ecosystem And also sometimes and also sometimes SARS can help you identify the security vulnerabilities within the device And yes, I'm not paid for it. But yes, we have been using checkmarks for SARS and this works really well So, uh, so I think the counter measures on the application there I think we are in sort of time. Let's let's quickly wrap up this So on the application there, the obvious counter measures are using the strict password policies implementing the lockpot mechanisms And and use widely accepted algorithms rather than building your own, right? So and on on on the application there are vulnerabilities Keep an eye on the wasp top end and have them on your priorities to be mitigated And the vulnerabilities of you know, the first on the list We had was the application there, right? So this includes all the injection issues and authentication issues to be honest Most of the most most of the injection issues could simply be solved by not trusting the user input Most importantly not allowing the unsanitized user input to you know operating system commands This helps you prevent any sort of privileged command injection issues Similarly on the the counter measures for former are that You know always update the former over HTTPS in order to prevent the man the mail attacks And also implement the forced update mechanism with the entire rollback to prevent the critical vulnerabilities Implement the former integrity in order to verify and say if the former has been actually modified by the vendor or not The other common stuff include avoid hard-putting any secret inside the former Whatever component is it one thing you always need to make assumption is that they'll be purchased dissected and studied One of the most common develop mistake that developer make is that they're not studied enough So the attacker the hackers will not be interested enough to in the product to reverse engineer, right? So this is the assumption what makes developers you know stop and hard-put certain credentials inside the former So similarly the counter measures on hardware and Your communications are pretty much given here. I think we're sort of on sort of time. Let's quickly wrap up this So we we had one slide. I think you might be interested in this But I think we have discussed this as well. Let's quickly focus on the best practices for security you know for security, so Uh, so here in the best practices, uh, one of the one of the main thing that you could do is minimizing You know minimizing the exposure So any one thing that you should always keep in mind is that the very moment when you increase the exposure The very moment when you increase the exposure remember that you have opened up the entire attack service for people to Come and attack, right? So minimize the exposure. Try not to you try not to Send the devices with the debug codes in the production by not to you know, Unnecessarily open the ports and leave it off Also for the open for the operating system. Strive the operating systems with a bare minimum Strive the operating system as much as you can to the least that you can right? So this this this will see to decrease down your attack surface And and the ways the attack the attackers could get into your ouch device so um And and and I think uh, there are a lot of best practices I think uh embracing the zero trust policy is one of the very important that you could always do Uh to prevent any lateral entry inside the network even if it gets hard um And and and managing a vulnerability discloser discloser program results very important Uh in in terms of best practices, um, but I think because of time, uh, we'll have to skip this as well There are a lot of best practices and and probably you can take a picture of this slide Even I think I'll I'll be I'll be uploading this slide in uh this guide as well Uh, you can you can take a look at them and probably, you know, uh, implementing your Um and share this within your developers Uh, I think we have come towards the last slide. There are a couple of good bridge and good talks I think you can find them on the internet. That's pretty much for today. Um, I think I think you have launched A lot. I think you have launched something new with this talk and I hope you enjoyed this. Uh, that's all guys Thank you so much for coming in. Thank you so much for attending. Um, and I hope that you all Stay safe and stay healthy. Thank you so much for attending