9 hours 59 minutes
Welcome back in this video, we're going to focus on Internet of Things, technology, some of the specific security considerations related toe i o. T. And then we'll touch on something quite related, which is mobile and mobile security considerations. Specifically from the cloud perspective,
I O. T. Is a term broadly used to describe a variety of computing devices that have a specific intended use in the real world. These air referred to as the things and those things, are connected to a network. Smaller powered things like equipment, sensors, electricity, meters and even medical devices
may not be directly connected to the network.
However, they will communicate with higher power devices that act as a gateway to the Internet. Your mobile phone could be one of these gateways, or it could be a custom appliance or device often referred to as an edge device. The amount of streaming data coming from these devices can vary. Mass consumer devices may stream small amounts of information,
but since the overall number of devices is much greater,
they can end up streaming an equal or greater amount of data than specialty devices that stream high definition images or heavy information amounts I ot brings its own set of security concerns in the C S. A. Outlines quite a few. Let's cover those here, starting with secure data collection and sanitization.
As an example, you may wanna scan incoming payloads
to see if they contain malicious data or malformed data that could compromise your system.
Each device is going to establish its own identity through a centralized registry. The registration process may occur during manufacturing with the device or through an irresistible ization process that takes place in the field. Subsequently, whenever the device phones home, it will be able to identify itself as one of the register devices.
At the same time, you can't blindly trust the identity,
so authentication needs to take place. This could be done using a password, but publicly and certificate based methods are preferred, as it makes it much more difficult for somebody who is attempting to spoof the device to guess the authentication value. Either way, you don't want to have all your devices using the same hard coded password or the same key credentials
in that situation. If one device gets compromised,
your entire fleet could be compromised. Once the device is authenticated, access controls around what the device can and cannot do should be managed through authorization.
As you'd expect, the chatter between the device and the cloud should be encrypted and transit. Somebody can easily sniff unencrypted network traffic, but you also want to make sure that a bad actor can't place themselves in the middle of the communication, acting as a proxy to decrypt and re encrypt any communication
certificate. Pinning can be used to ensure your device. Onley Trust communication coming from select sources
like your cloud based AP eyes. The goal of all this is to make sure nobody can listen or modify the communication taking place between the device and the trusted parties, whether they be other edge devices or cloud based services.
It's also worth taking a direct look at the A p I security for the device to cloud communication. This'll is a great opportunity to define the defense in depth philosophy, assume that somebody has figured out how the communication protocols between the device and cloud work, and if that happens, you can have a P I security, which is an extra layer of your defense.
This can prevent DDOS attacks,
enforced device isolation and sure the device itself has appropriate authorisation, so it can Onley perform the activities that are necessary.
The reality is things will never be perfect. You may have security vulnerabilities. You may need to add new functionality. This brings the ability to patch device software and firmware onto centre stage. It's a capability you'll want to design in as early as possible, since it gives you flexibility to make changes once your fleet is deployed.
The C S. A doesn't specifically talk about code signing, but it's a vital strategy to use for implementing device patching.
This way you make sure that the device on Lee applies software updates that it receives from trusted sources. Keep in mind these devices air out of your physical control. Somebody can open them up and do some real low level hacking, like flashing firmware updates through J tag interfaces examining memory,
even physically manipulating the electronic components, this leads to the final point of tamper detection. Having the ability to identify devices that aren't in line with set up you'd expect
is very powerful capability and ensuring security of your i o T ecosystem.
If you're the device manufacturer, you don't want somebody to overtake your device and use it for things it's not intended for,
especially if the device is attacking your cloud service. As the person responsible for the network that the devices running on you want to make sure the device does not provide a weak point or a foothold for an attack to get on your network and cause damage to other systems, that could be way more critical to your overall enterprise or company.
We look at devices that provide more general computing capabilities, such as smartphones and tablets, very similar to the way we look at the I O T devices.
These devices often have applications in those applications connect to a server based back end,
since the devices themselves could be geographically distributed and the workloads unpredictable and very dynamic, it makes hosting these back end in the cloud a prime option for you.
The C s. A. Calls out to specific areas of mobile security device registration authorization in authentication, just like I o t. But this could be a little different in that your applications ability to obtain and store credentials keep in mind. These devices will be hosting other applications in the same way cloud providers strive to provide 10 and isolation
mobile device manufacturers strived to implement application isolation.
However, there are always clever people out there who figure out ways to jail break their phones. This can allow a devious person to access the credentials your application is using to authenticate with back end services.
This pain point believes into authorization and a P I security CERT. Pinning is the method that you can use to have your mobile app insured on. Lee talks to the cloud services that air trusted, and this mitigates the potential for a man in the middle attack.
Such attacks could either be passively listening or could be actively modifying the communication stream between your mobile application and those cloud based applications. Now there's a ton in the realm of mobile device security, and it's almost its own discipline.
But the C S. A is just focused on the cloud based aspects of mobile computing. And so, for your CCS K exam, you don't need to be concerned about a lot of those other areas. And I'm not gonna cover them right here either. To summarize this video, we reviewed the definition of Internet of things we talked about I o t specific security considerations. And then we examine mobile security considerations,
many of which are quite similar to the i o T security.
Introduction to IT & Cybersecurity
Are you new to IT & cybersecurity and wondering which role might suit you best? ...
2 CEU/CPE Hours Available
Certificate of Completion Offered
AZ-500: Microsoft Azure Security Technologies
Azure Security Engineers are responsible for protecting against vulnerabiltieis, implementing threat protection, and responding to ...
9 CEU/CPE Hours Available
Certificate of Completion Offered