Google to buy Nest for $3.2B

Work2Play said:
And who woudl the average person call when their refrigerator gets hacked?
 
I've run into this problem in a network test lab where we had a lot of bright people who well versed in network tools such as routes, bridges, vpns and network sniffers. We finally discovered that one of our $100K+ tools had Windows XP CEon it and it had no virus protection. The network would keep getting re-infected until we isolated that unit, Getting that vendor to fix the problem was extremely difficult until Corporate threatened to ban the purchase of any more of their tools.
 
Now where would the consumer get that kind of knowledge when their ISP comes to them and says, we're blocking you until you clean up your network? Geek Squad? I think not, I'll be nice and just refrain from further opinion.
 
BTW, found this link that provides a counter point to the Proofpoint article: http://arstechnica.com/security/2014/01/is-your-refrigerator-really-part-of-a-massive-spam-sending-botnet/ . They do a decent job of pointing out some problems with the Proofpoint article.
 
The original article does begin to sound like a FUD piece but our discussion does bring up the worrying points of privacy and proper support. I'd say we're out in front of our head lights here with the IoTs.
 
Updated to correct the error of putting down XP instead of CE.
 
If someone is using Windows as an embedded OS within a fixed function box, I don't think that there should be any need for anti-virus software. I would argue that it should just be completely locked down with nothing exposed to the outside world but whatever ports are used by the tool software itself, so that the only way it could get infected is if their own software voluntarily accepted and stored a virus, which doesn't seem likely.
 
Dean Roddey said:
If someone is using Windows as an embedded OS within a fixed function box, I don't think that there should be any need for anti-virus software. I would argue that it should just be completely locked down with nothing exposed to the outside world but whatever ports are used by the tool software itself, so that the only way it could get infected is if their own software voluntarily accepted and stored a virus, which doesn't seem likely.
 
There are lots of software layers in Windows (or any OS for that matter) that sit below the application and are exposed through those outside ports.  They are part of the software path from the externally connected hardware to the application (think device drivers, TCP/IP, etc).  Any bugs that exist there are often exploited by a hacker who wants to infect the system.
 
But you can completely lock down Windows at the socket level, preventing incoming or outgoing connections on any ports you want. Though there have of course been some bugs in the actual TCP/IP stacks of OSes over the years, it's fairly rare. If you lock it down at the TCP/IP level, and only explicitly expose the ports that your own software uses, then you are going to be pretty damn safe. That means the only realistic way a virus could get onto that machine is a stack bug, or your own software accepts and stores a virus, which you'd have to be completely incompetent to do. With all ports locked down that means no ability to access any sort of shared resources, no ability to log in remotely, not ability to use any vulnerability in any of the standard background services that might be running (and of course you can even turn off many of those in a dedicated machine), etc... The exposed ports are the only things available for attack, and only your software is listening on them.
 
A system thusly set up would be among the last of my worries in my network. Almost everything else would be a far more likely target.
 
Dean Roddey said:
But you can completely lock down Windows at the socket level, preventing incoming or outgoing connections on any ports you want. Though there have of course been some bugs in the actual TCP/IP stacks of OSes over the years, it's fairly rare. If you lock it down at the TCP/IP level, and only explicitly expose the ports that your own software uses, then you are going to be pretty damn safe. That means the only realistic way a virus could get onto that machine is a stack bug, or your own software accepts and stores a virus, which you'd have to be completely incompetent to do. With all ports locked down that means no ability to access any sort of shared resources, no ability to log in remotely, not ability to use any vulnerability in any of the standard background services that might be running (and of course you can even turn off many of those in a dedicated machine), etc... The exposed ports are the only things available for attack, and only your software is listening on them.
 
A system thusly set up would be among the last of my worries in my network. Almost everything else would be a far more likely target.
The devices we used were network traffic generators and we were surprised to find out that WinCE was being used. We attached to the device via a software client, initially on Windows clients (later with Linux clients). We found out about it when we noticed the devices probing other Windows boxes (the start of Win2K, end of NT). At that time we'd also heard a similar story with a printer.
 
After that point we had corporate security requirements that had to be followed. All equipment had various security requirements (Windows, Linux and Main Frames are some of the easiest, other devices are not so easy ;-) ).
 
WinCE is perhaps a different animule. I don't know what it provides in the way of lock-down capabilities. It's also pretty ancient by modern standards as well. Hard to believe but that was 16 years ago when it first came out. Not to wax nostalgic but even those were more innocent network times in a way.
 
Years ago in a corporate environment after a bit we changed methodologies of protection relating to the protection of the enterprise network. 
 
We did treat the enterprise network as a sort of open network using the "onion" approach deciding what should be in the center and peeling back layers protecting each layer.
 
Here worked with all groups involved and concurrently managed capacity planning. 
 
Our group touched other departments; software, hardware, desktops et al.  On the infrastructure side went to just switching off network ports. 
 
The direction in the latter half of the 2000's did start to go to using single function embedded wintel terminals then linux embedded terminals.  Earlier access methodologies to said "terminals" did get addressed.  The further away from the core though the easier it was to circumvent the layered security in place which always present problems.  (> 100k clients on a global enterprise network). 
 
Most of the issues that I saw related to created silos and lack of communication between various department; IE: software applications, network infrastructure, desktop support, so forth and on.  IE: problems/issues would be presented to corporate security with solutions; then documented standards would be agreed upon between layers or departments. 
 
Madcodger said:
A company comes out with a truly useful, well made, quality product... Has never given me a moment of trouble... Looks great... Paid for itself in less than one year.
The point is what value you get and value you are creating for the service provider.
For reducing your energy bill there are some measures taking into consideration attendance,prediction of solar gains etc..
Algorithms anticipating when you will be home are certainly  helpful, but they might be linked towards your cell phone position staying away from home.
The point is if you really need to give away all your personal data in order to generate energy savings. Deprived workers having two shifts a day to pay for the living might agree. They give you personal data for free and get some time and energy savings-perfect.  
I guess there will be experts thinking about alternatives to that model however, I hope so!
 
Back
Top