Internet of Things (IoT) Security Issues

In the past, I discussed how the Internet of Things (IoT) could eventually cause a wealth of problems on the Internet, including security breaches, in a number of my books and articles. Some of my strongest warnings came in Build Your Own PC on a Budget and Security for Web Developers, but I included warnings in other places as well. Unfortunately, the worst case scenario has occurred according to the ComputerWorld article, Armies of hacked IoT devices launch unprecedented DDoS attacks. Yes, your DVR or smart television might have turned into a zombie at this point and now works for someone else committing crimes. All it takes is a little negligence on your part and your device will take a walk on the dark side.

The article is worthwhile reading because the statistics sound like something out of a bad science fiction novel. If anything, my warnings were too tame and I should have used my imagination a bit more in exploring just how bad things could get. Yet, I’ve received e-mail from readers who found the warnings I did provide barely believable. It didn’t seem possible that something as simple as the router installed to provide broadband support for your digital telephone could possibly cause any sort of problem. After all, your old telephone system never went on the attack. The thing is, any device that connects to the Internet today probably has enough intelligence to do harm, especially the IoT devices that everyone assumes just work.

IoT devices are actually some of the best targets for hackers. The users who have them barely know how they work, have no clue that they should change the password, and wouldn’t care even if they could figure it out. After all, the goal is to see Sunday afternoon football, not to configure security for a device. Vendors share in the blame because anyone with even a modicum of common sense would know that users have no desire whatsoever to change device passwords. IoT devices should go out with a unique password printed in a place that the user can easily find on the device, should it ever become necessary to access the device (and it might not ever become necessary). If hackers faced a unique default password for every device, the IoT devices would likely remain relatively secure unless hackers could somehow figure a pattern out in the password assignments. Ensuring the unique password is printed on the device means the user won’t lose it.

It’s not as if changing IoT device passwords is easy anyway, so hackers have every reason to believe that the default password is still in place for the majority of these devices. A recent device purchase pointed out to me that some IoT devices view even password changes as unwelcome user fiddling—it took nearly 20 minutes of reading to discover how to change the password using an arcane set of remote control clicks. Until this situation changes, you must expect that hackers will continue to use IoT devices to perform various kinds of attacks and that device owners will continue to remain oblivious about their cherished device’s life of crime. Let me know your thoughts on IoT security at John@JohnMuellerBooks.com.

 

Security Breaches and the Potential Effect on Big Data

There are two interacting forces in big data today that few people are talking about. Perhaps it just hasn’t occurred to anyone that there truly is a serious threat. This particular post is going to talk about big data used for healthcare, but the same issue applies to any use of big data. Organizations, such as Penn Medicine, are using big data to perform real world tasks that really make difference. For example, it’s now possible to predict the potential for diseases well in advance of any critical fallout now—at least for some diseases such as sepsis. The ability to predict an event before it becomes critical is important for all sorts of reasons, but the most important is improving overall health. Of course, it also affects the cost of healthcare and the need to use healthcare in the first place.

However, while writing both Python for Data Science for Dummies and Machine Learning for Dummies, I’ve discovered the fallout of data errors is more critical than anyone can imagine. Ensuring correct data entry is a large part of the solution, but there are other concerns. Yes, algorithms can learn to determine which data is useful and which data isn’t, but the purer the data at the outset, the better.

While writing Security for Web Developers I reviewed many sorts of security breach, some of which involve modifying organizational data. What this means is that an outsider could potentially corrupt the big data used to make assumptions about medical conditions. Do you see where I’m going with this? Having bad data, data that is modified by an outsider and therefore not as likely to gain the attention of someone who can fix it, will cause those algorithms to make some invalid assumptions. Humans help correct the assumptions, but humans aren’t perfect and make assumptions about the behavior of the algorithm. The bottom line is that security breaches of the wrong sort could end up costing lives. It’s something to think about anyway.

The potential for error in big data analysis is just one of a whole bunch of reasons that I’m happy to read that the government is finally looking into ways to bolster the devices used to work with medical data. I’m almost positive that medical practitioners will fight tooth and nail against the new security measures, just like users of every persuasion do, but the security measures really are more important than just protecting individual patient data. As data becomes the centerpiece of all sorts of human endeavors, ensuring it remains as pristine as possible becomes ever more important. Security has to take a bigger role in data management in the future. Let me know your thoughts on securing data that could be used for medical analysis at John@JohnMuellerBooks.com.

 

