Fortnite: Why Kids Love It and What Parents Need to Know

Fortnite: Battle Royale

 

Fortnite: Battle Royale is the hottest video game for kids right now. More than 125 million people have downloaded the game and it’s estimated that 3.4 million play it monthly. But while the last-man-standing battle game is a blast to play, it also has parents asking a lot of questions as their kids spend more and more time immersed in the Fortnite realm.

Why kids love it

A few hours on Fortnite and you can easily see why kids (and adults) love it. The game drops up to 100 players onto an island, where they try to find weapons to defend themselves and try to eliminate other players. The battlefield gradually shrinks, forcing players into encounters with each other until just one player remains and becomes the winner.

Even though it’s a battle, the Fortnite characters and interface are colorful and cartoon-like and there’s no blood or gore. The game itself possesses an inherent sense of humor and personality that’s lighthearted yet still competitive. The app is free to download, but players can outfit their characters (for purchase) in an array of battle fashions and any number of fun dances.

Ultimate gaming mash-up

Fortnite: Battle Royale

One reason kids love Fortnite: Battle Royale is that it’s the perfect survival mash-up of several popular media titles: The Hunger Games movie, Call of Duty video game, the first Fortnite (Fortnite: Save the World) video game, and the game PUBG (PlayerUnknownBattlegrounds). Fortnite: Battle Royale takes elements from all of these favorite storylines and game interfaces.

The game has a lot of fun attached for sure. Fortnite’s interface and hilarious character moves can be just as much fun to watch as it is to play. However, as with any other wildly popular, multi-player video game, there are some red flags families need to be aware of.

Fortnite: What to look out for

Excessive screen time. Because of the way Fortnite is structured, kids can easily burn through hours a day if left unmonitored. Some parents have reported their kids becoming Fortnite obsessed, even addictedSuggestion: Pay attention to the amount of time your kids spend playing. If your child is playing on Xbox, PlayStation, or Switch, you can turn on parental controls to limit gaming sessions. Another option, for PC, tablets, and mobile devices, is monitoring software that allows parents to set time limits for apps and websites.Fortnite: Battle Royale

Chat feature. Fortnite is a multi-player game, which means kids play against other gamers they may not know. So, Fortnite’s chat feature carries some potential safety issues such as foul language, potentially befriending an imposter, and cyberbullying. Suggestion: Talk to your child about this aspect of the game and the dangers. Spend time and sit in on a few games and listen to the banter. Then, make the best decision for your family. To turn chat off, open the Settings Menu in the top right of the main Fortnite page, go to the Audio Tab and turn it off.

In-app purchases. Fortnite is free to download but can get expensive quickly. Kids can use virtual currency (purchased via credit card) to access animations, weapons, and outfits for their characters. These items aren’t needed to win the game, but they allow a player to express his or her personality within the game, which is especially important to kids. Some parents have reported finding hundreds of dollars in unauthorized purchases on their credit cards due to Fortnite’s array of in-app purchases. Suggestion: If you know your child is passionate about Fortnite, take away the spending temptation by blocking his or her ability to make in-app purchases. Or, set a weekly limit on purchases.

Fortnite: Battle Royale

Increased anxiety/stress levels. Fortnite’s game structure is a highly-competitive, fast-moving game that renders only one winner. This means, as a solo player, the odds are stacked against you. Play Fortnite enough, and lose enough, and rage can surface. If your child is prone to anxiety or stress, Fortnite may not be the best environment. Suggestion: Monitor your child’s mood. Discuss the emotional highs and lows potentially associated with Fortnite and put some healthy parameters — that address both the types of content and time limits — around gaming habits.

Unsure about allowing your kids to play (or continue playing) Fortnite? Talk to them about it. Join in or watch your child play. Find out what your child loves about the game and if his or her demeanor changes during or after playing. Monitor the amount of time as well. Once you’ve gathered the facts as they pertain to your child, decide how much (or how little) of the Fortnite world is best for your family.

Want to connect more to digital topics that affect your family? Stop by ProtectWhatMatters.online. Also, join the digital security conversation on Facebook.

