A Hitchhackers Guide to the IoT: Security from a FMCG Perspective

uh can you hear me yes all right um anybody know what's the catchphrase for the hitch hikers Guide to the Galaxy the first two words yeah don't panic so so basically um those are the exact same words that were floating in my head when I was asked to do or build up an iot security program or um a company a Fortune 500 company I was lost and um I didn't know how to build it my background was from application security and um I know right now it's a quite a cold day and long day but um let's take it easy and unwind and uh go through an easier to digest topic uh which is an introduction to iot security and testing so it's kind of cool that the culminating topic right now is uh sort of a mix between everything that was uh talked about earlier today we have uh we are going to talk about Hardware Security application security um threat Intel um application development and even incident response so um hello everyone um good afternoon um let me introduce you to a hitch hackers Guide to the iot a security from a perspective of fast moving consumer goods company so quick introduction my name is Jerome de las Alas you can call me JD I'm from Atlanta Georgia uh this is my first time here in Charleston um it's a very very good city um and a very pretty um I'm currently doing product security um for Kimberly Clark um for 12 years I was an application security engineer I came from 45 on demand before it was or um previously it was from Hewlett Packard um so basically before cyber security um I was doing or I was coding assembly uh for a Japanese company uh doing a laser measurement tools so essentially um I was um doing development work um but around seven years ago I was hired by Kimberly Clark to build their own application security program um right now I'm focusing on iot security we're doing a smart restroom solution so basically um for businesses to automate their PayPal Tower dispensers and make it easier to track maintenance of restrooms um outside cyber security my interests are astrophotography photographing the Stars galaxies and uh looking at millions of years ago from the past as you might have noticed this presentation is uh play in words um for uh Douglas Adams's Hitchhiker's Guide to the Galaxy um which I thought suits um this walkthrough best because from a cyber security perspective um I I felt like it was I was just hitchhiking um my um journey through iot security because nobody knows how to like build iot Security Programs especially from a non-technology company like Kimberly Clark right so um there was no Surefire way to go through iot iot security back then a couple of years ago and the whole iot security landscape is still a mess until right now um there is no standardization no security controls uh unlike application security which has OS etc etc right so um basically um we're doing our best effort um to mimic what we are doing from currently established uh Security Programs like web network security etc etc so let's switch perspectives for a while a majority of the talks today are from um cyber Security Professionals uh vendors that are that are providing um Security Services to companies but from my company from my perspective we are on the receiving end um it is our business that's that wants uh security from the experts um these are the color-coded chapters that we're gonna go through uh to um figure our way out or figure our way through um iot security so our first tip uh figure out where we are um at this point we are aiming to figure out where we stand what's our posture in the current iot landscape um for essentially all the um iot devices in the world um Kimberly Clark as you might know is specializing on paper products like Kleenex uh diapers like Huggies um and it is estimated that it is estimated that one-fourth of the world is using sorry yeah one-fourth of the world is using Kimberly Clark products per day so it it covers quite a lot of uh people but um yeah remember the pandemic when everybody ran out of tissue papers yeah that was us so um why on Earth would we run out of uh technology would we want uh to dive in into a technology we are a paper company right um the short answer there is there is a market for it um businesses want to automate they they want uh efficiency in their businesses and that's why we're providing iot solutions to uh easy um for easier monitoring of their um bathrooms or restrooms and that that was the point where we thought uh we needed to take take a step back and um Define for ourselves uh what the hell is iot and where would our products be in our in the ecosystem uh we we also had to evaluate our offerings and um how to integrate Security in the development of the product um in the next couple of slides we'll go through the what the why and the how so basically these are just clippings of uh issues and growing concerns for iot security um since 2018 um until recently um consumers are slowly starting to be aware of iot security and um as we move forward I think it would um start to get more visibility from everyone um something some I think worth noting here is the uh Google uh smart speaker Fiasco here when um they admitted uh that they kept a recording of users um without the Wake words okay Google so it's kind of interesting for me um these are just small samples of iot and connected devices from the more normalized ones like smart TVs smart cars smartphones uh onto on until the until the more absurd ones like uh smart salt shakers uh smart sandals um smart toothbrushes everything is smart right now um there is a quote here from uh the Oxford dictionary um which is uh it's a sample usage sentence from Oxford uh which I found quite interesting given that the the first thing they thought about um aside from the transformation for iot is uh security and then we have to evolve we had to evolve away our way of thinking uh from a normal software uh development life cycle to what we now consider as system development life cycle uh we had to look into emerging Technologies and make new efforts um to do security considerations for each I broke down this these pillars into five distinct items uh that we can separately test and ensure efforts on security uh um controls and configurations for each um these are hardware and firmware um and just a side note uh we have collaborated with our earlier speaker Jake here uh from andient um and his team to get our Hardware tested um I believe they did the methodology that they he described earlier or not one of our products yeah it's so cool so um Communications and networks and protocols like Bluetooth low energy cellular mqtt um and of course we already have application security and mobile security kind of in the back because uh we have established our application Security Programs way earlier before and then there was a secure Cloud configuration and hardening which is also a bit new for us and then we saw a new and different risks and opportunities what that we previously uh just kept at the back of our minds um we all we oh we always find this mean uh funny because um essentially when the hackers uh need only to be right once um to measure their success well from a security perspective or from our perspective anything less than 100 is considered faulty um this also means that considering that nothing is standard um there's no consensus way to protect iot implemented implementations since there are thousands if not millions of permutations um on how to build an iot solution and then when the product was prototyped we had to establish a method to the madness um I call this a trial by fire um we were already there there's no going back uh we had to move forward and so we did uh we will I will walk us through each item and provide samples of how we approached it um most of you might find find this uh simplistic um I apologize for that but keeping things simple is what helped us understand how deep should we go in terms of our security controls and our design our first um tip is dual functional or normal Baseline test first I cannot stress this enough if we have a device make it work first like you're a normal user um and um not a an actual hacker there's no point in uh doing security testing If the product is not even working right so for example if you are testing a Smart Lock right here um if see if it unlocks first uh download the application and try to unlock it normally foreign the next step is uh draw a simple architecture diagram well with associate functions and mapping of what it does uh rtfm if you don't know how things work usually these products have some details and Technology on the technologies that they use um in their user users manuals so for example here in the Smart Lock um they advertise that they have a mobile application and you already have the hardware device which is the Smart Lock and um we assume that the the application is communicating through a cloud environment and that's why what we wrote here in our architecture diagram foreign open up the devices sorry it's kind of cold um list out parts that are easily identifiable um refer to user manuals and development manuals um and consult specific technical documents um majority of these um search engines are very very helpful when um when discovering um the the user usage and um um yeah um functions of the components for example when uh we open up a product there's uh usually an engraved label in the microchip or microposter do a quick Google search for that uh either through their FCC ID or their specific data sheets um shown here is an ESP microcontroller esp32 um it's a very very common chip for Internet connected products uh and interestingly I noticed a little badge here um also is using the same check family um funny when you look at the badge here there's a QR code uh that should contain information on when the chip was created or manufactured and it should also contain the MAC address of the actual chip and other Vital Information that are in the chassis of the microprocessor so once we get the data sheet there they these should display the pins of interests not not Pinterest but pins of interest that would probably want we want to test uh pins like uarts SPI jtags um that data sheet would also on to us which pin to pull up or pull down if you want a specific desired function um data sheet should also tell us what which pins are the VCC or the power pins as well as the ground pins um it should also show the unique specifications of the microcontroller uh such as the delays and the clocks the uh the timers Etc uh since we only have a limited number of pins uh in a microcontroller sometimes the functions are multiplexed um into different pin outs uh depending on the developer's configuration once we establish a method to the madness um we we can expounding it into a to map an attack surface so um remember this is the the um architecture diagram that we wrote earlier what we can do is um since we have established these functions what we can do is um these are the orange ones we can write out the specific effect surface that are are possible for for the actual functions for example we have uh ble lock here which is the physical device what we can attack is uh the firmware um um yeah physical security issues like essentially pulling or uh breaking the device itself and then um for example Bluetooth low energy you can snip and replay the traffic like um for using um um yeah Uber tooth etc etc so um Verma Cloud uh security perspective check if the it is also susceptible to brute force or misconfiguration um exposed API keys and tokens should also be considered here and then we do our normal tests uh for each of the components I mentioned a while ago um yeah a few slides ago uh the common go to tools here from the different fields of security um of penetration testing would be a great start so for example for hardware and firmware we have Benoit uh microcontroller debug tools and um uh the applications for uh Communications we'll have Wireshark TCP Dom Uber tooth Gap tool etc for web and mobile applications we have the ever reliable burp suite and the Z attack prophecy this is we Where we exercise our creativity for example I was testing a prototype uh or a solution of home and I cannot for some reason sniff the traffic um um that was generating I ended up connecting my device to my um pineapple for mac5 and then I executed a TCP dump from the the hack five um GUI itself then that's the only time I was able to uh do the TCP dump of the traffic um or the piece the pcap files of the traffic um the internet is also full of geniuses that um that are already have the necessary um tools associated with with that specific Hardware uh for example uh esp32 here um if you search for the ESP tool that python they actually have a python script uh that can dump the actual firmware uh once you connect and or find the actual pin outs in the device um and this is where the actual title of this topic is we we hitch hike or we hitchhike from the Geniuses from the internet and use their expertise and Technology to um for our own advantage so some tips while working through a test though uh first be patient sleep on it usually the answer is already there but you are you just have to look at it from a different perspective uh start with the least invasive tests do not go gung-ho in dismantling uh the devices from your first test cases um this includes testing the default firmware and software before any updates are um um made or done um yeah do not break the device for now my next set of uh tips include uh considering power supply and static electricity from my past experience as a hardware developer Hardware is 10 times more worse to troubleshoot than software um simple static electricity can break your device and uh in a matter of seconds uh soldering and desoldering while the device is turned on could possibly overheat um uh the sensitive microchips possibly um takes uh step-by-step pictures of uh or a video while you're dismantling the process uh this brings back memories when I was a kid and being scolded by my mother for not being able to put back um some home electronics that I dismantled those were the days um but also on this math when dismantling a device uh be mindful of component orientation some specific electronic components like polarized capacitors uh might not work or might even destroy your whole device when you put it backwards and then we go into the details of documentation I know documentation is a bad word for uh penetration testing but um yeah aside from the normal contents of an uh a normal penetration test we include some new components such as device versions firmware versions that we tested um also include the tests that did not yield actual uh significant security issues so that next time when other pen testers uh do it they they would know which methodology that was um that was performed from the previous test so in summary those are the tips that help us configure or help us figure um where we stand in terms of capability and uh from a consumer goods manufacturing standpoint some tests we did we did on our Pro own prototypes some tests uh we had uh to test devices from the outside like if we were using an external component um or external um solution then we had to test it ourselves as well now we go to the second tip which is um never ignore strategy for the sake of how fast the iot uh environment or landscape is changing our current chief information security officer always tells us to skate where the puck is going so basically um we look into the current iot landscape and predict what what would be the next Trend and so we can um manage um the the security attack surface that's going to happen on that end um yeah so we also um asked our business to um let cyber security have a seat at the table uh in terms of decision making um and have um have some inputs from our end because at the at the end of the day whenever a a product is reached it's the whole brand or the whole company that's going to be affected so also when starting we had to reach out to different individuals like our corporate Saturday strategists our r d business owners to learn what they Envision their product would look like and from there I worked backwards to fill in the gaps like the necessary supporting documents um standards like Nest OAS iotsf uh provided my Baseline requirements um special courses like uh the apify one from Aditya Gupta and Sans iot security course um helped me establish the the required test cases um these courses also have the perk of having security test kits uh that we can practice on hardware for um some of the hardware that we don't necessarily prototype but we um we are curious on how it works as well so shift left has been a buzzword for application security for quite some time now why not integrate it in the system development lifecycle as well um note that we're still in the same theme here um think of it as we're like on a spaceship and lost in the galaxy and shifting left is course correcting and maneuvering our shift towards the left devops right now has some integration with uh security automation tools like SAS Das and software composition analysis um some of these processes and integration can also apply to Firmware development on how firmware it is designed um Seas or software composition and analyzers in particular have um can help build out the software bill of materials which would immensely help in tracking uh threat cves and uh the the actual component updates and Frameworks that we have previously used um you also need to establish a threat analysis early so that we ensure that the necessary controls over each attack surface and attack scenario that we identify so here's an example of the uh threat assessment snippet um first we identified the type of threat um in this case uh software uh the the leftmost part here and then we established the uh attack vectors uh and the impact and then we established the current status of the threat whether it's mitigated or not or whether um uh it's still open and then uh the rest is for the incident response and how can they how can they tell if something goes wrong with the product um we can also use some industry standardization and uh recommendations like the micro framework here uh we all we listed out the some of the um yeah code uh for the actual threat uh that we found um or simply if you want to have a more um quantitative approach you can use the CVSs scoring for it on point to our space space theme uh let us uh timer jump or uh time or space warp um this just means that we need to understand where is the balance between letting go of the security range if you want r d and Innovation to flourish versus when we need uh cyber security to come in obviously we would want cyber security to be present in the final design but we would want we do not want a full-blown penetration test on a Sandbox environment right so the key word here is seamless uh make it so that cyber security is not um considered a roadblock but uh rather a selling point for a product so oh no we uh need to test our ship uh quick press the red button but um oh is that the orange button so basically the red teams are in uh are critical in testing our security posture uh but we would want involvement with our developers and that's where the um orange comes in we want a mix in yellow which is the developers and um join it with the red team making it orange so um historically and usually developers are um and Security Professionals professionals are at odds when it comes to product development usually they come yeah so from my standpoint we just need to talk to them um make the developers understand the value of our security controls and uh bring to the um what our security controls bring to the overall posture of the whole solution um make them realize that it would take a lot more to fix if the actual vulnerabilities are