A Fuller Understanding of the Internet of Things

You can find the Internet of Things (IoT) discussed just about everywhere today because the Internet has become pervasive. IoT is part of most business applications today as discussed in Security for Web Developers and part of any PC you build as discussed in Build Your Own PC on a Budget. It appears as part of smart TVs and Blue-ray players. In fact, you find IoT employed in a lot of places you might not have thought possible even a year ago. The point is that IoT is here to stay and we need to consider some of the ramifications of it on every day life.

One of the issues that hasn’t surprised me too much is the issue of security. Both my smart TV and smart Blue-ray player require me to enter a password to access the Internet through my wireless router (mostly because the router is configured to require one). So these devices do employ security to some extent. However, they remain logged on at all times, so the router is also configured to disconnect devices after a certain time. Each time I turn the devices on, I must reenter the password. It’s a level of security, but not necessarily the best security. Some devices, such as Apple Watch, lack any form of security. (In the case of Apple Watch, the device authenticates through an iPhone, so it still has some level of security, but not security that is part of the device itself.) Some industry pundits are saying that these devices will eventually kill the password, which means that some other form of primary authentication is needed.

The problem is increased by the proliferation of headless devices (products that lack any sort of display, such as a door lock, security system, or robots). In these cases, you can’t enter a password. No one is really sure how to secure these devices, but a solution really is needed and soon. Unless we find a solution, the issues surrounding intentional hacking will increase. A recent InfoWorld article, Welcome to the smart home … of horror!, emphasizes some of the sorts of things that could happen due to a lack of security.

Security and configuration problems aren’t just limited to outsiders gaining access to your home, office, business, or other location due to holes in IoT security. It also turns out that smart devices aren’t particularly smart, so sometimes you lose access to your network and its connected devices due to a combination of security and configuration issues when a failure occurs. In the ComputerWorld article, The Internet of Things: Your worst nightmare, you can hear about one person’s attempt to recover from a simple router failure. It turns out that simply replacing the router wasn’t enough—everything connected to the router needed reconfiguration and sometimes the task was less than easy to perform.

The world is in a age of transformation. The ride will be bumpy and the problems severe. When you consider the immensity of the things that are changing, the future looks incredibly different from anything that has gone on in the past. Not only is there IoT to consider, but the whole issue of robots and other technologies that are coming to fore. As these new technologies become part of everyday life, we have to ensure we can use them safely and that ability of someone to hurt us through them is curtailed. Let me know your thoughts about IoT security and configuration at John@JohnMuellerBooks.com.

 

Web Apps and Outdated Software

A particular problem that developers face when creating web apps is that users are notoriously lax in updating their software. A problem piece of software may make it easy for a hacker to gain access to the system. In some cases, the user will blame your application because it depends on software that could be outdated on the user’s system. A recent InfoWorld article, 10 old, risky applications you should stop using, brings the issue to light. Many of these pieces of software see use in Web apps. You may think that the user will rely on the newest version of the software, but the user may, in fact, have a piece of software that’s several generations old, yet runs your web app just fine.

Most of my web development books at least hint at the issue of dealing with outdated libraries, APIs, and microservices. Security for Web Developers makes the strongest case for verifying that web apps rely on the latest third party products to ensure the web app is less likely to cause a security breach, but both HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies discuss the issue as well. The point is that you need to know that a user is relying on the latest software if at all possible. Otherwise, you may find your web app blamed for a security breach actually caused by another piece of software, such as a web browser.

The fear that many users have is that your web app will stop working if they upgrade to newer software. This fear has a strong foundation in broken applications of all sorts in the past. The problem can become quite severe. Looking at the InfoWorld article, you find several interesting bits of information. For example, many existing applications rely on Microsoft XML Core Services 4.x, despite the fact that the software is no longer supported and represents a huge security hole that hackers are only too happy to exploit. If the user removes this software to keep their systems safe, they may also have to give up on one or more mission critical applications. Testing is the developer’s tool of choice in this case. Make sure you test your web apps with the lasted software and then publish the results online. Keep users informed of potential problems and your plan for fixing them so that they can continue making required updates to keep their systems safe.