Toni Birdsong is a Family Safety Evangelist to McAfee. You can find her onTwitter @McAfee_Family. (Disclosures)

The post Fortnite: Why Kids Love It and What Parents Need to Know appeared first on McAfee Blogs.

80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals

The author thanks Shaun Nordeck, MD, for his assistance with this report.

With the explosion of growth in technology and its influence on our lives, we have become increasingly dependent on it. The medical field is no exception: Medical professionals trust technology to provide them with accurate information and base life-changing decisions on this data. McAfee’s Advanced Threat Research team is exploring these devices to increase awareness about their security.

Some medical devices, such as pacemakers and insulin pumps, have already been examined for security concerns. To help select an appropriate target for our research, we spoke with a doctor. In our conversations we learned just how important the accuracy of a patient’s vital signs is to medical professionals. “Vital signs are integral to clinical decision making” explained Dr. Shaun Nordeck. Bedside patient monitors and related systems are key components that provide medical professionals with the vital signs they need to make decisions; these systems are now the focal point of this research.

Exploring the attack surface

Most patient monitoring systems comprise at minimum of two basic components: a bedside monitor and a central monitoring station. These devices are wired or wirelessly networked over TCP/IP. The central monitoring station collects vitals from multiple bedside monitors so that a single medical professional can observe multiple patients.

With the help of eBay, we purchased both a patient monitor and a compatible central monitoring station at a reasonable cost. The patient monitor monitored heartbeat, oxygen level, and blood pressure. It has both wired and wireless networking and appeared to store patient information. The central monitoring station ran Windows XP Embedded, with two Ethernet ports, and ran in a limited kiosk mode at start-up. Both units were produced around 2004; several local hospitals confirmed that these models are still in use.

The two devices offer a range of potential attack surfaces. The central monitoring station operates fundamentally like a desktop computer running Windows XP, which has been extensively researched by the security community. The application running on the central monitoring station is old; if we found a vulnerability, it would likely be tied to the legacy operating system. The patient monitor’s firmware could be evaluated for vulnerabilities; however, this would affect only one of the two devices in the system and is the hardest vector to exploit. This leaves the communication between the two devices as the most interesting attack vector since if the communication could be compromised, an attack could possibly be device independent, affecting both devices by a remote attack. Given this possibility, we chose networking as the first target for this research. Dr. Nordeck confirmed that if the information passing to the central monitoring system could be modified in real time, this would be a meaningful and valid concern to medical professionals. Thus the primary question of our research became “Is it possible in real time to modify a patient’s vitals being transmitted over the network?”

Setup

When performing a vulnerability assessment of any device, it is best to first operate the device as originally designed. Tracking vital signs is the essence of the patient monitor, so we looked for a way to accurately simulate those signs for testing. Many hardware simulators are on the market and vary drastically in cost. The cheapest and easiest vital sign to simulate turned out to be a heartbeat. For less than $100 we purchased an electrocardiogram (ECG) simulator on eBay. The following image illustrates our test network:

In our test bed, the patient monitor (left), central monitoring station (right), and a research computer (top) were attached to a standard switch. The research computer was configured on a monitor port of the switch to sniff the traffic between the central monitoring device and the patient monitor. The ECG simulator was attached to the patient monitor.

Reconnaissance

With the network configured, we turned to Wireshark to watch the devices in action. The first test was to boot only the central monitor station and observe any network traffic.

In the preceding screenshot a few basic observations stand out. First, we can see that the central station is sending User Datagram Protocol (UDP) broadcast packets every 10 seconds with a source and destination port of 7000. We can also see clear-text ASCII in the payload, which provides the device name. After collecting and observing these packets for several minutes, we can assume this is standard behavior. Because the central station is running on a Window XP embedded machine, we can attempt to verify this information by doing some quick reverse engineering of the binaries used by the application. After putting several libraries into Interactive Disassembler Pro, it is apparent that the symbols and debugging information has been left behind. With a little cleanup and work from the decompilers, we see the following code:

