What is Message Queue Telemetry Transport (MQTT)? How to secure MQTT?
MQTT is a messaging protocol broadly used in IoT and connected services, very lightweight and reliable even over poor quality networks. It is designed lightweight so it can work on constrained devices but, even in its latest version MQTTv5, the attack surface is very large.Security for IoT Devices and Why It’s Important
IoT We do use Personal Computers (PC) and server/client computers that run Windows, Linux, etc. PCs are used for helping human activity, thus the computer network is basically for displaying/output info/video/audio to humans and input by humans, so it is Human to Human (H2H) network. When we talk about CyberSecurity, that refers to those server/client PCs and TCP/IP security. Other than PC,s there are Micro Computers/Embedded Computers that are used for Home Electronics, Factory machines, live cameras, or small devices. Most of them were used to work for in-house tasks and were not connected to the Internet with TCP/IP protocol until recently. By the way, I think the iPhone is the most successful computer device that uses the Internet in the history of computers. However, the iPhone (and iPod touch) is not the first handheld device of Apple. Apple released the “Newton” in 1993 which can perform a variety of tasks like the iPhone. However, the sale of the Newton was not good and the project was canceled. We are not concerned here with the question of Newton's failure, however, what the iPhone has and what Newton hasn't - is the ability to connect to the Internet. As a result of the mass production of iPhone and other smartphones, microcomputers, GPS receivers, and small sensor devices became inexpensive and mass-produced, and Internet connectivity became possible with inexpensive components. Naturally, Micro Computers/Embedded Computers are combined with cheap network access devices - the combination of these microcomputers and networks is called Internet of the Things (IoT). In most cases, IoT devices relay data from sensors which is attached to the IoT devices, and it relays to other IoT devices to aggregate the data for processing – the IoT devices are connected, and the communications are done among IoT (machines): so it is Machine to Machine (M2M) network. So the IoT devices are also to be M2M network devices. One of the well-known examples of IoT devices is the Arduino board which is an open-source electronics platform based on easy-to-use hardware and software. Arduino is easy to program, and deploy, and can use many types of sensors, and the cost is quite low, thus it has been used in thousands (or more) of projects and applications. As IoT devices are much cheaper and easier to produce compared to the PC, the number of IoT devices increases rapidly, and no limitation on the producing number. In contrast, the demand for PCs (and smartphones) is limited by the number of humans. The number of IoT devices that are connected (cite from statista) 2019 8.6 billion 2023 15.14 billion As the number of IoT devices increases, the network connecting IoT devices (M2M) increases geometrically. By the way, BigIP LTM has a profile to use one of the protocols which is used for IoT networks ( Local Traffic ›› Profiles : Services : MQTT ). Security Concerns What problems will arise from IoTs? Attack surface First, unlike servers and PCs, these IoT devices are small and can be transported anywhere (laptop PC is portable, but limited to the space where human goes). A good example is drones – which has microcomputers and network connecting devices thus IoT - that can move autonomously from place to place, even to the place humans can’t go. Therefore, they are not restricted access by physical location and can be connected to the Internet wherever they are located. Therefore, unlike servers and PCs, it is difficult to know the location of all IoT devices in the world. The problem is that IoT devices are directly accessible by malicious attackers: they can be everywhere and the number of devices are too many to track all of them. From the network perspective, servers and PCs are always protected because they have limited physical access points = Attack Surface, and even if they become the source of an attack, the locations of the malicious attacker’s host can be determined to some extent. The CVSS metrics score low when the PC/Servers are not accessible via the network. In contrast, since it is hard to know all the locations of IoT devices and their M2M network connection points, the Attack Surface is everywhere. If an IoT device that is located in an unknown (physical) place is compromised and becomes a jump host, it might be difficult for a defender to know where the attack is coming from. In other words, being everywhere because it is convenient also means not knowing where they are. We need to think about expanding the attack surface. You may recall the Mirai botnet - Mirai's primarily targets IoT devices such as IP cameras and home routers - IP cameras can be placed on the outside of the building so easy to access for the malicious attacker. In the Keynote speech of BlackHatAsia 2019, the presenter of the speech said that “IoT is next asbestos!” Not only physical access, the range of the network is going to be expanding. As the number of network devices increases, the amount of network connecting them also increases geometrically, so the network that needs to be monitored will also expand. Network protocol Second, many IoT devices use protocols other than TCP/IP. Since they were used in the closed network before the IoT era like in the factory or car, the design and implementation of such protocols do not need to consider security and privacy. However, once it connects to the Internet, attacks against them are often easy due to the nature of those protocols, which are not security-conscious, and the lack of research that has been done on them may make these attacks possible. For example, the CAN network is used for in-vehicle (i.e. car) networks, which have no destination or source address. Therefore, it is difficult to identify and block the source of an attack through the CAN network. Some IoT devices communicate through TCP/IP and HTTP protocol, but not HTTPS – it is because those devices are designed to be using small memory and narrow network bandwidth. Of course, it is not secure. The amplified DDOS attack As mentioned above, the number of the PC is limited while the IoT devices are limitless. And the protocol has some security weaknesses – so the IoT devices could be compromised and used as jump hosts for DDOS campaigns. The jump hosts which is used for the DDOS attack will be amplified - more than that of the H2H network, and it make it difficult to defend. Mirai botnet is one of the most famous IoT attacking bots. Quote from What was the Mirai botnet? "In late 2016 in France, telecom company OVH was hit by a distributed denial-of-service (DDoS) attack. Experts were struck by how the assault was 100 times larger than similar threats." This incident happened in 2016 - as shown above, we have more and more IoT devices. Defense IoT devices behave differently than PC/Servers and require their own cybersecurity rules depending on how they operate. To reduce the risks of IoT devices, some system standards and security guidelines for IoT have been published by governments and non-profit organizations. USA IoT Cyber Security Improvement Act of 2020 https://www.govinfo.gov/content/pkg/COMPS-15863/pdf/COMPS-15863.pdf NIST IoT Device Cybersecurity Guidance for the Federal Government https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-213.pdf USA DHS : Strategic Principles for Securing the Internet of Things https://www.dhs.gov/securingtheIoT IEEE IoT security best practices white paper https://standards.ieee.org/wp-content/uploads/import/documents/other/whitepaper-internet-of-things-2017-dh-v1.pdf To mitigate the risk, IoT devices need to consider implementing security measures when it is designed. For example, access control feature and user(machine) authorization to change the config, implement encryption (while it is a performance trade-off), monitor the abnormality, and use Edge computer to filter the data and proxy the connection. And, of course, not using default user/Password is essential – the Mirai botnet will use them. In most cases the data from IoT devices will be uploaded to cloud service and processed on the application layer – thus application firewall can be one of the protection measures. Future Think about the future – the number of IoT devices, the M2M network, and the amount of data on the M2M network will be exponentially increased, thus humans might be overwhelmed to monitor and analyze the network. Recently generative AI has been used for large amounts of data, so AI will also be used for IoT security. As discussed in another article, the security of AI is also important, and, if AI and IoT are united, things need to be considered might be more. Further study Thesis of IoT security in arxiv: A Survey of the Security Challenges and Requirements for IoT Operating Systems https://arxiv.org/abs/2310.19825 A Unified Taxonomy and Evaluation of IoT Security Guidelines https://arxiv.org/abs/2310.01653 Navigating the IoT landscape: Unraveling forensics, security issues, applications, research challenges, and future https://arxiv.org/abs/2309.02707 A Large-Scale Study of IoT Security Weaknesses and Vulnerabilities in the Wild https://arxiv.org/abs/2308.13141 Unleashing IoT Security: Assessing the Effectiveness of Best Practices in Protecting Against Threats https://arxiv.org/abs/2308.12072 IoT and Man-in-the-Middle Attacks https://arxiv.org/abs/2308.02479 5G Networks and IoT Devices: Mitigating DDoS Attacks with Deep Learning Techniques https://arxiv.org/abs/2311.06938 IoT in the Era of Generative AI: Vision and Challenges https://arxiv.org/abs/2401.01923The Internet of Sports
Did you see what the NFL is doing this year with sensors? Earlier this month they announced a partnership with Zebra Technologies, a company that provides RFID chips for applications from 'automotive assembly lines to dairy cows' milk production.' This season there will be sensors in the player's shoulder pads which will track all their on field movements. This includes player acceleration rates, top speed, length of runs, and even the distance between a ball carrier and a defender. Next year they'll add sensors for breathing, temperature and heart rate. More stats than ever and could change the game for-ever. Imagine coaches being able to examine that data and instantly call a play based on it. Play by play. To me it somewhat takes away that 'feel' for the game flow but also having data to confirm or deny that feeling might make for exciting games. Maybe lots of 0-0 overtimes or a 70-0 blowout. Data vs. data. Oh how do I miss my old buzzing electric football game. The yardsticks will have chips along with the refs and all that data is picked up by 20 RFID receivers placed throughout the stadium. Those, in turn, are wired to a hub and server which processes the data. 25 times a second, data will be transmitted to the receivers and the quarter sized sensors use a typical watch battery. The data goes to the NFL 'cloud' and available in seconds. The only thing without a sensor is the ball. But that's probably coming soon since we already have the 94Fifty sensor basketball. And we've had the NASCAR RACEf/x for years and this year they are going to track every turn of the wrench with RFID tracking in the pits and sensors on the crew. Riddell has impact sensors in their helmets to analyze, transmit and alert if an impact exceeds a predetermined threshold. They can measure the force of a NBA dunk; they can recognize the pitcher’s grip and figure out the pitch; then the bat sensor that can measure impact to the ball, the barrel angle of their swings, and how fast their hands are moving; and they are tracking soccer player movement in Germany. Heck, many ordinary people wear sensor infused bracelets to track their activity. We've come a long way since John Madden sketched over a telestrator years ago and with 300 plus lb. players running around with sensors, this is truly Big Data. It also confirms my notion that the IoT should really be the Internet of Nouns - the players, the stadiums and the yardsticks. ps Related: Player-tracking system will let NFL fans go deeper than ever Fantasy footballers and coaches rejoice—NFL players to wear RFID tags More sensors are coming to professional sports, but research outpaces business models Why This Nascar Team Is Putting RFID Sensors On Every Person In The Pit Impact Sensors: Riddell InSite Impact Response System Fastpitch Softball League Adds Swing Sensors to its Gear Technorati Tags: rfid,sensors,IoT,things,nfl,cloud,big data,silva,f5 Connect with Peter: Connect with F5:
F5 BIG-IP MQTT protocol support and use cases in an IoT environment
The Internet-of-Things is a system of physical devices, vehicles, buildings, and any other items each provided with a unique identifier allowing them to communicate with one another without any human intervention. MQTT is a widely-used machine-to-machine connectivity protocol that helps these devices communicate and exchange messages. The wide adoption and popularity of the MQTT protocol led to its support in the BIG-IP version 13.0. MQTT is a publish/subscribe messaging protocol. A device such as a camera, heat sensor, lP-enabled light bulb, etc. can publish data to an intermediary module using the MQTT protocol. An application can then subscribe to this intermediary module and retrieve the published data. Intermediary modules are also known as message brokers. The BIG-IP with MQTT awareness can sit in front of the MQTT message brokers to provide scalability, security, visibility, and availability. Fig. 1 – Basic architecture of using the BIG-IP platform in an IoT environment. In an MQTT configuration, clients publish messages and the BIG-IP system parses those MQTT messages based on which it invokes MQTT specific iRule events if defined and performs connection based load balancing on the MQTT messages to a pool of message brokers. The message brokers then transport and route the messages to subscribing servers A typical BIG-IP MQTT configuration includes: MQTT pool of message brokers Are grouped together to receive and process traffic. After the pool is created, associate the pool with a virtual server. Some common open source message brokers examples are Mosquitto and VerneMQ iRules for MQTT Use iRules to exercise MQTT functionality, for example to log the messages that the BIG-IP system passes, or to pass the client certificate's common name in the CONNECT message Client SSL profile Use a Client SSL profile when you want the BIG-IP ® system to authenticate and decrypt/encrypt client-side application traffic Virtual server configured to use MQTT functionality For more details please refer to: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-iot-administration-13-0-0/1.html BIG-IP natively supports the MQTT protocol. BIG-IP has a full proxy architecture which makes BIG-IP itself an endpoint and an originator of the MQTT protocol. iRules take advantage of the deep understanding of the protocol and can be used at different events (specific moments within the session flow of a network connection, such as MQTT_CLIENT_INGRESS, MQTT_SERVER_INGRESS) to intelligently parse the MQTT protocol and make traffic decisions. Let’s explore some of the use cases using iRules such as load balancing and steering traffic based on a unique identified present within the MQTT protocol, preventing attacks based on TOPICS/LENGTH of a PUBLISH message, client authentication based on CN name present in the client certificate. Use Case: prevent MQTT DDoS attacks based on the below parameters Topic validation Validate the ‘TOPIC’ of a PUBLISH message and if it does not fit the validation criteria then drop the connection. This will prevent messages with bogus TOPICS from reaching the message brokers. And help in preventing MQTT DDoS attacks based on TOPIC. when MQTT_CLIENT_INGRESS { log local0. "CLIENT [MQTT::type]" if {[MQTT::type] eq "PUBLISH" } { # Check against a allowed topic. if { [MQTT::topic] eq "bogus/bogus" } { # Invalid topic log local0. " Topic is Invalid. Potential DDoS Attack -> Dropping Topic: [MQTT::topic]" drop } } } The above iRule can be enhanced to use data groups where the data groups will have the entire list of TOPICS and the [MQTT::TOPIC] can be checked against the data group MQTT PUBLISH message length validation An application will typically have knowledge about the size of the data that is being transmitted. Taking advantage of that knowledge the length of a PUBLISH message can be validated and if it does not satisfy the expected length then drop the connection. This will prevent large messages from reaching the message brokers and not overload the broker. when MQTT_CLIENT_INGRESS { log local0. "CLIENT [MQTT::type]" if {[MQTT::type] eq "PUBLISH" } { # Check length of message. if { [MQTT::length] > 100 } { # Invalid length log local0. " Length is Invalid. Potential DDoS Attack -> Dropping message: [MQTT::topic] : [MQTT::length]" drop } } } Use Case: pool selection/load balancing based on username as a unique identifier Use the username as a unique identifier to steer traffic to a message broker. This enables stickiness between an end user and a message broker by mapping a device/end user to a pool in the load balancer. The mapping helps in conditions where in a device needs to reconnect to the message broker on which the active client session lives and can use the state information present on the message broker to make decisions. when MQTT_CLIENT_INGRESS { log local0. "CLIENT [MQTT::type]" if {[MQTT::type] eq "CONNECT" } { # Select pool based on username, example license ID if { [MQTT::username] eq "D1111111" } { log local0. "Load balancing to pool MQTT-BrokerPool1" pool MQTT-BrokerPool1 } if { [MQTT::username] eq "D1111112" } { log local0. "Load balancing to pool MQTT-BrokerPool2" pool MQTT-BrokerPool2 } } } The above iRule can be enhanced to use data groups where the data groups will have the list of unique usernames. Multiple data groups can be defined, each one representing users for multiple Pools. The [MQTT::username] can be checked against the data group and based on that the pool selection can be made. Use Case: client certificate authentication over TLS BIG-IP can terminate MQTT encrypted SSL/TLS messages and then send the un-encrypted traffic to the backend Broker. This allows the Broker to scale as it can offload all SSL/TLS functions and configuration to the BIG-IP. In addition to terminating SSL/TLS the BIG-IP can use iRules to perform Client Certificate Authentication. The BIG-IP can embed the client CN name from the client certificate into the backend connection along with the username for authentication by the back-end Broker. when CLIENT_ACCEPTED { set cn "" } when CLIENTSSL_CLIENTCERT { log local0. " Parsing X509 Info for SSL Client Cert CN Name" set cn [findstr [X509::subject [SSL::cert 0]] "CN=" 3 ","] log local0. "Found Client Cert Common Name (CN) : $cn" } when MQTT_CLIENT_INGRESS { log local0. "MQTT Client MmessageTtype [MQTT::type]" if {[MQTT::type] == "CONNECT"} { log local0. "Connecting to Broker" if {$cn == ""} { # if we didn't see a client cert, return an authentication error MQTT::drop MQTT::respond type CONNACK return_code 5 MQTT::disconnect } else { log local0. "Passing Username and CN to Backend for Authentication" log local0. "MQTT Username: [MQTT::username]" log local0. "Username: [MQTT::username] CN: $cn" set mqttuser [MQTT::username] MQTT::username "$mqttuser $cn" } } } Conclusion Bookmark this page if you are interested in learning more. We will be update this blog with new compelling IoT features developed by F5 for the upcoming BIG-IP releases. Do you have a suggestion for an IoT related topic that you would like for us to cover? Please leave a comment on this post if you do. References https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-iot-administration-13-0-0/1.print.html https://devcentral.f5.com/s/articles/lightboard-lessons-iot-on-big-ip-24923?tag=lbl https://devcentral.f5.com/s/articles/the-iot-ready-platform https://f5.com/resources/white-papers/tmos-redefining-the-solution https://devcentral.f5.com/s/articles/the101-irules-101-events-amp-priorities https://en.wikipedia.org/wiki/MQTT https://mosquitto.org/Lightboard Lessons: Exploiting Cellular IoT Gateways
Critical emergency services such as police, fire, and medical manage their fleets with vulnerable cellular IoT devices. “Vulnerable” doesn’t have to mean a vulnerability within the hardware or software, although we suspect that is the case in some makes and models. In this instance, "vulnerable" can mean being susceptible to remote attacks because of weak access control and use of default credentials. An attacker can use these vulnerable device to launch attacks, as we have seen with thingbots like Mirai and Reaper, or they can use that access for nefarious purposes to spy, redirect commands in the case of a fleet taking orders from a remote command, or shut the system off, effectively disabling operations. In this video, John outlines the problem of weak authentication in widely-used cellular gateway devices. Help spread the word, and for the love of all things security, change your default usernames and passwords! Related Resources: F5 Labs Report: Breaking Down the Door to Emergency Services through Cellular IoT Gateways F5 Labs Report: Leveraging Government Transparency to Find Vulnerable Cellular GatewaysPost of the Week: Explaining the KRACK Vulnerability
In this "Post of the Week" video, we discuss the KRACK vulnerability that targets mobile devices and wireless routers. This vulnerability targets the WPA2 security protocol that allows for encryption between a mobile device and a wireless router. As the mobile device negotiates encrypted communication with the router, an attacker can force the mobile device to use very weak encryption (essentially no encryption at all) and thus see all the traffic between the device and the router. We also talk about ways you can help avoid this problem. Enjoy! Related Resources New Threat May Slip Through the KRACK in BYOD Policies (F5 Labs) Scary Candy Week: KRACK and ROCALightboard Lessons: Connecting Cars with BIG-IP
I light up how BIG-IP and Solace work together in a MQTT connected car infrastructure. ps Related: Using F5 BIG-IP and Solace Open Data Movement technology for MQTT message routing and delivery Lightboard Lessons: What is MQTT? Solace and F5: Partnering for Better IoTUsing F5 BIG-IP and Solace Open Data Movement technology for MQTT message routing and delivery
The "Internet of Things" (IoT) has the potential to not just impact the way we live and work, but to disrupt entire industries. Some of the major industries that are driving innovation in IoT include manufacturing, transportation, and utilities. In this post I’ll talk about an example of how digital manufacturing is helping automobiles be more intelligent. There are millions of connected automobiles that have software running on them: from programs that keep GPS maps up to date to sensors sending vehicle speeds or temperature information. This information typically is being sent to a centralized management system that enables intelligent decisions, and those back-end systems also need to send data, instructions, and updates to the cars. We are actively working with a leading multinational automotive company. In this deployment the management system uses MQTT to send notifications to cars that a new software update is available for download. It is critical that these messages are received by the connected cars, but message delivery can be delayed if the car can’t be reached because it’s out of range, or driving through a tunnel, or even if cellular networks are congested. Using the Solace message broker To ensure eventual delivery in such situations, you can have the management system send messages to a message broker that in turn distributes them to intended recipients. This decouples your architecture so the many elements of the management system don’t need to worry about the specific destinations to which each message must be delivered, nor track delivery status. They simply send a message to the broker which A) takes care of routing it to requisite destinations, and B) stores a copy of it until every vehicle that needs it has confirmed receipt. Basic IIoT architecture for connected automobiles Before diving deeper, let’s look at the architecture that is used in the above use case. The idea is the same, but to support the numbers of connected vehicles and volume of data involved, it’s necessary to implement multiple message brokers. This architecture is provided by Solace which uses a novel architecture that enables efficient publish/subscribe distribution of data and can scale to millions of connected devices. (see Fig 1.). Back-end applications connect to a single broker (core message broker) to send a message to any vehicle, and can use messaging techniques preferred by IT applications such as JMS, AMQP and Node.js. The core message broker is communicating to several edge message brokers through internal messaging. The data for a particular vehicle is routed through one edge message broker and delivered to the vehicle in the matter conducive for it, in this case MQTT. In the diagram, Vehicle 1 connects to Message Broker 1. That means that messages sent from the management system to the core message broker that are intended for Vehicle 1 only need to go to Message Broker 1 Fig. 1 – Basic IIoT architecture for connected automobiles This two-tier approach provides a simple and powerful scaling architecture for north-south communication, since more connected cars can be added by adding more edge message routers without affecting the existing system. BIG-IP and persistence For this architecture, we’re aiming to achieve two things: First, we want to relieve the management system of the burden of keeping track of message delivery to potentially millions of vehicles. The Solace message broker uses MQTT QoS Level 1 which guarantees that a message will be delivered at least once to the receiver. The message is persisted in the edge message broker which allows the backend IoT application to publish messages with confidence that they will eventually reach their destination, but without needing to keep track of message delivery status. Second, we need to make sure that the vehicle connects to the right message broker so it can receive its messages. This can be achieved by managing a 1:1 mapping between the edge message broker and the vehicle. Fig. 2 – F5 BIG-IP in the IoT architecture BIG-IP version 13+ helps to achieve the 1:1 mapping with support for MQTT message parsing. It sits in front of the message broker and parses the MQTT messages – using iRules – exchanged between the vehicle to the message broker. Data groups on the BIG-IP are used to map a vehicle using a unique Identifier to a pool of message brokers. Using iRules every MQTT message is parsed, then the data group lookup routes the data to the correct pool of message brokers. This helps to achieve a “sticky” load balancing solution so that when a vehicle comes back online it will always get routed and connected to the correct message brokers where the connection state for that vehicle is known to be maintained. We say a “pool of message brokers” in order for the brokers to provide a highly-available service. Here is some sample code of an iRule that helps with achieving persistence or sticky load balancing: when MQTT_CLIENT_INGRESS { log local0. "CLIENT [MQTT::type]" if {[MQTT::type] eq "CONNECT" } { # Select pool based on vehicle ID if { [MQTT::username] eq "D1111111" } { log local0. "Load balancing to pool MQTT-BrokerPool1" pool MQTT-BrokerPool1 } if { [MQTT::username] eq "D1111112" } { log local0. "Load balancing to pool MQTT-BrokerPool2" pool MQTT-BrokerPool2 } } } Conclusion IoT use cases which benefit from having a guaranteed delivery of messages can take advantage of F5’s persistence capabilities. The architecture described above means that specific edge broker instances will maintain 'state' for specific connected vehicles. This requires the MQTT load-balancing to be sticky across sessions. BIG-IP version 13+ supports MQTT message parsing using iRules and thereby provides a key functionality in achieving the end-to-end goal of the solution for this type of architecture. The industries that are embracing “Internet of Things” applications are still in the early stages of innovation, but market leaders are architecting now for scale and resilience so they can automate more and more processes with a single infrastructure. The automaker in this example has chosen F5’s BIG-IP solution for 1:1 mapping of cars to message brokers, and Solace’s Open Data Movement technology as the MQTT infrastructure for message routing and delivery. The combination provides an elegant solution that can scale to millions of connections to support an increasing number of message exchanges between the vehicles and back end systems as their telematics and in-car services get more sophisticated.What to Expect in 2017: Mobile Device Security
We are mobile, our devices are mobile, the networks we connect to are mobile and the applications we access are mobile. Mobility, in all its iterations, is a huge enabler and concern for enterprises and it'll only get worse as we start wearing our connected clothing to the office. If the last 10 years wasn’t warning enough, 2017 will be a huge year for mobile…again. Every year, it seems, new security opportunities, challenges and questions surround the mobile landscape. And now it encompasses more than just the device that causes phantom vibration syndrome, it now involves the dizzying array of sensors, devices and automatons in our households, offices and municipalities. Mobile has infiltrated our society and our bodies along with it. So the security stakes are high. The more we become one with our mobile devices, the more they become targets. It holds our most precious secrets which can be very valuable. We need to use care when operating such a device since, in many ways, our lives depend on it. And with the increased automation, digitization and data gathering, there are always security concerns. So how do we stay safe? The consumerization of IT technologies has made us all administrators of our personal infrastructure of connected devices. Our digital self has become a life of its own. As individuals we need to stay vigilant about clicking suspicious links, updating software, changing passwords, backing up data, watching financial accounts, having AV/FW and generally locking down devices like we do the doors to our home. Even then, the smartphone enabled deadbolt can be a risk. And we haven’t even touched on mobile payment systems, IoT botnets or the untested, insecure apps on the mobile phone itself. Cybersecurity is a social issue that impacts us all and we all need to be accountable. For enterprises, mobile devices carry an increased risk, especially personal devices connecting to an internal network. From regulatory compliance to the disgruntled employee, keeping sensitive information secret is top concern. BYOD policies and MDM solutions help as does segmenting those devices away from critical info. And the issue isn’t so much seeing restricted information, especially if your job requires it, it is more about unauthorized access if the device is compromised or lost. Many organizations have policies in place to combat this, including a total device wipe…which may also blast your personal keepsakes. The endpoint security market is maturing but won’t fill the ever-present security gaps. From your workforce to your customers, your mobile web applications are also a target. The Anti-Phishing Working Group (APWG) reports a 250 percent jump in the number of detected phishing websites between October 2015 and March 2016. Around 230,000 unique phishing campaigns a month, many aimed at mobile devices arriving as worrisome text messages. Late 2016 saw mobile browsing overtake desktop for the first time and Google now favors mobile-friendly websites for its mobile search results. A double compatibility and SEO whammy. And those two might not be the biggest risk to an organization since weakest link in the security ecosystem might be third-party vendors and suppliers. On the industrial side, tractors, weather sensors, street lights, HVAC systems, your car and other critical infrastructure are now mobile devices with their own unique security implications. The Industrial Internet of Things (IIoT) focuses on industrial control systems, device to network access and all the other connective sensor capabilities. These attacks are less frequent, at least today, but the consequences can be huge – taking out industrial plants, buildings, farms, and even entire cities. The Digital Dress Code has emerged and with 5G on the way, mobile device security takes on a whole new meaning. ps Related: Mobile Trends For 2017 And Beyond Perspectives on Securing Mobile and Social Business, 12 Months On RSAC17: More ransomware and IoT-enabled attacks on the way, warns expert Mobile Malware Milestone Mobile banking and how to stay secure What Does Mobile Mean, Anyway? BYOD - concentrate on the apps, not the devices 10 Security Trends To Watch For At RSA 2017Lightboard Lessons: IoT on BIG-IP
As more organizations deploy IoT applications in their data centers and clouds, they're going to need their ADC to understand the unique protocols these devices use to communicate. In this Lightboard Lesson, I light up how IoT protocol MQTT (Message Queuing Telemetry Transport) works on BIG-IP v13. iRules allow you to do Topic based load balancing along with sensor authentication. And if you missed it, here is the #LBL on What is MQTT? ps Related: Lightboard Lessons: What is MQTT? Security Trends in 2016: Securing the Internet of Things The Intruders of Things The IoT Ready Platform Using F5 BIG-IP with IBM MessageSight