It may not be entirely possibly to fix every security problem immediately. The fact is that software today is so interdependent on every other piece of software that even when your web app has fully supported underpinnings, the software you depend upon may not. The dependencies cascade in convoluted ways that make it entirely possible that a hacker will find a way to breach your application despite your best efforts. Consequently, you not only need to maintain a firm grasp on testing, but also of potential problems with the software used to reduce your development effort and make the application perform better. In short, you need to have a contingency plan in place for those times when a hacker finds a way to break your web app because a determined hacker will fine a way.

Outdated software is the bane of developers everywhere, yet users remain clueless as to how much damage they invite by not making required updates. One of the issues that I’m constantly striving to solve in my books is this whole concept of software dependency and how it affects application reliability, security, and speed. If you find that some of the materials I’ve put together are especially helpful (or possibly not helpful enough), please let me know about them at John@JohnMuellerBooks.com. I want to be sure that the security features of my books really do help you past the whole outdated software issue because users really won’t be much help at all.

 

Web Security, A Lot More Complicated Than It Seems

I recently finished writing Security for Web Developers. During the months that I worked on the book, I became aware of a serious problem in the reporting, handling, and supposed fixes for the problem of web security—everyone seems intent on making things fast and easy. Depending on the source, you also see a fair amount of finger pointing at play. Sources put the blame on just one or two entities in most cases. Unfortunately, the picture is far more complex than simply applying a bandage to one or two potential security problem sources. I started understanding the problem when I wrote HTML5 Programming with JavaScript for Dummies and CSS3 for Dummies, but it wasn’t until I wrote this book that I began to understand the true enormity of the problem. It isn’t just one or two or three sources—it’s all the sources combined. In this latest book I explore a lot of different sources of security problems and provide advice on how to overcome these issues to some extent.

  • Users
  • Application Developers
  • Third Party Library, API, and Microservice Providers
  • Administrators and Other IT Staff
  • Product Distributors
  • Data Service Providers

Many other groups appear in the book as well. The more I dug, the more I found that just fixing one problem or educating one group wouldn’t solve anything. Hackers look for easy ways to gain access to applications and the current system provides them with plenty of opportunities. The current strategy of responding to just one potential threat will continue to fail simply because the hacker will move on to another threat. Unless an organization is willing to take a holistic approach to security, hackers will continue to enjoy overwhelming success without a whole lot of work. In writing Security for Web Developers, I attempted to provide a broader view of the security picture so that development teams that include all of the stakeholders involved in an application effort can finally work together to resolve the security issues in their individual areas of expertise (including users who are susceptible to too many kinds of attack to mention).

A reader recently asked me whether the strategies in my book will prevent attacks, which is a loaded question and one that is hard to answer. My view of security is that a determined hacker will always gain entrance to your system, so you must remain vigilant at all times. If someone wants your data, they’ll gain access, but if you’re equally vigilant, you can keep the damage to a minimum. For that matter, you might be able to prevent any real damage. However, you need to realize that no security measure you take is going to succeed all the time.

What my book does is help make your system less appealing. In other words, if a hacker is just looking for a system to invade and not specifically your system, then making your system less appealing will see the hacker move to other systems. Like anyone else, a hacker seeks to minimize effort and maximize gain. Making your system less appealing by employing a holistic security approach will increase the effort the hacker must employ and make it less likely that the hacker will continue probing.

Unless you really want to see your organization’s name join the victim list in the trade press, you really do need to employ security across an organization, which means vetting software fully, educating users, having appropriate policies in place, reviewing software before placing it in production, and so on. Using just one or two measures simply won’t work. Let me know if you have questions regarding my upcoming book at John@JohnMuellerBooks.com.

 

Web Application Security Breach Commonality

If you follow the trade news for even a few weeks, you begin to see a recurring pattern of security breaches based on web application deficiencies, social engineering attacks, or some other weakness in the security chain. The latest attack that is making the rounds is the IRS security breach. However, I’m not picking on the IRS, you can find security breaches galore in every arena of human endeavor simply by performing the required search. Everyone gets hacked, everyone is embarrassed by it, and everyone lies through their teeth about the methods used for the attack, the severity of the attack, and the likelihood of dire results. The attacks serve to demonstrate a simple principle I’ve written about in HTML5 Programming with JavaScript for Dummies, CSS3 for Dummies, and Security for Web Developers—if someone wants to break your security, they’ll always succeed.