This loop calls a function that broadcasts Rwhat, a protocol used by some medical devices. We also can see a function called to get the amount of time to wait between packets, with the result plugged into the Windows sleep function. This code block confirms what we saw with Wireshark and gives us confidence the communication is consistent.

Having gained basic knowledge of the central monitoring station, the next step was to perform the same test on the patient monitor. With the central station powered down, we booted the patient monitor and watched the network traffic using Wireshark.

We can make similar observations about the patient monitor’s broadcast packets, including the 10-second time delay and patient data in plaintext. In these packets we see that the source port is incrementing but the destination port, 7000, is the same as the central monitoring station’s.  After reviewing many of these packets, we find that offset 0x34 of the payload has a counter that increments by 0xA, or 10, with each packet. Without potentially damaging the patient monitor, there is no good way to extract the firmware to review its code. However, the central monitoring station must have code to receive these packets. With a bit of digging through the central station’s binaries, we found the section parsing the broadcast packets from the patient monitor.

The first line of code parses the payload of the packet plus 12 bytes. If we count in 12 bytes from the payload on the Wireshark capture, we can see the start of the patient data in clear text. The next function called is parse_logical_name, whose second parameter is an upper limit for the string being passed. This field has a maximum length of 0x20, or 32, bytes. The subsequent code handles whether this information is empty and stores the data in the format logical_name. This review again helps confirm what we see in real time with Wireshark.

Now that we understand the devices’ separate network traffic, we can look at how they interact. Using our network setup and starting the ECG simulator we can see the central monitor station and the patient monitor come to life.

With everything working, we again use Wireshark to examine the traffic. We find a new set of packets.

In the preceding screen capture we see the patient monitor at IP address 126.4.153.150 is sending the same-size data packets to the central monitoring station at address 126.1.1.1. The source port does not change.

Through these basic tests we learn a great deal:

  • The two devices are speaking over unencrypted UDP
  • The payload contains counters and patient information
  • The broadcast address does not require the devices to know each other’s address beforehand
  • When the data is sent distinct packets contain the waveform

Attacking the protocol

Our reconnaissance tells us we may have the right conditions for a replay attack. Such an attack would not satisfy our goal of modifying data in real time across the network; however, it would provide more insight about the requirements and may prove useful in reaching our goal.

After capturing the packets from the simulated heartbeat, we attempted to replay the captures using Python’s Scapy library. We did this with the patient monitor turned off and the central monitoring station listening for information. After several attempts, this test was unsuccessful. This failure shows the system expects more than just a device sending data packets to a specific IP address.

We examined more closely the packets that are sent before the data packets. We learned that even though the packets are sent with UDP, some sort of handshake is performed between the two devices. The next diagram describes this handshake. 

 

In this fanciful dialog, CMS is the central monitoring system; PM is the patient monitor.

To understand what is happening during the handshake, we can relate each phase of this handshake to that of a TCP three-way handshake. (This is only an analogy; the device is not actually performing a TCP three-way handshake.)

The central monitoring station first sends a packet to port 2000 to the patient monitor. This can be considered the “SYN” packet. The patient monitor responds to the central station; notice it responds to the source port of the initial request. This can be considered the “SYN,ACK.” The central station sends the final “ACK,” essentially completing a three-way (or three-step) handshake. Directly following this step, the patient monitor sends another packet to the initial port of the “SYN” packet. The central monitor responds to the patient monitor on port 2000 with a new source port. Immediately following, we see the data packets being sent to the new source port, 3627, named in the previous exchange.

This exam provides insight into why the replay attack did not work. The central station defines for each connection which ports will be open for the incoming data; we need to consider this when attempting a replay attack. Modifying our previous Scapy scripts to account for the handshake, we retested the replay attack. With the new handshake code in place, the test still failed. Taking another look at the “SYN,ACK” packets provides a potential reason for the failure.

At offset 0x3D is a counter that needs to be incremented each time one of these packets is sent. In this case the patient monitor’s source IP address is embedded in the payload at offsets 0x2A and 0x30. This embedded IP address is not as important for this attack because during the replay our scripts can become the patient monitor’s IP; however, this will become more important later. The newly discovered counter needs to be accounted for and incremented.

