Using Machine Learning For Risk Analysis In RBAC For IOT Applications - Benjamin

any complaints. So I'm going to be discussing the work I did for my dissertation which was making based access models more applicable to IoT environments through simulation. The general order is this. So I'm going to start with a refresher/ introduction to the topic of IoT and access control. I'm going to discuss the problem grow my suggested solution the theory behind it what I developed for it results and where I like future research to go so what is IoT the internet of things refers to a network physical devices vehicles appliances and other physical objects that embedded with sensors software network connectivity allowing to collect and share data this is the definition defined by a and you might

have noticed it doesn't say anything at Um wait uh the problem is IoT is messy and it means different things depending on the implementation and the architecture. You can broadly say that it's usually a distributed network of small devices and by small devices I mean that usually have one function such as a wind sensor gathers wind information and it's quite simple. They use embedded systems which makes them very compatible and within IoT networks you can have model ownerships. What I mean by that is say for example an intelligent traffic system IT you'll have traffic lights that own by seaman you'll have cars reporting their own data so you have multiple own ships which can make coordinating access

control a big mess so some quick examples of use cases for those not so familiar with IoT you've got intelligent traffic systems you've got health monitoring so for example my smartwatch I have smart scales at home all these small devices that are system And then you've also got smart homes. I'm sure everyone's health hopefully. Bit boring. Um so what does the typical hardware look like? So this can differentiate depending on the layer. So you have the application layer is the layer that users will interact with where the data is collected and calculated in centralized locations. Auto making asterisk is made within this layer and this is where the functionality of IoT networks come from. This is sometimes called the

cloud layer. The serve layer. So this is where the hardware such as servers will be in the cloud. You then have the middle layer. This refers to the layer responsible for communication between IT devices and this goes by multiple ones as well of course. And then you have the object layer and this is where the devices perform their actions such as collecting data from the surrounding environment where the IT device performs actions. So such as a traffic light where change color and stuff and so you have cars that fit in all three and then you have you have trackers that um well they they're mainly just in the first second layer and in terms of a network a

typical network although not much is typical in I environments you'll have cloud environment and then you'll have edge devices which have a bit more processing power then have the individual devices. So in the example of my smartwatch again I have my watch and then my phone acts as an edge device that will connect to server somewhere. So that's just a small catch up happy with that. So the problem which I've hinted to is that it is complex and this then leads to access models becoming messy. So I'm going to go over three typical three typical access models and explain the problems. So um out to control list if you've heard of them they're quite typical simple one that

you're um in normal IoT access models whatever um the problem is with IoT networks is for every new device you add to the system you will add one more dimension to the matrix of all these access controls that you have to say yes no sometimes more granular controls and these matrices just explode and unmaintainable. You have ro based access control which is slightly more realistic and these are quite good for IoT networks when you first implement them because you'll have usually quite well defined roles that people are happy with at the start like oh yes we're going to have this person who access the cars this person accesses this as your IoT network matures you'll soon get a

lot of niche roles a lot of outdated roles and just end up with an unmaintainable mess and then you have the last one which is quite specific speific to IT application which is the publish subscribe model which is actually quite a system but is very limited in its applicability cuz it um well I'll explain what it is first. So example in a wind monitoring station each device that monitors wind will publish the wind data collected say every minute to a wind channel then any IT device that wants to learn about the wind will subscribe to this channel and take all the wind data. The problem with this is you can't request data or formally communicate with any device. So

this will work in applications where it works for but there is no way you can expand this to work in situations it doesn't work for. So pro solution is risk based access control. Risk based access control offers a more contextual approach by considering multiple factors at once to make adaptive contextaware decisions by estimating the security risk of an access request. factors that are commonly looked at include RO, resource value, action severity and frequency of request. So this sounds a bit similar to attribute based um stuff which it is similar for those who understand this. Um this can address um so an example this can address devices suddenly request too much information um which is suspicious and dynamically respond to

this. Conversely, a device that's been on network for a long period of time requesting information infrequently might be given a higher level of control, which is quite useful. Um, this gran this granular control may access circumstances where a traditional system might deny it. So, there's quite an example of a paramedic. A paramedic shouldn't have everybody's medical information, but if they turn up, it could be life-saving if they have access to that person's medical information. And so there's an element where you can assess risk and a more dynamic system is quite good. After I said all this, it sounds great. However, there is a catch. There is a lot of mowers with defining risk, defining asset value, defining initial