Later analysis of the IRS attack brings out some important issues that you need to consider as part of your development efforts. The first is that you really do need to expend the effort to create the most secure environment possible. Many of the successful attacks use simple methods to obtain the desired result. Training really does help reduce social engineering attacks, updates really do help close security issues that a hacker can use to access your system, good programming practices keep hackers at bay, make applications easier to use, and reduce errors that result in security issues. All of these methods help you remain secure. However, remaining vigilant is important too. Monitoring your application and the libraries, APIs, and microservices on which they depend are all important. Despite protestations to the contrary, the IRS probably could have done more to prevent the breach, or at least mitigate the results of the breach.

A focal point of the analysis for me is that the IRS currently has 363 people working security and a budget of $141.5 million to ensure your data remains safe. The author is a bit harsh and asks whether the IRS Commissioner Koskinen thinks his people are stupid because he keeps making the claim that these hackers are quite skilled. Yet, the hacks used are really quite simple. Breaches happen to every organization at some point, no matter how much money you want to throw at the problem. Organizations get blindsided because hackers attack from a direction that is unexpected in many cases or the organization simply isn’t keeping track of the current threats. Again, I’m not heaping insult on the IRS, simply pointing out a problem that appears common to most of the breaches I read about. What is needed in this case is a frank admission of the facts and a whole lot less in the way of excuses that simply make the organization look weak or stupid anyway.

The IRS, like many organizations, later came back and increased the tally on the number of individuals affected by the breach. This is another common issue. Instead of investigating first and speaking later, many organizations provide numbers at the outset that really aren’t based on solid facts. When an organization has a breach, the public does need to know, but the organization should wait on details until it actually does know what happened.

The application that caused the breach is now dead. It’s a demonstration of a final principle that appears in many of my books. If you really want to keep something secret, then don’t tell anyone about it. Breaches happen when data is made public in some manner. Yes, it’s convenient to access tax information using a web application, but the web application will be breached at some point and then the confidential details will appear in public. Organizations need to weigh convenience against the need to keep data secure. In some cases, security has to win.

The more I read about security breaches, the more convinced I become that they’re unavoidable. The only way to prevent data breaches is to keep the data in a closed system (and even then, a disgruntled employee could still potentially make a copy). Being honest about data breaches, providing the public with solid facts, and ensuring remediation measures are effective are the only ways to control the effects of a data breach. Let me know your thoughts on this issue at John@JohnMuellerBooks.com.

 

Security = Scrutiny

There is a myth among administrators and developers that it’s possible to keep a machine free of viruses, adware, Trojans, and other forms of malware simply by disconnecting it from the Internet. I’m showing my age (yet again), but machines were being infected with all sorts of malware long before the Internet became any sort of connectivity solution for any system. At one time it was floppy disks that were the culprit, but all sorts of other avenues of attack present themselves. To dismiss things like evil USB drives that take over systems, even systems not connected to the Internet, is akin to closing your eyes and hoping an opponent doesn’t choose to hit you while you’re not looking. After all, it wouldn’t be fair. However, whoever said that life was fair or that anyone involved in security plays by the rules? If you want to keep your systems free of malware, then you need to be alert and scrutinize them continually.

Let’s look at this issue another way. If you refused to do anything about the burglar rummaging around on the first floor while you listened in your bedroom on the second floor, the police would think you’re pretty odd. More importantly, you’d have a really hard time getting any sort of sympathy or empathy from them. After all, if you just let a burglar take your things while you blithely refuse to acknowledge the burglar’s presence, whose fault is that? (Getting bonked on the back of the head while you are looking is another story.) That’s why you need to monitor your systems, even if they aren’t connected to the Internet. Someone wants to ruin your day and they’re not playing around. Hackers are dead serious about grabbing every bit of usable data on your system and using it to make your life truly terrible. Your misery makes them sublimely happy. Really, take my word for it.