Emulating a patient monitor

By taking these new findings into account our replay attack becomes successful. If we can observe a certain ECG pattern, we can play it back to the central monitoring station without the patient monitor on the network. Thus we can emulate the function of the patient monitor with any device. The following video demonstrates this emulation using a Raspberry Pi. We set our Scapy scripts to load after booting the Pi, which mimics the idle function of the patient monitor. When the central monitor requests information about the patient’s vitals, the Pi provides the station with an 80-beats-per-minute wave form. This also works with the other vital signs.

Impact of emulation

Although we have not yet reached our goal of real-time modification, we must consider the implications of this type of attack. If someone were to unplug the monitor of a stable patient and replace it with a device that continued to report the same stable vitals, would that cause any harm? Probably not immediately. But what if the stable patient suddenly became unstable? The central station would normally sound an alarm to alert medical personal, who could take appropriate action. However, if the monitor had been replaced, would anyone know help was needed? The patient monitor also normally sounds alarms that might be heard in and outside of the patient’s room, yet if the monitor was replaced, those alarms would be absent.

In hospitals, nurses and other personal generally make periodic checks even of stable patients. So any deception might not last long, but it might not need to. What if someone were trying to kidnap a patient? A kidnapper would alert fewer people than would be expected.

Switching from a real patient monitor to an emulator would cause a short loss in communication from the patient’s room to the central monitoring station. Is this enough to make the scenario unrealistic or not a threat? We asked Dr. Nordeck if a short loss in connection could be part of a reasonable scenario. “A momentary disconnection of the ECG would likely go unnoticed as this happens often due to patient movement or changing clothes and, as long as it is reconnected, will be unlikely to cause an alert,” he said.

Modifying vitals in real time

Although emulating the patient monitor is interesting, it did not accomplish our goal of making real-time modifications. Using what we learned while testing emulation, could we perform real-time injection? To answer this question, we must first understand the difference between emulation and real-time injection.

Emulation requires a deeper understanding of how the initial connection, the handshake, between the two devices occurred. When considering real-time modification, this handshake has already taken place. But an attacker would not know which port the data packets are being sent too, nor any of the other ports used in the data stream. Plus, because the real patient monitor is still online, it will constantly send data to the central monitoring station.

One way to account for these factors is to use Address Resolution Protocol (ARP) spoofing. If the patient monitor is ARP spoofed, then the attacker, instead of the central monitoring station, would receive the data packets. This step would allow the attacker to determine which ports are in use and stop the patient monitor’s data from getting to the central monitoring station. Because we have already shown that emulation works, the attacker simply has to send replacement data to the central station while appearing as the patient monitor.

For example, consider the following original packet coming from the patient monitor:

The patient monitor sends a packet with the patient’s heartbeat stored at offset 0x71 in the payload. The patient monitor in this screen capture is at IP address 126.4.153.150. An attacker can ARP spoof the patient monitor with a Kali virtual machine.

The ARP packets indicate that the central station, IP address 126.1.1.1, is at MAC address 00:0c:29:a1:6e:bf, which is actually the Kali virtual machine. Wireshark recognizes two MACs with the same IP address assigned and highlights them, showing the ARP spoof.

Next the attacker from the virtual machine at address 126.4.153.153 sends false information to the central monitoring station, still at address 126.1.1.1. In this example, offset 0x71 has been changed to 0x78, or 120. (The attacker could choose any value; the following demo videos use the heartbeat value 180 because it is more alarming.) Also notice the IP address stored in the payload, which we discovered during the reconnaissance phase. It still indicates this data is coming from the original patient monitor address, which is different from the IP address on the packet’s IP header. Due to this implementation, there is no need for the attacker to spoof their IP address for the attack to be successful.

Two videos show this modification happening in real time:

 

Impact of real-time modification

Although the monitor in the patient’s room is not directly affected, real-time modification is impactful because medical professionals use these central stations to make critical decisions on a large number of patients—instead of visiting each room individually. As long as the changes are believable, they will not always be verified.