risk with rule definition and it requires a large amount of processing power which is obviously difficult for IT applications. So is there a solution? I uh well I hope so I've I've made a solution for assessing initial risk in network um or tried. So this is only suitable for architecture with powerful edge devices that will be able to run it. There's there's no way around that. Um um and one other thing is the rest of the network do not need to run based access mode. This would just be for your ownership. So say for example you had a smart car. It would just be your smart car running this based access model. You could join a new network and have a

contextual understanding of the rest of the network hopefully you probably need more than one device. Okay. Yeah. So the theory the theory was to simulate large networks of IoT devices large random networks. The way I did this was by generating a random graph. I was doing it in an IT environment but I won't go into too much detail for that. a random graph of edges and nodes would simulate a road network and I would then assign a cluster of devices to random edges which were traffic sensors and then I would assign traffic lights to random nodes which were traffic lights like junctions. Um the idea is then to iterately improve the realism and use machine learning to

assess risk based on realistic simulation. Um this was working on um well definfined fuzzy logic traditional based access control. I wasn't trying to reinvent normal wristbased access control. That was quite simple. Probably too simple but that wasn't what I was trying to work on here. Okay. So what tools I use? I used Kathara if anyone's heard of it. It's a piece of software designed to create virtual networks. Um I used Carta which is an extension of Cathara that automates some of the spinning up process. um it helps with some of the rooting stuff. I use bash which is um you code the behavior of the boxes. I use Python which is a easiest language to write in in my opinion for the

machine learning stuff and um generating the random graphs all that stuff and then I use also use docker to uh create real Linux boxes which would um imate IoT machines as I believe this would be a scalable um approach for the future. So you could actually try and create more realistic IoT applications in the future. So yeah, so um just a little bit of the fundamentals I went through first. I I tried a model approach. So I have as you can see here on my GitHub a lot of different files. The idea was that if you wanted to work on this, you could pick the file that you wanted to work on. So a good example of this is someone

might come in with a different network architecture to me. They work on the file latest network architecture. Or for example, here you've got the if model type. I had a very basic machine learning model in there. All you need to do is replace that when you call the function with your machine learning model for a better machine learning model and you can say look at the file communication protocols. Um so that was the module approach. The advantage to this was I won't go into too much detail of it but I used hardcoded attributes at this point which the machine learning was supposed to detect and so there was a lot of importance in making sure that kept in a

separate file that the machine learning will never saw to ensure they actually trained off the simulation outputs rather than the patterns I was looking for detect. So there's segregation of files for that reason. So the main focus the machine learning part um it's going to be a a long slide I'm afraid. So um the hard code patterns were attributes the devices had. So they had attributes such as the manufacturer, whether the code was signed, when was last updated, a lot of them, uh, a lot of bowling attributes, and each of them had a certain chance of the device being faulty or not. And the machine learning would then guess how much of these how much of an impact these different

attributes had and then make prediction for whether each device was faulty or not. This would then start the simulation with this point in the based access model. It would then run for a couple of thousand of access requests and just see well so eventually it should always go to a good place and by just dynamically responding with fuzzy logic. It was just to try and get it to be that good point of ignoring the bad machines quite quickly with accurate accureness. Um so yeah it would it would then assign so after making some after so say in the middle after it's kind of got an idea of what attributes do it would assign each device how risky

it thinks it is the simulation would start and this and then you would get your it run for a thousand simulations and you would see how many of the access controls the access things were a how well it had listened And then that would be the feedback that the machine learning model would get. So if a load of if it been listening to incorrect people, incorrect devices, that would get negative feedback and it would realize that the attributes it guessed were wrong and it try again. This ran for many many simulations. I mean a lot of simulations and uh it's the most exciting part. The results [Music] it's it's exciting. Oh, they're mediocre. So, have I uh have I