The reason I’m discussing this issue is that I’m still seeing stories like, “Chinese hacker group among first to target networks isolated from Internet.” So, what about all those networks that were hacked before the Internet became a connectivity solution? Hackers have been taking networks down for a considerable time period and it doesn’t take an Internet connection to do it. The story is an interesting one because the technique used demonstrates that hackers don’t have to be particularly good at their profession to break into many networks. It’s also alarming because some of the networks targeted were contractors for the US military.

There is no tool, software, connection method, or secret incantation that can protect your system from determined hackers. I’ve said this in every writing about security. Yes, you can use a number of tools to make it more difficult to get through and to dissuade someone who truly isn’t all that determined. Unfortunately, no matter how high you make the walls of your server fortress, the hacker can always go just a bit further to climb them. Headlines such as “Advanced Attackers go Undetected for a Median of 229 Days; Only One-Third of Organizations Identify Breaches on Their Own” tell me that most organizations could do more to scrutinize their networks. Every writing I read about informed security is that you can’t trust anyone or anything when you’re responsible for security, yet organizations continue to ignore that burglar on the first floor.

There is the question of whether it’s possible to detect and handle every threat. The answer is that it isn’t. Truly gifted hackers will blindside you can cause terrifying damage to your systems every time. Monitoring can mitigate the damage and help you recover more quickly, but the fact is that it’s definitely possible to do better. Let me know your thoughts about security at John@JohnMuellerBooks.com.

 

Considering Our Future Cyber War

It’s not if a cyber war will happen, but when. Precisely what form such a war will take depends on the perpetrators and their goals. I’ve spend quite of time discussing the relative insecurity of the Supervisory Control and Data Acquisition (SCADA) systems out there. However, I’m only assuming that SCADA is going to be targeted at some point because it’s such low hanging fruit and no one seems to have any interest at all in securing. Plus, the attack would be of the sort that we’d have a hard time defending against (and possibly identifying at first as the hospitals fill with victims of some mysterious problem).

I recently read an article by John Dvorak entitled, “What if Facebook Is Hacked Next?” John makes some excellent points, but probably doesn’t go far enough. Why would an attacker stop with just Facebook? Why not attack all of the sources of social media out there, including places like LinkedIn and Twitter? The confusion created by the loss of all social media would be amazing. It could easily act as a smokescreen for some other activity even more devastating than the loss of data. While everyone is scrambling to fix their social media issues, someone could work in the background to do something truly horrible.

Actually, the attacker might not even have to do anything other than disrupt all online activities. Think about the number of jobs lost, the hit to online commerce, and the other problems that such an attack would cause. Perhaps these people are simply waiting until more brick and mortar stores close that people no longer have local resources to help in such an emergency. For example, think about the problems that the loss of online stores would have to IT professionals who maintain huge networks of computer systems. The potential for truly terrifying results is amazing.

A cyber war is coming. Just when it will arrive is the topic of much speculation, but my feeling is that it’ll come sometime soon. What sorts of security measures do you have in place? Have you done anything else to prepare? Let me know about your thoughts on cyber war at John@JohnMuellerBooks.com.

 

API Security and the Developer

As our world becomes ever more interconnected, developers rely more and more on code and data sources outside of the environment in which the application runs. Using external code and data sources has a considerable number of advantages, not the least of which is keeping application development on schedule and within budget. However, working with APIs, whether local or on someone else’s system, means performing additional levels of testing. It isn’t enough to know that the application works as planned when used in the way you originally envisioned it being used. That’s why I wrote API Security Testing: Think Like a Bad Guy. This article helps you understand the sorts of attacks you might encounter when working with a third party API or allowing others to use your API.

Knowing the sources and types of potential threats can help you create better debugging processes for your organization. In reality, most security breaches today point to a lack of proper testing and an inability to debug applications because the inner workings of that application are poorly understood by those who maintain them. Blaming the user for interacting with an application incorrectly, hackers for exploiting API weaknesses, or third parties for improperly testing their APIs are simply excuses. Unfortunately, no one is interested in hearing excuses when an application opens a door to user data of various types.

It was serendipity that I was asked to review the recent Snapchat debacle and write an article about it. My editorial appears as Security Lessons Courtesy of Snapchat. The problems with Snapchat are significant and they could have been avoided with proper testing procedures, QA, and debugging techniques.This vendor is doing precisely all the wrong things—I truly couldn’t have asked for a better example to illustrate the issues that can occur when APIs aren’t tested correctly and fully. The results of the security breach are truly devastating from a certain perspective. As far as I know, no one had their identity stolen, but many people have lost their dignity and privacy as a result of the security breach. Certainly, someone will try to extort money from those who have been compromised. After all, you really don’t want your significant other, your boss, or your associates to see that inappropriate picture.