Dr. Nordeck explains the impact of this attack: “Fictitious cardiac rhythms, even intermittent, could lead to extended hospitalization, additional testing, and side effects from medications prescribed to control heart rhythm and/or prevent clots. The hospital could also suffer resource consumption.” Dr. Nordeck explained that short changes to a heartbeat would generally trigger the nurse or technician monitoring the central station to page a doctor. The doctor would typically ask for a printout from the central station to review the rhythm. The doctor might also order an additional test, such as an EKG, to verify the rhythm. An EKG, however, would not likely capture an abnormal rhythm if it is intermittent, but the test might reveal an underlying cause for intermittent arrythmia. Should the rhythm recur intermittently throughout the day, the doctor might make treatment decisions based on this erroneous printout.

The American Heart Association and American College of Cardiology publish guidelines that hospitals are to follow, including for “intermittent cardiac rhythms,” seen in this chart:

A decision tree for treating an intermittent heart rate. Source: American Heart Association.

The first decision point in this tree asks if the patient is hemodynamically stable (whether the blood pressure is normal). This attack does not affect the bedside monitor. A nurse might retake the patient’s blood pressure, which would be normal. The next decision point following the “Yes” path is a diagnosis of focal atrial tachycardia. Regardless of the medical terms and answers, the patient is issued medication. In the case of a network attack, this is medication the patient does not need and could cause harm.

Conclusion

This research from McAfee’s Advanced Threat Research team shows it is possible to emulate and modify a patient’s vital signs in real time on a medical network using a patient monitor and central monitoring station. For this attack to be viable, an attacker would need to be on the same network as the devices and have knowledge of the networking protocol. Any modifications made to patient data would need to be believable to medical professionals for there to be any impact.

During our research we did not modify the patient monitor, which always showed the true data; but we have proven the impact of an attack can be meaningful. Such an attack could result in patients receiving the wrong medications, additional testing, and extended hospital stays—any of which could incur unnecessary expenses.

Both product vendors and medical facilities can take measures to drastically reduce the threat of this type of attack. Vendors can encrypt network traffic between the devices and add authentication. These two steps would drastically increase the difficulty of this type of attack. Vendors also typically recommend that medical equipment is run on a completely isolated network with very strict network-access controls. If medical facilities follow these recommendations, attackers would require physical access to the network, greatly helping to reduce the attack surface.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. Through responsible disclosure we aim to assist and encourage the industry toward a more comprehensive security posture. As part of our policy, we reported this research to the vendor whose products we tested and will continue to work with other vendors to help secure their products.

The post 80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals appeared first on McAfee Blogs.

How Valuable is Your Healthcare Data?

Health care is a hot topic in security right now. A quick search for “hospital ransomware” returns a laundry list of news reports on hospitals as targets of cyberattacks. However, it is not just ransomware that people need to worry about. In the report Health Warning: Cyberattacks Are Targeting the Health Care Industry, our McAfee Labs team digs into the dark underbelly of cybercrime and data loss involving health care records. In this case, the dark refers to the dark web.

Following up on the Hidden Data Economy report, we looked further to see if medical data was showing up for sale. We found dark web vendors offering up medical data records by the tens of thousands. One database for sale offered information on 397,000 patients!

2016-10-27_17-36-06

These databases contained not only names, addresses, and phone numbers of patients, but also data about their health care insurance providers and payment card information.

What’s it worth?

Of course, for this to be worth a cybercriminal’s time, they must be able to profit from it. We are finding that health care records to be a bit less valuable than records such as payment card records that contain financial information. The going price for a single record of information on a user that includes name, Social Security number, birth date, account information such as payment card number (referred to as fullz in dark web lingo) can range from $14 to $25 per record. Medical records sell for a much lower price, anywhere from a fraction of a cent to around $2.50 per record.

Does this mean medical records are not as valuable? Although not as lucrative as fullz, medical record information has  higher value than just a username/password record when sold on the dark web. We think that sellers are trying to maximize their gain from the data theft. In one underground market forum, a seller listed 40,000 medical records for $500, but specifically removed the financial data and sold that separately.

