Maybe the best answer is to have the fridge have SNMP ability, and let one's own computer walk the MIBs periodically and respond to traps by the appliance. This is an existing protocol, available in virtually every single OS.
The problem is that doing security right isn't cheap, in both buying the right tools, making a proper network topology, and getting everything configured.
Long term, it really means businesses have to lay fiber and create a separate WAN, separate from the Internet, with some top-down management system (virtual circuits), where if machines are not pre-arranged to communicate with each other, they don't have access... and this is done on both the network fabric, and the individual hosts. Dedicated links are a lot more expensive than VPNs, but one isn't a misconfiguration of a router from disaster with them.
Remote access trojans (RATs) are not hard to stomp. If machine "A" has no reason to be communicating outside to the Internet, then it doesn't get access [1]. If it needs to go out, it gets access to the IP range it needs and no other. Network security 101 with the principle of deny everything that isn't whitelisted. This has been in textbooks since 1992 when one used Venama's TCP wrappers on sensitive boxes to ensure only proper hosts could telnet to them (SSH wasn't in use back then because it would have been considered an ITAR munition.) RATs are easily detectable by IDS/IPS installations. In a more secure network, if the traffic isn't MITM-able by the BlueCoat appliance, and it appears encrypted, it doesn't go out. SSH tunnels are easy to spot with monitoring tools, and the kibosh laid on it automatically.
Of course, edge security goes without saying. This isn't hard. ASA appliances are relatively cheap, and the expertise to properly configure them is widespread.
[1]: Realistically, how many machines in a company need Internet access, or access outside their Ethernet segment for most things? One could always allow RDP/Citrix access to a hop box if people wanted external Web access, WSUS and mirroring repositories takes care of patches, and DCs are internal. Or, one can require remote desktop access for the more secure data and "just" use proper endpoint security. Lots of ways to do this securely.
There are some good things about the iOS ecosystem. For starters, if you require the latest iOS version, the piracy rate for apps will be at 0%. If you allow multiple iOS versions, just do a write or read outside your app's sandbox to check for a JB or not. Android has a non-zero piracy rate, but LVL and device-based APK encryption do reduce it to a dull roar.
You can still earn money as a developer. However, you can't follow the herd. If everyone is making fart apps, don't waste the time in making one.
Find a market segment and go with that. For example, Torque is an app that makes a lot of money. It isn't mainstream, but for the task at hand, it is extremely useful, and people will pay for it.
Some ideas/suggestions of what to do:
1: Make a GOOD PGP/gpg program. One that not just does the usual signing/encrypting/validating/decrypting, but uses the operating system's encryption (KeyChain) to stash the private keys. Coupled with an optional passphrase, this provides good protection.
2: Make a utility that can store files on multiple cloud providers at once. That way, if I stash documents and some sync error trashes one provider, I still have the documents saved somewhere else. If there are sync mismatches, give the user the option of using the document with the latest timestamp with saving the old one in an archive directory to be safe.
3: Create an app that is based on option #2, but also encrypts and presents itself as a WebDAV option. This way, one can use their phone as a drag and drop cloud storage device, with the app doing the backend encryption and distributed storage work.
4: A statistical analyzer similar to Minitab or SAS, but scaled down to a device.
5: A device that does TKIP/SKIP authentication like Google's Authenticator, but can use TouchID on iOS, a PIN/passphrase on iOS/Android, and can back the seeds up securely. This way, if I re-ROM my phone, I don't have to redo all my 2FA stuff... just re-import an encrypted backup and be back and running. With the option of a PIN, even if the device is stolen, one's 2FA IDs are still protected.
Swift must be a really good language. Every so often, I get E-mails from recruiters with positions demanding five years of Swift programming skills as part of the core position.
Diesel engines also could use gasoline as fuel. It requires some engineering due to the differences in compression, but it could be done.
I agree... diesel is a better all around fuel. Modern ethanol-based gasoline has a lifetime of weeks, while diesel with bug killer can be stores in a tank for much longer and still be usable.
There is also the biodiesel aspect. Biodiesel can be made from almost anything oily/greasy, be it cooking oil, fat from a meat packing plant, waste motor oil that is filtered, or anything along those lines. Of course, it has different lubricant properties than normal diesel... but if a gasser engine can run on booze, it isn't that hard to adjust programming on a diesel to run on B20-B100.
The days of the smoke-belching, dog-slow Mercedes turbo diesels which forced people to pass on the breakdown lane in order not to get asphyxiated are long gone, even though those were a scourge of the roads. One can walk behind a Sprinter, Ford F-350, or other diesel vehicle made within the past decade, and there won't be a smell, and there is likely to be no smoke, other than when the engine is started.
Of course, there are coal rollers who deliberately de-tune their engines to run rich and reprogram the ECMs for the black smoke... but in my neck of the woods, the local police will actually scrape off the inspection and registration stickers, or even tow a vehicle on the spot (since it is not considered road-legal) to the nearest diesel shop if the DPF/DEF/EGR stuff is deliberately destroyed.
I personally detest wasting fuel. Diesel isn't cheap.
Isn't this what DPF and DEF systems are for? DPF systems mean that there is a filter which gets clogged every so often so the diesel vehicle is in the shop for a â3000 replacement, especially if the vehicle idles often. The DEF system provides for the vehicle being in the shop for a new engine (or at least a new set of injectors and high pressure fuel pump) when a novice vehicle owner gets confused and pours the AdBlue into the fuel tank and not the piss tank. Since the diesel-engined vehicle is kept off the road by both of these things, particulate issues are well addressed.
We had the ability to have a secure Internet back in the 1990s. However, with the average corporate desktop copy of Windows initially having no security other than logging into the Netware server to show a share, security primarily moved to the network.
The problem with IoT is that we (as in general organizations) have a lot of experience in securing networks. However, all IoT devices are edge devices... and it doesn't take a CCIE to realize the problem with that, especially the fact that the tech to secure machines is far trailing the expertise in securing network fabric.
How about we go to a third model, and that is DMZ networks with hardened chokepoints. We can do this with existing protocols.
For example, we have a subnet that has a fridge, oven, dishwasher, and power distribution unit on it. A central device with a hardened exterior firewall controls what goes out. At an extreme, one can build firewalling functionality into the hardware NIC so if the device's OS is compromised, it still has protection.
The central device uses SNMPv3 to walk the devices. If finds the fridge's internal thermostat is 55 degrees in the freezer, and sends an alert to the company's monitoring station, which alerts the owner via app or SMS. The dishwasher was set and fished, so sends a SNMP trap which lets the user know dishes are ready. Since the user set a flag that he is on vacation, the monitoring device sends a SNMP request to the PDU to shut off power to circuits not needed.
IoT functionality can be done, and can be done securely, with existing tools. It just needs common sense and making sure that what is connected to the Internet is well-hardened, and the "soft and chewy" iOT devices do their communication to an appliance, and the appliance does the rest over the Internet.
LAN communication between devices and the monitor can be well secured. Recent Bluetooth versions do this well, preventing a third party from not just eavesdropping, but spoofing traffic. For even better security, devices can use the power line and encryption over that. Of course, the best security would be dedicated fiber optic cables run in a conduit from the appliances to the monitoring station. Not 100%, but if physical access is gained by an intruder to those cables, the jig is up anyway, and the goal is to protect against remote attacks.
The biggest problem with IoT is that all devices are edge devices when in reality, they should be core (or DMZ) devices with secure device handling the requests. Again, not 100% secure, but if some appliance's IP stack is buggy, it won't be exposed to entire Internet, just anyone nearby that physical location.
If I were deploying an infrastructure, I'd go with a basic layered approach. The sensitive stuff either gets put behind RDP or Citrix (with 2FA to log onto those servers), the edge VPNs definitely get 2FA, and average machines get "plain old" AD logins with passwords changed on a normal schedule like every 30-60 days [1].
Of course, network topology, and devices play a large part in this. This way, a guy in receiving who gets malware on his machine will not affect the computers in finance or development. Endpoint management also helps, but one doesn't know if an attack is going to go through a compromised Web browser, physical access, a disgruntled employee, or a backdoor in the main firewalling routers that allows an attacker full access from the Internet.
Wise use of 2FA does help, but as with all security products, it isn't a magic bullet.
[1]: Only real difference I'd have is that all user accounts would have expiration dates in AD going 6-12 months out, and that an audit every month or so would pop up ones about to expire so the accounts can be either re-validated or left to expire until explicitly needed again. This way, an admin that left quietly where people forgot about won't always have access, as it will end up getting pulled automatically.
MTBF and transfer rate numbers are boring... but those can be just as important, if not more, than the drive's capacity.
With high capacity tier 3 drives, one reason that RAID 6 (or a RAID 50 setup with tiers/groups of disks) is used is because it can take days to rebuild a blown drive. If drives continue to have larger capacities, but I/O stays the same, then we will need to add more parity drives to RAID arrays to support multiple drive failures and still keep the data accessible, better algorithms that run in the background to detect (and fix) bit rot, and bigger/smarter caches.
Maybe this is just me, but I'd rather see drives with double the MTBF than double the capacity. I can always add more drives and arrays. A failed disk will cost time no matter what, even if it is just walking to the server room, pulling it out and replacing it with a spare. For non-enterprise customers, a failed drive can be catastrophic since not many users have RAID arrays for protection.
Bingo. Having computer assisted voting that produces a ballot that is both machine and human readable is a must. Without this paper trail, you have absolutely nothing. Even with crypto, crypto doesn't protect against erasure, and an "accidental" erasure of votes on a voting machine can sway an election.
I was working on an e-voting prototype using Java in the late 1990s. No matter how it worked, there was no way to secure it, so I gave up on the project, because if the device couldn't be hacked, the data on it was destroyable. Distributed storage could easily be hacked/tampered with, and would be hard to admin by volunteers. The hardware could be made more secure, but it would completely destroy voter anonymity.
Instead, David Chaum's Verifiable Voting system is the absolute best thing out there. It provides not just anonymity for votes, but validates ballots were done correctly.
Biometrics might be useful for a lock inside an already secure company, but there are so many existing solutions which work well with AD that cobbling up something can be pointless:
1: Why not just use regular AD authentication at the core, move the 2FA to the edges? I've seen this done using either Cisco software for VPNs, Citrix, or other means. This way, to authenticate from machine to machine (especially if UNIX machines use AD and there isn't a way to add anything), it doesn't take that much. Plus, this saves cash by limiting the need for devices to users who need access from the edge.
2: If 2FA is needed, then why not use CAC/PIV-like cards? Since the US government uses them everywhere, the software for them is available.
3: If 2FA is needed on the cheap, there might be a way to use the Google Authenticator (part of OAuth as above). I have that in place on ESXi machines and other items. However, this means that one has to have a device showing the numbers with them at all times. I also use OAuth and Google's app for Linux VMs that are Internet facing as a backup if I don't have the local machine's SSH key in the remote VM's authorized keys file.
Personally, I'd just use 2FA on the edges or on the machines which need that security. Fewer hassles, and cheaper.
Hydrogen also takes a lot of energy to split from water. Technically it is renewable... and it also is energy source independent (got a hydro plant nearby, like Paraguay, then there may be energy to spare.) This can be a good thing, because the vehicle isn't tied to petroleum like it would be with CNG/LNG or other fossil fuels.
I personally like the idea of getting away from anything dino related as fuel, be it batteries, a la Tesla, or hydrogen fuel. This is going to have to happen sooner or later, and better now as opposed to when a crisis happens, such as Iran deciding to stop letting tankers cross through the Strait of Hormuz.
Long term, hydrogen does use more energy... but getting energy is a matter of will than technology. Thorium reactors have been around for decades. China has gen IV reactors up and running, and are doing their best to get off the imported oil teat. If vehicles can be moved from oil, it would be a major coup for energy independence. Investing in other forms of energy and separating the fuel needed for vehicles from the energy used to power it is a lot better long-term than another oil pipeline which will only run dry in 5-10 years.
I'm signing up for this as well. If I frequent a site, and they have a subscription, I'll pay for it. Some sites have a lifetime of no ads if you toss them half to a whole C-note, so I do that. Other sites offer donations, so they get â25 or so every so often. I'm sure subscription revenue higher than ad revenue, so it is a win/win.
Yes, these things are vulnerable to "cow tipping", but I can see these used to patrol some disused strip mall or other complex to keep the squatters at bay, where having a solution that one can just set up and forget would be quite handy. It also would discourage thieves because squatters or trespassers would have to deal with the robot and either book it or attack it (which now makes them felons for malicious mischief charges.) Shooting the robots then brings armed trespass charges.
If I owned some empty real estate space in a suburban or rural area, with sidewalks smooth enough that the K5s would not topple over, it would make sense to have two units on patrol as an enhancement to a CCTV installation.
I wish that happened. Realistically if Doom were done like how most IAP games are laid out these days, we have to buy IAP for the chainsaw and everything past the fist and pistol, IAP so we can use the powerups, IAP so that the secret panel unlocks, and when we died, either wait 2 hours, or pay $1.99 for three more lives... then the next few levels would be an entirely different app, and we would have to re-buy the rocket launcher and BFG all over again.
I wish Android had the ability to have a "default store", so that Google's Play Store, Amazon's store, F-Droid, or other stores/repositories could be used without having to turn on the "unknown sources" option. That way, a device could be shipped, and the user pick a store they use, or have the ability to download and install from multiple items without needing to go through the sideload mechanism.
It depends on how savvy the person is. If one has basic UNIX abilities, then yes. Set a firewall, set it to not allow anything out unless it is explicitly granted by you.
Even better, using Xposed's XPrivacy is also a major security boost. If some flashlight app is demanding root, trying to get to contacts, trying to get to sites offshore, it will be obvious to the user and thus stopped.
Of course, if the user isn't UNIX savvy, they may end up blocking some outgoing task that needs to phone home and then get mad why their phone isn't working.
As for the malware, if it is an app, the worst it can do is try to install itself as a device administrator (which will require a prompt from the user) which gives it the ability to lock and erase the device at will, as well as the ability to hide itself. Of course, if the user has a rooted device and allows the app access via su, the game is over. However, newer su versions will disallow apps from even prompting for su access unless they declare a permission for it (ACCESS_SUPERUSER) which will be obvious when downlaoded or installed.
Sometimes the new technology was just sitting there disused all along. There are a lot of things that are sitting around that are waiting to be rediscovered. Hybrid cars for example were made in the late 1800s/early 1900s.
There are a lot of factors involved... the invention, making the invention marketable, getting the factories able to mass produce it and the parts required. Just small innovations like a machine that can twist metal links for a chain can mean immense improvements in product availability.
After that, there is legal stuff, and slapping a book's worth of warning labels on it. For example, why does 9mm ammo need a warning of "do not eat" on it?
It is a long and treacherous road to get ideas to market. In theory, it should be easy, such as the time period between 1900 and 1950 where life went in the US from dwelling in mud houses to modern life. Now, the rate of inventions making it to market has all but stopped due to all the hurdles in the way, be it regulatory, vague patents, people that need paid off, or the fact that a lot of VCs are not interested in inventions, but pyramid schemes with built in exit strategies.
Of course, this gives me a worry about the future of the US. The reason why English is the lingua franca of the planet is because of innovation. This can change quickly. Twenty years from now, it may actually be a toss-up if the default language will remain English, or shift to Chinese, Arabic, or even Russian for the global tongue of trade.
Solar and wind are just pieces of a puzzle. If I take an average house, I have to either tear it down and rebuild it so it could use passive solar heating/cooling or I would have to either use a fuel or the electric grid to keep the temperature bearable, especially in Texas.
What Google should have done is look at the missing pieces -- storage and transportation. This could be batteries, super caps, or even relatively energy-consuming conversions like converting water to hydrogen or CO2 in the air to propane. After storage, it becomes transportation. Over really long distances (hundreds of miles), it might be worth it to power a reaction that pulls CO2 from the air to generate propane, ship that via pipeline to be burned and turned back into electricity at the receiving end.
This is an offshoot from off-grid and RV solar charging systems. Oftentimes one will end up with one unit that takes 120 VAC, converts it into the right voltage for the batteries to use at the proper state of charge. However, as inverters become more of a standard fixture in RVs, one unit does the converter/rectifier work, as well as takes 12 volts DC, and turns it into 120VAC.
Most RV systems have a converter/inverter, and the solar panels are fed into a charge controller which is a separate unit. MPPT charge controller prices are dropping, so it is only wise to go for something along those lines (so your 24 volt panels get a lower voltage, but higher amperage going to the batteries, as opposed to a PWM controller which will "lop" off half the voltage, making a 24 volt, 100 watt panel into a 50 watt panel for all intents [1].)
Even though it is a misnomer, since more units are springing up with the inverter/converter/rectifier functionality, they end up getting called inverters, although it is wise to check what type of inverter (MSW versus PSW), and what added functionality is present.
HTTPS requires active MITM attacks to eavesdrop. If one looks at the trail afterwards, there isn't any real way to glean the session key the two machines created... to get that key, Charlie has to actively step between Alice and Bob and capture their pieces, while pretending to be the other person. If both use some signature mechanism, Charlie is SOL.
What might have been better is early on, have Web browsers accept self-signed SSL certs, and show some grey icon for that. Certs validated and signed by a CA, a blue icon. EV certs, green. Couple that with a mechanism that detects an unexpected certificate change, and this could provide a decent level of protection, while making it obvious to the user that if they are concerned about security, do transactions with the green or blue color present.
That applies to all operating systems. When it comes to production, three things apply: Has the patch been tested in an environment as close to what the field is like, can it be applied without much downtime, and is there a way to back it out without causing major headaches.
This is one reason I like virtualization with clusters [1]. If a patch does make it past testing and fouls up a production VM, I'm a snapshot away from going back to a working machine. This isn't a magic bullet solution, but it does help, and there is software which can sit atop the virtualization platform to catch intrusions and automatically roll boxes back to a working snapshot (perhaps taking a snapshot of the hacked VM for forensic purposes.)
[1]: VMWare's fault tolerance mechanism is limited to a VM with one vCPU, but the ability to restart a VM if the physical machine is dead is a good one. Same with Hyper-V.
That's the rub. Turning on encryption is easy. However, how does one do key management?
Arguably, the most secure way would be to have a true secure RNG (using radioactive decay, high speed flip-flops, or political flip-flopping on issues) as a source of randomness, perhaps multiple sources so if one ends up having something periodic, a "bit blender" (be it a hashing algorithm, or just XOR-ing the random number streams.) Then having two copies of the OTP, one at each endpoint.
Realistically, don't see a OTP being used, but maybe the quantum key generation used as a way to create a highly secure key that session keys are generated from.
However, for relatively cheap devices, if they implement crypto even up to WPA2-PSK spec, I'll be impressed. My ideal is to use a set of preshared keys (preferably both a set of symmetrical and assymetric) to generate random session keys via a D-H exchange, and periodically generate a new key.
Slashdot Mirror
Maybe the best answer is to have the fridge have SNMP ability, and let one's own computer walk the MIBs periodically and respond to traps by the appliance. This is an existing protocol, available in virtually every single OS.
The problem is that doing security right isn't cheap, in both buying the right tools, making a proper network topology, and getting everything configured.
Long term, it really means businesses have to lay fiber and create a separate WAN, separate from the Internet, with some top-down management system (virtual circuits), where if machines are not pre-arranged to communicate with each other, they don't have access... and this is done on both the network fabric, and the individual hosts. Dedicated links are a lot more expensive than VPNs, but one isn't a misconfiguration of a router from disaster with them.
Remote access trojans (RATs) are not hard to stomp. If machine "A" has no reason to be communicating outside to the Internet, then it doesn't get access [1]. If it needs to go out, it gets access to the IP range it needs and no other. Network security 101 with the principle of deny everything that isn't whitelisted. This has been in textbooks since 1992 when one used Venama's TCP wrappers on sensitive boxes to ensure only proper hosts could telnet to them (SSH wasn't in use back then because it would have been considered an ITAR munition.) RATs are easily detectable by IDS/IPS installations. In a more secure network, if the traffic isn't MITM-able by the BlueCoat appliance, and it appears encrypted, it doesn't go out. SSH tunnels are easy to spot with monitoring tools, and the kibosh laid on it automatically.
Of course, edge security goes without saying. This isn't hard. ASA appliances are relatively cheap, and the expertise to properly configure them is widespread.
[1]: Realistically, how many machines in a company need Internet access, or access outside their Ethernet segment for most things? One could always allow RDP/Citrix access to a hop box if people wanted external Web access, WSUS and mirroring repositories takes care of patches, and DCs are internal. Or, one can require remote desktop access for the more secure data and "just" use proper endpoint security. Lots of ways to do this securely.
There are some good things about the iOS ecosystem. For starters, if you require the latest iOS version, the piracy rate for apps will be at 0%. If you allow multiple iOS versions, just do a write or read outside your app's sandbox to check for a JB or not. Android has a non-zero piracy rate, but LVL and device-based APK encryption do reduce it to a dull roar.
You can still earn money as a developer. However, you can't follow the herd. If everyone is making fart apps, don't waste the time in making one.
Find a market segment and go with that. For example, Torque is an app that makes a lot of money. It isn't mainstream, but for the task at hand, it is extremely useful, and people will pay for it.
Some ideas/suggestions of what to do:
1: Make a GOOD PGP/gpg program. One that not just does the usual signing/encrypting/validating/decrypting, but uses the operating system's encryption (KeyChain) to stash the private keys. Coupled with an optional passphrase, this provides good protection.
2: Make a utility that can store files on multiple cloud providers at once. That way, if I stash documents and some sync error trashes one provider, I still have the documents saved somewhere else. If there are sync mismatches, give the user the option of using the document with the latest timestamp with saving the old one in an archive directory to be safe.
3: Create an app that is based on option #2, but also encrypts and presents itself as a WebDAV option. This way, one can use their phone as a drag and drop cloud storage device, with the app doing the backend encryption and distributed storage work.
4: A statistical analyzer similar to Minitab or SAS, but scaled down to a device.
5: A device that does TKIP/SKIP authentication like Google's Authenticator, but can use TouchID on iOS, a PIN/passphrase on iOS/Android, and can back the seeds up securely. This way, if I re-ROM my phone, I don't have to redo all my 2FA stuff... just re-import an encrypted backup and be back and running. With the option of a PIN, even if the device is stolen, one's 2FA IDs are still protected.
Swift must be a really good language. Every so often, I get E-mails from recruiters with positions demanding five years of Swift programming skills as part of the core position.
Diesel engines also could use gasoline as fuel. It requires some engineering due to the differences in compression, but it could be done.
I agree... diesel is a better all around fuel. Modern ethanol-based gasoline has a lifetime of weeks, while diesel with bug killer can be stores in a tank for much longer and still be usable.
There is also the biodiesel aspect. Biodiesel can be made from almost anything oily/greasy, be it cooking oil, fat from a meat packing plant, waste motor oil that is filtered, or anything along those lines. Of course, it has different lubricant properties than normal diesel... but if a gasser engine can run on booze, it isn't that hard to adjust programming on a diesel to run on B20-B100.
The days of the smoke-belching, dog-slow Mercedes turbo diesels which forced people to pass on the breakdown lane in order not to get asphyxiated are long gone, even though those were a scourge of the roads. One can walk behind a Sprinter, Ford F-350, or other diesel vehicle made within the past decade, and there won't be a smell, and there is likely to be no smoke, other than when the engine is started.
Of course, there are coal rollers who deliberately de-tune their engines to run rich and reprogram the ECMs for the black smoke... but in my neck of the woods, the local police will actually scrape off the inspection and registration stickers, or even tow a vehicle on the spot (since it is not considered road-legal) to the nearest diesel shop if the DPF/DEF/EGR stuff is deliberately destroyed.
I personally detest wasting fuel. Diesel isn't cheap.
Isn't this what DPF and DEF systems are for? DPF systems mean that there is a filter which gets clogged every so often so the diesel vehicle is in the shop for a â3000 replacement, especially if the vehicle idles often. The DEF system provides for the vehicle being in the shop for a new engine (or at least a new set of injectors and high pressure fuel pump) when a novice vehicle owner gets confused and pours the AdBlue into the fuel tank and not the piss tank. Since the diesel-engined vehicle is kept off the road by both of these things, particulate issues are well addressed.
(/sarcasm.)
We had the ability to have a secure Internet back in the 1990s. However, with the average corporate desktop copy of Windows initially having no security other than logging into the Netware server to show a share, security primarily moved to the network.
The problem with IoT is that we (as in general organizations) have a lot of experience in securing networks. However, all IoT devices are edge devices... and it doesn't take a CCIE to realize the problem with that, especially the fact that the tech to secure machines is far trailing the expertise in securing network fabric.
How about we go to a third model, and that is DMZ networks with hardened chokepoints. We can do this with existing protocols.
For example, we have a subnet that has a fridge, oven, dishwasher, and power distribution unit on it. A central device with a hardened exterior firewall controls what goes out. At an extreme, one can build firewalling functionality into the hardware NIC so if the device's OS is compromised, it still has protection.
The central device uses SNMPv3 to walk the devices. If finds the fridge's internal thermostat is 55 degrees in the freezer, and sends an alert to the company's monitoring station, which alerts the owner via app or SMS. The dishwasher was set and fished, so sends a SNMP trap which lets the user know dishes are ready. Since the user set a flag that he is on vacation, the monitoring device sends a SNMP request to the PDU to shut off power to circuits not needed.
IoT functionality can be done, and can be done securely, with existing tools. It just needs common sense and making sure that what is connected to the Internet is well-hardened, and the "soft and chewy" iOT devices do their communication to an appliance, and the appliance does the rest over the Internet.
LAN communication between devices and the monitor can be well secured. Recent Bluetooth versions do this well, preventing a third party from not just eavesdropping, but spoofing traffic. For even better security, devices can use the power line and encryption over that. Of course, the best security would be dedicated fiber optic cables run in a conduit from the appliances to the monitoring station. Not 100%, but if physical access is gained by an intruder to those cables, the jig is up anyway, and the goal is to protect against remote attacks.
The biggest problem with IoT is that all devices are edge devices when in reality, they should be core (or DMZ) devices with secure device handling the requests. Again, not 100% secure, but if some appliance's IP stack is buggy, it won't be exposed to entire Internet, just anyone nearby that physical location.
If I were deploying an infrastructure, I'd go with a basic layered approach. The sensitive stuff either gets put behind RDP or Citrix (with 2FA to log onto those servers), the edge VPNs definitely get 2FA, and average machines get "plain old" AD logins with passwords changed on a normal schedule like every 30-60 days [1].
Of course, network topology, and devices play a large part in this. This way, a guy in receiving who gets malware on his machine will not affect the computers in finance or development. Endpoint management also helps, but one doesn't know if an attack is going to go through a compromised Web browser, physical access, a disgruntled employee, or a backdoor in the main firewalling routers that allows an attacker full access from the Internet.
Wise use of 2FA does help, but as with all security products, it isn't a magic bullet.
[1]: Only real difference I'd have is that all user accounts would have expiration dates in AD going 6-12 months out, and that an audit every month or so would pop up ones about to expire so the accounts can be either re-validated or left to expire until explicitly needed again. This way, an admin that left quietly where people forgot about won't always have access, as it will end up getting pulled automatically.
MTBF and transfer rate numbers are boring... but those can be just as important, if not more, than the drive's capacity.
With high capacity tier 3 drives, one reason that RAID 6 (or a RAID 50 setup with tiers/groups of disks) is used is because it can take days to rebuild a blown drive. If drives continue to have larger capacities, but I/O stays the same, then we will need to add more parity drives to RAID arrays to support multiple drive failures and still keep the data accessible, better algorithms that run in the background to detect (and fix) bit rot, and bigger/smarter caches.
Maybe this is just me, but I'd rather see drives with double the MTBF than double the capacity. I can always add more drives and arrays. A failed disk will cost time no matter what, even if it is just walking to the server room, pulling it out and replacing it with a spare. For non-enterprise customers, a failed drive can be catastrophic since not many users have RAID arrays for protection.
Bingo. Having computer assisted voting that produces a ballot that is both machine and human readable is a must. Without this paper trail, you have absolutely nothing. Even with crypto, crypto doesn't protect against erasure, and an "accidental" erasure of votes on a voting machine can sway an election.
I was working on an e-voting prototype using Java in the late 1990s. No matter how it worked, there was no way to secure it, so I gave up on the project, because if the device couldn't be hacked, the data on it was destroyable. Distributed storage could easily be hacked/tampered with, and would be hard to admin by volunteers. The hardware could be made more secure, but it would completely destroy voter anonymity.
Instead, David Chaum's Verifiable Voting system is the absolute best thing out there. It provides not just anonymity for votes, but validates ballots were done correctly.
Biometrics might be useful for a lock inside an already secure company, but there are so many existing solutions which work well with AD that cobbling up something can be pointless:
1: Why not just use regular AD authentication at the core, move the 2FA to the edges? I've seen this done using either Cisco software for VPNs, Citrix, or other means. This way, to authenticate from machine to machine (especially if UNIX machines use AD and there isn't a way to add anything), it doesn't take that much. Plus, this saves cash by limiting the need for devices to users who need access from the edge.
2: If 2FA is needed, then why not use CAC/PIV-like cards? Since the US government uses them everywhere, the software for them is available.
3: If 2FA is needed on the cheap, there might be a way to use the Google Authenticator (part of OAuth as above). I have that in place on ESXi machines and other items. However, this means that one has to have a device showing the numbers with them at all times. I also use OAuth and Google's app for Linux VMs that are Internet facing as a backup if I don't have the local machine's SSH key in the remote VM's authorized keys file.
Personally, I'd just use 2FA on the edges or on the machines which need that security. Fewer hassles, and cheaper.
Hydrogen also takes a lot of energy to split from water. Technically it is renewable... and it also is energy source independent (got a hydro plant nearby, like Paraguay, then there may be energy to spare.) This can be a good thing, because the vehicle isn't tied to petroleum like it would be with CNG/LNG or other fossil fuels.
I personally like the idea of getting away from anything dino related as fuel, be it batteries, a la Tesla, or hydrogen fuel. This is going to have to happen sooner or later, and better now as opposed to when a crisis happens, such as Iran deciding to stop letting tankers cross through the Strait of Hormuz.
Long term, hydrogen does use more energy... but getting energy is a matter of will than technology. Thorium reactors have been around for decades. China has gen IV reactors up and running, and are doing their best to get off the imported oil teat. If vehicles can be moved from oil, it would be a major coup for energy independence. Investing in other forms of energy and separating the fuel needed for vehicles from the energy used to power it is a lot better long-term than another oil pipeline which will only run dry in 5-10 years.
I'm signing up for this as well. If I frequent a site, and they have a subscription, I'll pay for it. Some sites have a lifetime of no ads if you toss them half to a whole C-note, so I do that. Other sites offer donations, so they get â25 or so every so often. I'm sure subscription revenue higher than ad revenue, so it is a win/win.
Yes, these things are vulnerable to "cow tipping", but I can see these used to patrol some disused strip mall or other complex to keep the squatters at bay, where having a solution that one can just set up and forget would be quite handy. It also would discourage thieves because squatters or trespassers would have to deal with the robot and either book it or attack it (which now makes them felons for malicious mischief charges.) Shooting the robots then brings armed trespass charges.
If I owned some empty real estate space in a suburban or rural area, with sidewalks smooth enough that the K5s would not topple over, it would make sense to have two units on patrol as an enhancement to a CCTV installation.
I wish that happened. Realistically if Doom were done like how most IAP games are laid out these days, we have to buy IAP for the chainsaw and everything past the fist and pistol, IAP so we can use the powerups, IAP so that the secret panel unlocks, and when we died, either wait 2 hours, or pay $1.99 for three more lives... then the next few levels would be an entirely different app, and we would have to re-buy the rocket launcher and BFG all over again.
I wish Android had the ability to have a "default store", so that Google's Play Store, Amazon's store, F-Droid, or other stores/repositories could be used without having to turn on the "unknown sources" option. That way, a device could be shipped, and the user pick a store they use, or have the ability to download and install from multiple items without needing to go through the sideload mechanism.
It depends on how savvy the person is. If one has basic UNIX abilities, then yes. Set a firewall, set it to not allow anything out unless it is explicitly granted by you.
Even better, using Xposed's XPrivacy is also a major security boost. If some flashlight app is demanding root, trying to get to contacts, trying to get to sites offshore, it will be obvious to the user and thus stopped.
Of course, if the user isn't UNIX savvy, they may end up blocking some outgoing task that needs to phone home and then get mad why their phone isn't working.
As for the malware, if it is an app, the worst it can do is try to install itself as a device administrator (which will require a prompt from the user) which gives it the ability to lock and erase the device at will, as well as the ability to hide itself. Of course, if the user has a rooted device and allows the app access via su, the game is over. However, newer su versions will disallow apps from even prompting for su access unless they declare a permission for it (ACCESS_SUPERUSER) which will be obvious when downlaoded or installed.
Sometimes the new technology was just sitting there disused all along. There are a lot of things that are sitting around that are waiting to be rediscovered. Hybrid cars for example were made in the late 1800s/early 1900s.
There are a lot of factors involved... the invention, making the invention marketable, getting the factories able to mass produce it and the parts required. Just small innovations like a machine that can twist metal links for a chain can mean immense improvements in product availability.
After that, there is legal stuff, and slapping a book's worth of warning labels on it. For example, why does 9mm ammo need a warning of "do not eat" on it?
It is a long and treacherous road to get ideas to market. In theory, it should be easy, such as the time period between 1900 and 1950 where life went in the US from dwelling in mud houses to modern life. Now, the rate of inventions making it to market has all but stopped due to all the hurdles in the way, be it regulatory, vague patents, people that need paid off, or the fact that a lot of VCs are not interested in inventions, but pyramid schemes with built in exit strategies.
Of course, this gives me a worry about the future of the US. The reason why English is the lingua franca of the planet is because of innovation. This can change quickly. Twenty years from now, it may actually be a toss-up if the default language will remain English, or shift to Chinese, Arabic, or even Russian for the global tongue of trade.
Solar and wind are just pieces of a puzzle. If I take an average house, I have to either tear it down and rebuild it so it could use passive solar heating/cooling or I would have to either use a fuel or the electric grid to keep the temperature bearable, especially in Texas.
What Google should have done is look at the missing pieces -- storage and transportation. This could be batteries, super caps, or even relatively energy-consuming conversions like converting water to hydrogen or CO2 in the air to propane. After storage, it becomes transportation. Over really long distances (hundreds of miles), it might be worth it to power a reaction that pulls CO2 from the air to generate propane, ship that via pipeline to be burned and turned back into electricity at the receiving end.
This is an offshoot from off-grid and RV solar charging systems. Oftentimes one will end up with one unit that takes 120 VAC, converts it into the right voltage for the batteries to use at the proper state of charge. However, as inverters become more of a standard fixture in RVs, one unit does the converter/rectifier work, as well as takes 12 volts DC, and turns it into 120VAC.
Most RV systems have a converter/inverter, and the solar panels are fed into a charge controller which is a separate unit. MPPT charge controller prices are dropping, so it is only wise to go for something along those lines (so your 24 volt panels get a lower voltage, but higher amperage going to the batteries, as opposed to a PWM controller which will "lop" off half the voltage, making a 24 volt, 100 watt panel into a 50 watt panel for all intents [1].)
Even though it is a misnomer, since more units are springing up with the inverter/converter/rectifier functionality, they end up getting called inverters, although it is wise to check what type of inverter (MSW versus PSW), and what added functionality is present.
[1]: Note, these are rough numbers.
HTTPS requires active MITM attacks to eavesdrop. If one looks at the trail afterwards, there isn't any real way to glean the session key the two machines created... to get that key, Charlie has to actively step between Alice and Bob and capture their pieces, while pretending to be the other person. If both use some signature mechanism, Charlie is SOL.
What might have been better is early on, have Web browsers accept self-signed SSL certs, and show some grey icon for that. Certs validated and signed by a CA, a blue icon. EV certs, green. Couple that with a mechanism that detects an unexpected certificate change, and this could provide a decent level of protection, while making it obvious to the user that if they are concerned about security, do transactions with the green or blue color present.
That applies to all operating systems. When it comes to production, three things apply: Has the patch been tested in an environment as close to what the field is like, can it be applied without much downtime, and is there a way to back it out without causing major headaches.
This is one reason I like virtualization with clusters [1]. If a patch does make it past testing and fouls up a production VM, I'm a snapshot away from going back to a working machine. This isn't a magic bullet solution, but it does help, and there is software which can sit atop the virtualization platform to catch intrusions and automatically roll boxes back to a working snapshot (perhaps taking a snapshot of the hacked VM for forensic purposes.)
[1]: VMWare's fault tolerance mechanism is limited to a VM with one vCPU, but the ability to restart a VM if the physical machine is dead is a good one. Same with Hyper-V.
That's the rub. Turning on encryption is easy. However, how does one do key management?
Arguably, the most secure way would be to have a true secure RNG (using radioactive decay, high speed flip-flops, or political flip-flopping on issues) as a source of randomness, perhaps multiple sources so if one ends up having something periodic, a "bit blender" (be it a hashing algorithm, or just XOR-ing the random number streams.) Then having two copies of the OTP, one at each endpoint.
Realistically, don't see a OTP being used, but maybe the quantum key generation used as a way to create a highly secure key that session keys are generated from.
However, for relatively cheap devices, if they implement crypto even up to WPA2-PSK spec, I'll be impressed. My ideal is to use a set of preshared keys (preferably both a set of symmetrical and assymetric) to generate random session keys via a D-H exchange, and periodically generate a new key.