wasted your time? So, uh why were the results so mad? The biggest factor was I'm bad at coding. I'm going to be honest there. Uh the second factor was I put the largest focus on developing the simulated platform and making sure that it was in like a scalable way that would be useful for the future. And I didn't put as much effort into the machine learning. I'm not very good at machine learning cuz I'm bad at coding if I mention that. And uh the second issue was that the um the award process was heavily affected by the factors that made a large difference. So for example, the manufacturer made a large difference. So I had a good sensor corp and they were

great. I had a shady sensor cor and they were bad. And so those big influences it could detect, but it wasn't very fine tuned to the more sensitive factors because I'm bad at coding. Um, it was also overly attracted. So that wasn't really enough for the machine learning model to learn from. So where would I like future research to go? There are two sections that I would like future research to look at. I would like a more physical approach of um so I'd like an analysis of my approach with a more realistic use case. So this would be more realistic docker images. This would be more realistic architecture and more realistic threat scenarios as I had

machines that either faulty or not. It'd be interesting to see more malicious machines and just a larger variance in threat scenarios and this could even include adversarial modeling which would actually give machine learning a lot to learn from and actually make it a lot more applicable. And then from a theory side um while I use fuzzy logic because it was convenient this wasn't evidence in space that this was actually best logic system to use and so it yeah that probably more theoretical ground work to be laid. So uh thank you for anyone everyone's coming you have any questions >> have questions >> um so I guess maybe coding was the most difficult part but my question was going

to be what was the most difficult part of the dissitation how did you overcome that >> so I I would say the coding was the most difficult part because I it was quite new to me some of the stuff I was doing and I maybe have the support I should have for that. Um, and then when it came to also writing up, one issue I had was because this actually something that's not been done before in my like literature review, I was literally reviewing IoT architecture. I was literature reviewing access control and machine learning and it just ended up with me having to review three different sections rather than people had done it before so I can

look at it more concisely. Then also my introduction became really long because the reader needed to be familiar with so many different topics. >> So I've programming something >> three topics at a time >> and it was only an undergraduate degree. So they give me that much time for it. >> How do you overcome it? >> How to overcome it? caffeine and um with the machine learning model not turning out well. Obviously, if I had more time, I think I could have been better and it would have been nice to see better numbers. So, cuz it's a bit difficult cuz I want people to carry this on, but then my numbers aren't even good cuz my machine learn model wasn't

that strong. >> Any other questions? >> Yeah, I've got one. >> Okay. >> So, the um I mean the theory behind what you're saying sounds really good. I know. you're kind of slamming yourself a little bit here at the end with how it turned out. But I think the idea of an IoT risk based architecture is a good idea. So who are you kind of pitching this towards? Would this be the manufacturers of the IoT devices or be the people who are maintaining them? You know, where is it your if you could do this a sales pitch to somebody? Who would you sales pitch it to? >> Well, I would say it's um they just the

research behind it to really be pitching it. or an academic interest of seeing if this is even feasible. So that's who I'm taking it to the moment. >> You go to more of a university type or research company or something like that. This this is a thing I think this is a gap we have in the market and I want you to fill it. Let me help. >> I'm I'm sure the solution would work. It definitely needs more research cuz I was just like I picked fuzzy logic at random because it's just not been done before. Um, when looking at papers on this topic, the average number of attributes looked at per paper was 1.8 when

implementing risk based access, which just is not enough because the number of hours of physically defining all this stuff just makes it unrealistic. So 1.8 fact, you get none of the advantages of a dynamic um access model. So the groundwork's just not there yet. >> Any questions? Yeah, >> especially since [Music]

there have been other approaches explored in terms of access. >> Do you mean like um is there risk based? >> Yes. Um there there definitely are other methods that work. I was told to look at risk based access models and I find a hole and fix it. That's what I was told by my professor. So I have not really looked at anything other than risk based other than their shortfalls. So risk based access control won't actually work for a lot of implementations. It's only when you actually need the advantages of a dynamic system such as military or health where it's really important. The problems with implementing risk access control which I did mention are proving

it's secure is very difficult um proving that you've actually got your systems in a dynamic system is very difficult because you have no static access control you can point to and say they don't have access to this. So it it definitely there are other applications and there are other access models for them. But if you wanted to implement risk based access control, this is one of the suggestions I have. Is there any other questions? Everyone's still awake though. I'm pretty impressed. Thank you very much. [Applause]