Why is the health care industry a target?

Although there are regulations and guidelines for the health care industry to protect patient information, the industry itself faces many challenges. Foremost, the focus of the majority of health care workers is the treatment of patients. Because they are dealing with life and death situations, the equipment used to treat patients must be working and available at a moment’s notice. This means there is often little time to install a patch or an update on a piece of medical equipment. The equipment may also be running an outdated operating system that simply cannot be patched to protect against the latest threats. It is not uncommon to see medical equipment running on Windows 95. The medical industry is also subject to FDA regulations and approvals. There may be equipment that is approved by the FDA only on an older operating system and would need to be recertified if updated.

How do I stay safe?

Unfortunately, these data breaches are outside the control of the average person. Health care providers typically use the information they collect from you for your treatment, so you cannot withhold your home address or phone number. As a consumer, you need to be alert for health care data breaches that potentially impact you.

  • Pay attention to the news: Once discovered, medical data breaches tend to make the evening news. Even if you went to a health care provider only once to get an x-ray because you thought you broke your thumb and that provider experiences a data breach, odds are your information was compromised.
  • Monitor your credit score: A common use for resold information is the opening of credit cards or bank accounts. Subscribing to a credit-monitoring service will help you know if a new account has been opened without your knowledge.
  • Watch out for phishing: If your contact information has been stolen, you are almost certain to be the target of numerous phishing attempts. Keep an eye out for suspicious emails and text messages. You can read one of my previous blogs for tips on how to spot a phishing attempt.

The nature of today’s digital world can unfortunately cause our personal and private data to be leaked. If you stay vigilant, you can reduce the impact these breaches will have on your life.

Stay on top of the latest consumer and mobile security threats by following me and @IntelSec_Home on Twitter, and “Like” us on Facebook.

Stay Safe!

The post How Valuable is Your Healthcare Data? appeared first on McAfee.

How to Secure the Future of the Internet of Things

iot5

The world of security for the Internet of Things just became more complex. IoT devices are no longer a potential threat to their owners; now they pose a significant threat to everything connected to the Internet.

The old IoT security problem

For the past year, the cybersecurity and IoT communities have been at odds regarding how to keep devices from harming their owners. Much of the focus emerged around industrial controls and transportation equipment. Vulnerable industrial controls devices could cause cascading effects to power stations, water distribution, chemical plants, heavy machinery, and other industrial facilities, posing a threat to workers or downstream users. There have been hacks, compromises, and stern warnings. Concerned governments are putting pressure and establishing requirements to protect services at a national level.

Vehicles, most notably airplanes and smart cars, have taken the bulk of the public’s attention. Hacks against Jeep, Tesla, and Volkswagen have shown how doors can be unlocked and total operating control commandeered with steering, breaks, and acceleration taken over by an attacker. A car that is rendered unusable by its owner or made to crash and injure occupants is frightening but apparently trivial if you do not own that type of vehicle. The public appears to be entertained by these research exploits but not too concerned. The danger may seem beyond the everyday consumer and the effects are likely limited to only those who could afford such conveyances.

On the low-cost side, home appliances, wearables, toys, and drones are already a part of the everyday consumer world, but hacking a smart toaster or rice cooker seems harmless, beyond some burnt starch.

Eventually, we will face more risks than we can imagine. As IoT devices are woven into the fabric of people’s daily lives, we will be at risk of their misuse. In the future they will begin to control the stoplights on the way to work, the equipment in the emergency room, control of progressively more vehicles on the road and in the sky, and the distribution of such necessities such as electricity, food, medicine, water, and communications. We will begin to understand how these little technical minions become critical to the smooth delivery of services in our future digital lives.

This is the space where thought-leading IoT manufacturers are working feverishly. The automobile industry in particular has been quick to invest in security to ensure their products do not cause accidents. Such work has begun, but it still has a long way to go in cars and across all the other billions of devices we will weave into our lives and businesses in the next few years.