The need to test APIs carefully, fully, and without preconceived notions of how the user will interact with the API is essential. Until APIs become more secure and developers begin to take security seriously, you can expect a continuous stream of security breaches to appear in both the trade press and national media. The disturbing trend is that vendors now tend to blame users, but this really is a dead end. The best advice I can provide to software developers is to assume the user will always attempt to use your application incorrectly, no matter how much training the user receives.

Of course, it isn’t just APIs that require vigorous testing, but applications as a whole. However, errors in APIs tend to be worse because a single API can see use in a number of applications. So, a single error in the API is spread far wider than a similar error in an application. Let me know your thoughts on API security testing at John@JohnMuellerBooks.com.

Red Herrings

Whenever a new exploit surfaces, such as Heartbleed, and the media focuses all its attention on it, I have to wonder whether the exploit may not be a red herring—a bit of misdirection used to keep our attention focused anywhere other than it should be. It’s true that this exploit is quite terrible. It affects any server running Secure Sockets Layer (SSL) and Transport Layer Security (TSL) software based on OpenSSL, which is actually supposed to protect people engaged in confidential transactions. Supposedly, Windows and OS X servers are immune to the exploit, but these servers often rely on services offered by servers that are affected, so everyone is suspect at this point. It’s my understanding that the exploit is incredibly easy to implement and doesn’t leave any trace once the perpetrator has gone. Fortunately, there are also ways to fix the problem and most sites will likely have it fixed within a couple of days.

The exploit is an eye opener for users who have grown complacent about Internet use over the years. Most of the articles I read about Heartbleed don’t even address the user, but the user is the real loser. It’s the user’s information that is gone forever without a trace and the user who will likely bear the brunt of the financial problems caused by Heartbleed. Even if a company is forced to pay some sort of compensation to the user for the loss of information, the compensation will never fully repay the user for the inconvenience and loss of reputation that such an exploit causes. Unfortunately, the user continues to pay a price long after the exploit is forgotten in the form of lost opportunities and an inability to make use of certain services due to a loss of reputation caused by the exploit.

However, I began this post by talking about red herrings—the misdirection often found in the plot of detective novels. I find it interesting that this bug was introduced in December 2011 and is only now making headlines. This means that Heartbleed was a usable, viable means of grabbing information surreptitiously for over two years. It makes me think that there must be other kinds of exploits of this sort that nefarious individuals are currently using to grab every last bit of information possible about you. All the media attention on this one particular exploit is taking the spotlight off those other exploits. Perhaps Heartbleed has outlived its usefulness and was actually made visible by the hacker community on purpose for the purpose of hiding the true activities of these individuals. Of course, there is no way of knowing.

What all this leads me to believe is that individuals must exercise good judgement when engaging in online activities of any sort. No one will fix your credit report or reputation once ruined and counting on the financial community to make amends simply won’t work. These people are rich for a reason—they know how to hold onto their money (as in, you won’t get any). In addition, software is always going to contain errors because programmers are human, so you must count on future exploits every bit as bad (or potentially worse) than Heartbleed. With this in mind, consider taking these suggestions to moderate your online behavior and make it a little more safe.

 

  • Use strong passwords that are easy to remember so you don’t have to write them down.
  • Change your password relatively often (every month or two works pretty well).
  • Use different passwords on every site you visit.
  • Never engage in transactions of any sort with any organization you don’t know.
  • Rely on a single credit card for financial transactions and never use the credit card for any other purpose (better yet, rely on an online-specific financial aid such as PayPal).
  • Don’t expose more information about yourself than necessary.


There are other ways in which you can protect yourself, but if you follow these few techniques, you can avoid a considerable number of security issues. The point is that Heartbleed is a scary exploit and there are probably a hundred other exploits, just as scary, already in play out there. Someone will always want your information and just handing it over to them seems like a bad idea, so take steps to personally keep your information secure. Let me know your thoughts about security red herrings at John@JohnMuellerBooks.com.