The next generation of IoT devices is appearing and will work to help protect our property, monitor our health, automate our homes, keep our children safe, increase our communication, eliminate time-wasting chores, make us more efficient, and optimize our businesses. A great future to be sure, but it will need to be trustworthy and secure, as our reliance on the smallest elements will ultimately impact the biggest parts of our lives. These are all known and accepted security challenges in the world of IoT. This is not the end of the security story, only the beginning.

The new IoT security problem

We now face a new set of problems with IoT. Unlike the known challenges, in which IoT devices might impact local owners and bystanders, the new threat is a powerful weapon that can be pointed at anything connected to the Internet. Recent distributed denial of service (DDoS) attacks have been fueled by hacked IoT devices, called bots. DDoS attacks saturate Internet-connected devices and services to bring them down or make them unavailable. Such attacks have been around for years, and in fact were some of the first types of Internet attacks; but the scale is now changing the game at a pace not tenable for security workarounds.

The game has changed. These IoT DDoS attacks are typically run by “bot herders.” These herders compromise devices and install malware that allows them to be remotely controlled. By pointing hundreds or thousands of devices to flood a target with requests and data, they can overwhelm it to the point it can no longer maintain functions. There are several anti-DDoS services that offer protection for a price. But the scale of the new IoT-backed attacks, which are larger than anything ever seen, makes protection difficult and costly. Josh Shaul, Akamai’s vice president of web security, warned that if such an attack were sustained, it could cost the victim millions of dollars in cybersecurity services to stay online.

Traditionally, PCs were the prime targets to turn into bots, as many people did not bother with installing antimalware products. But over the last few years, PCs have become much better protected and thus difficult for bot herders to consistently control. The other problem is the shift to laptops. A bot is good only if it is online, can receive instructions from its master, and then continuously execute those orders. Laptops do not fit this model well, as they spend much of their time off, to save battery life.

What bot herders really want is a massive number of devices that are easy to hack, are ignored by their owners, and are constantly connected to the Internet. Recent attacks have proven IoT devices are the perfect solution for cybercriminals.

The rise of IoT is a dream come true for bot herders. Most IoT devices are not powerful enough to have any type of antimalware service. A majority of consumer products come with a default login and password that are published by the manufacturer and easily found on the web. Many stay continuously connected to the Internet and users rarely monitor or update these devices, especially consumers. The biggest factor is around scale. Unlike the hundreds or thousands of PCs that might be in a herd, IoT botnets can number in the hundreds of thousands!

With legions of exploitable devices, attackers are mustering massive DDoS armies and the results of IoT botnets are devastating.

How to secure the future of IoT

The problem is not just what to do now, with the current exploits, but also how to protect the future. Attackers are using the most simple and easy path to take control, the default passwords. But they will adapt as controls come into play. This is the pattern we have seen with many other attack vectors. It is a repeating cycle in which attackers follow the path of least resistance to achieve their objective. IoT devices are just too perfect for botnets for the attackers to easily give up. This is shaping up to be a long and drawn-out fight.

securing-iot-devices

We must secure the future of IoT. This means blocking current exploits as well as interdicting the likely future maneuvers of attackers. This is what must be done to protect the life cycle of IoT devices, from inception to retirement.

  1. Designed and architected for security
    IoT manufacturers must take the time to embed security into the architecture, interfaces, and designs of their products. Basic security concepts and capabilities such as compartmentalization of data and code, communication between trusted parties, data protection both in use and at rest, and authentication of users should be established and tested. Products in the future will get more powerful, store more data, and possess more functionality. This means products should have the ability for security updates, feature locking, build validation, software vetting, and default configurations that follow industry best practices. It all starts with the manufacturer. Future proofing begins at the foundations. The hardware, firmware, operating systems, and software must be designed to go into a hostile environment and survive.
  1. Secure provisioning and configuration
    Most IoT devices require some kind of setup and provisioning upon installation. Device identity and authentication are a must, as part of this two-way process. Proper default configurations that adhere to best security practices are important and should be easy for users to understand. Rules should be in place that do not allow default passwords, require patches and updates to be signed, data to be encrypted, and only secure web connections. For enterprises, limiting network access, patching in a timely manner, and allowing only approved software to run will go a long way to keeping the devices secure. For gadgets that are capable, implementing security software such as antimalware, intrusion prevention systems, and even local firewalls will improve the device’s defense posture. Detection and telemetry should also be configured to detect when systems are under attack or are functioning in ways not intended by the organization. Policies must be established for privacy, data retention, remote access, key security, and revocation procedures.
  1. Proper administration and management
    For devices owned by consumers, it is imperative they alone maintain the final say in how the device is managed. Manufacturers and online service providers play a role in provisioning but the owner must retain ultimate control of what the device will do. Provisioning is different than administration. For example, during installation of home cameras it makes sense to connect to the manufacturer for the latest patches and maybe even setting up cloud storage. But you would not want your home cameras controlled by the manufacturer. They should not have the ability to operate them outside of buyer’s authority. Owners must retain the power to turn on or off their products and choose which online services they allow to connect. This requires proper user identification and authentication. As before, allowing a common default password is not good because anyone can take over as the administrator. Imagine if Windows came with a default login password for every system. It would create a security nightmare because many would never change it and attackers would login as users. So, first IoT systems must be able to authenticate their owners. Management functionality must also extend to empower the owner to set limits, data policies, and privacy parameters that are more restrictive than those of any potential third-party vendor. Signed security updates should be automatically installed by default as they become available. Savvy owners should be able to configure limits for inbound and outbound connections, data types, ports, and security settings. Logs that can be pushed to a trusted system or viewed locally should capture errors, and unexpected and unusual activities. A system for remote-warning notifications, via email or text, is a welcome feature on some devices. Finally, a reset capability must be present in the event of an unrecoverable compromise or transfer of ownership.

Enterprise and industrial devices are typically managed centrally, by the purchasing organization. This may be part or different than provisioning by the manufacturer or service provider. Entire classes, potentially numbering in the thousands, may be controlled to operate individually or as part of a collective. The same choices and control are required. Instead of a single owner, an organization’s employees will administer the IoT devices, monitor for issues, and respond to problems.

Proper administration and management is about oversight and final control by the device owner. It should be simple to understand and easy to manage. Devices should possess the necessary processes to determine if something is wrong, communicate such events to their owners, and provide options to resolve issues. IoT devices are here to make our world better and smarter; they themselves must bring some intellect to the ecosystem to protect themselves and work with their owners for their benefit.

How do we make IoT security a reality? 

Security and privacy take effort, resources, and commitment. To change from the status quo, we must hold manufacturers accountable for their devices. If they fail to design and architect security into their products, make them liable and stop buying their wares. For critical functions that could put the safety of people at risk, enact regulations and subject them to government penalties.

As part of the best practices, which manufacturers and service providers must follow, developers must institute the aspects that make provisioning and initial configuration secure by default. Industry consortiums are working to define best practices, configurations, and default settings for different device classes.

Last and perhaps most difficult, is to raise the level of awareness and involvement of users. It is their security and the operational availability of potential Internet targets that is at risk. Without some assistance from consumers and businesses, these controls will be easily undermined or neglected. Social interaction must take place. We all have a responsibility, as a digital community, to maintain reasonable hygiene for devices connecting to our common resource, the Internet.

The choice is ours

It may seem like a lot to consider, but remember attackers need only find a reasonable vulnerability to exploit. The opportunity is to make the effort challenging enough so they are not motivated to pursue these devices. We find ourselves in a situation in which billions of IoT products will flood every industry and quickly find their way into our homes, schools, governments, and businesses. We must make the necessary efforts to not bring vulnerabilities with them. The effects will go well beyond our own lives, data, and devices. They may be turned into legions of bots, which could cause havoc to even the biggest of organizations on the Internet. We could all become victims if we do not work together to make our future technology trustworthy, safe, and secure.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

 

The post How to Secure the Future of the Internet of Things appeared first on McAfee.