Nail, head, hit. My vehicle (which was bought with a non touch screen) has all the basic controls available by buttons or dials. No need to take the eyes of the road to look at the touch screen, punch a tab on it to select the A/C or heat, tap and drag a slider up and down, then hit another tab to control fan speed. Of course, with how UIs are, there will be lag where you can't tell the device noticed your tap or not. At least with a dial, you know that it registered it due to tactile clicks.
My biggest complaint about newer cars is the fact that a touch screen is needed, coupled with the fact that the audio head is on the same CAN as the radio... which means if the radio glitches, the car can stall or go haywire in random ways.
There is a balance between going back to paper and double-entry books versus putting the whole thing so close to the Internet that a single compromised box can make it easy for an attacker to slurp everything down. There are also tools to help separate data, but yet allow people to do their daily jobs.
VDIs come to mind. If one can serve up apps from different desktops, a user can have an external Web browser, internal Web browser, E-mail, the internal finance application, with appropriate separation between all of them.
On a different level is putting assets behind Citrix or RDP. The user can manipulate them, but doesn't have access to fetch the files. This helps limit potential damage, the worst thing being RATs, next would be screenshot snappers/keyloggers, but again, the signature of a RAT should be detected by the network IDS/IPS, especially if that network doesn't allow access to the external Internet other than through an application.
So, there is a balance between unfettered Internet access and a complete airgap, with security maintained. As an extreme, there is always moving back to a text terminal emulator and using SSH or even a 3270 emulator as opposed to going all the way back to paper and pencil.
Hacking something on the Internet is one thing. Compromising SIPRNet or NIPRNet... completely different.
I wonder when businesses will stop trying to put band-aids on this problem and actually build a WAN between themselves that isn't the Internet, nor is connected to the Internet directly. It wasn't that long ago when the Internet wasn't the only WAN (DECNet anyone.) Maybe it is time for businesses to start getting leased lines, laying fiber, and creating networks that are well separated. For smaller businesses, ISPs could offer connections not just to the Internet, but to the business WAN, with ACL rules in place so if machines are not arranged to communicate with each other, they can't.
Again, this isn't a 100% measure... but it sure ups the ante to requiring physical access, especially if endpoints encrypt all traffic between each other.
As for malware, a decent IDS/IPS would have stopped those attacks cold. Some SANs (NetApp for one) can offer tools to look at logical drives and scan off-box for the bad stuff.
The ironic thing about this is that as posted above, electric cars are going mainstream. For a household that already has a normal car for trips, an electric car like the i-MyEV from Mitsubishi makes sense, especially if the commute is short. It is perfect for congested areas because when stopped, the engine requires zero energy to keep going, it requires very little upkeep, can easily keep up with traffic, and don't require going out of one's way to fuel up. Of course, the downside is that for a long trip, one needs to go fetch the ordinary gasser/diesel vehicle, but for most things, the EV does the job.
This was the same with solar. It used to be a "hippie" thing to have solar panels. Now both the granolas and the Tea Party people both have the PV frames and chargers on the roof.
The demand for electric cars is only going to grow. People in the US are not the smartest, but even with gas prices at a low, they know this won't stay this way for long, and it only takes one issue in the Middle East before gas goes back up to $4-$5 a gallon and stays there.
I wouldn't blame the politicians, as they are pawns here. I would blame the fact that the US is the only civilized country that allows anyone to hand money over to a candidate's election campaign without any oversight whatsoever. It doesn't even matter if the money comes from overseas, as anonymous contributions are gladly accepted, and the FEC has little to no oversight on this due to SCOTUS decisions.
If campaigns were regulated like European countries, Canada, or virtually any other organized nation, as opposed to being a game of who has the deepest pockets to buy that election, the US would have far fewer problems and far more responsive elected officials.
Yes, cars require a lot of equipment, and some makes of vehicles can get downright finicky. For example, one European make of car has warnings about loss of performance and potential permanent damage to a vehicle's ECM should the battery be replaced and the replacement battery not "registered" at a dealer. Another make doesn't even have an oil drain plug, and you change the oil by putting a tube into the crankcase and firing up an oil evac pump.
In general, newer cars are decently reliable. Keep the oil changed, replace other consumables when they need it, and 100,000 miles is not a problem. However, when it comes time to fixing them, that is where the "fun" starts. If the ECM, or some other gewgaw on the CAN malfunctions, it may be impossible to track the fault down, pretty much forcing the owner to replace the vehicle.
One local theater chain is doing something about this:
They replaced the scheduled times of The Interview with a Team America sing-along.
Sony and the other theater chains have really screwed the US (and the West in general.) They caved in. NK doesn't have a monopoly on hacking, and in the future, this has emboldened every blackhat group worldwide because they know that they can not just breach a company, but actively control what that company does.
Going into tinfoil hat territory, I wonder if one of the hackers got some dirt on someone high up at Sony (and/or the theater chains) and was blackmailing them with it, so Sony used the NK thing as a way to pull the movie.
What were the smaller threats? A brick through a window? Used to happen all the time when Austin was in a recession in the early 1990s.
Would I go? Yes, because it is very hard to find a barber here in Austin at a reasonable time.
Would I say yes, no matter what? Not without more info, but in general, it wouldn't affect me. If it was a threat significant enough to be worried about, the local PD would have their MRAP there.
The cloud is more than just storage, but usually people use the storage functionality for this.
Realistically, the cloud needs to be treated as another storage medium, just like optical, tape, floppy disks, HDDs, SSDs, and everything else. You plan for media failure, and you build in anti-compromise measures.
The cloud is the same way. If you are an enterprise, you turn on encryption in NetBackup or other program, create a storage pool, and have a mirror on other media (be it an Avamar, a tier 3 disk, or a LTO-6 silo.)
If you are a home user, you encrypt your cloud backups, either by storing things in an encrypted container (TrueCrypt, BitLocker protected windows image, Mac Disk Image, LUKS, PGP Disk volume, etc.), or using a backup program that encrypts. At the worst, there are utilities like BoxCryptor which act similar to CryptFS and map an encrypted layer on top of the cloud drives. Any of this is better than nothing.
Of course, with encryption comes the major bugaboo -- key management. You may have the data securely stashed on the cloud... but without keys, it will be inaccessible. I like having several printed out physical notebook with keys in it, as well as archive grade optical media, and a USB flash drive. Each copy of the notebook goes with a key person (corporate officer), and there is one kept in the local tape safe. This way, if the data center gets completely flattened, it may take days to weeks, but data is still recoverable. This also helps if there is an audit or motion of discovery.
The cloud has its big issues... but treat it as its own piece of media, and it can come in handy. To be more specific, treat each cloud offering as its own media. Amazon Glacier is great for long term archiving, but one needs to well index it, to minimize the stuff retrieved, and Glacier should be the absolute last resort if data is needed, due to the charges for fetching data.
This is a niche that nothing fills. In the past, there were a number of players (Archos, Creative, etc.) which filled this place. However, some players required special software, others would not allow copying music from the device (as it encrypted the files, not just renamed them), and some had poor build quality (one brand of player failed to deburr the metal case, and after two returns due to obvious machining fails, I gave up.)
Eventually, the third parties moved to "media" players, so if one wanted something for audio, one had to buy a much larger physical box because the maker assumed people would watch movies on it.
For a time, only Apple and MS's Zune had MP3 players that had reasonable (greater than 64 GB) capacities.
Right now, there is a hole in the MP3 player market. Someone who can make a MP3 player with 250 gigs of capacity, a MTP/PTP interface (or just allowing the device to mount as a physical drive), support for popular audio formats, and a reasonable battery life even when playing FLAC, would have a definite niche. Not a huge place... but it would have a spot in almost every studio.
For work use, a 3270 terminal does the job well, especially for point of sale systems. Just a terminal is pretty secure, as most likely the serial term servers are not connected to the Internet, and physically tapping the RS232 cable would require physical access.
I would agree that now, having a 3270 emulator is a clean way of doing things. However, I wouldn't be surprised for an intruder to be able to use a RAT on someone's Windows box to slurp the user's password and use the 3270 via remote. If this wasn't the case, then I'd definitely recommend this route (although I'd present an alternative using a 3151/3153 and an AIX/Solaris backend with a curses interface as opposed to VM/ESA since old school UNIX experience seems easier to come by than Big Iron guys.)
I definitely want to sub to your newsletter. In a way, all these breaches are making serial terminals sexy again, just because of the simplicity. Going back to serial terminals may not look as cool at some POS display with a flashy logo, but they do work, and with a good application designer, would work just as well as a graphical application, perhaps better, if the UI was made to be responsive. An attacker would have to have physical access, or have to go after the UNIX server, which is likely extremely hardened [1].
[1]: Solaris 11 turns root into a role, and AIX can be configured to disallow root altogether, so UID 0 is just another user, no special attributes attached. Modern commercial UNIX variants can be locked down quite well.
IT can be completely different, depending on organization structure and people involved.
I have worked in companies where the IT department always had stuff in testing and stayed ahead of the game, not just putting out reports, but workarounds when it became time to roll major upgrades out. I've worked in other departments which were purely reactionary, and the only thing they really did was fight fires with every purchase being under an emergency budget. I've seen the spectrum in between the two extremes.
The problem with IT's reputation is that it is a cost center, and a highly visible one. IT also has a lot of factors, some at opposed ends. For example, if a sales guy demands that he is able to store confidential un-announced products on his personal laptop, how does one answer that demand and still preserve security? The exact answer depends on the organization [1].
IT has always had that pitfall of the new and shiny, be it internal wikis that were deployed, then just sit there, untouched for years, to the cloud, to business social networks, to internal chat mechanisms, and so on. It takes both technical and social expertise to take all the noise and clamor from vendors busting down the door and create a usable, secure setup, while keeping in budget.
The one most important factor is reacting to change. Flexibility is crucial. For example, even though individual machines with drive arrays work well, moving to a SAN in the data center [2] is a necessary move for most applications. Similar with moving from racks of physical hardware to a VM infrastructure [3]. Network-wise, the future will be about dealing with edge devices (IoT stuff), and perhaps even having a separate WAN that is shared among companies that uses leased lines so that business transactions run on a separate network than the Internet.
[1]: One organization would give the sales guy the middle finger. Another would just allow him to email the plans to customers and call it done. In between would be a company laptop with decent FDE on it (BitLocker + TPM), and so on.
[2]: Pick your protocol. iSCSI is the cheapest to implement, but FC is decent, as it is most likely a separate fabric so if the network goes down, your drives stay up. Ideally, if you have compute nodes (like ESXi machines), you have everything boot from the SAN.
I think text consoles, though secure, are dead. Instead, for a network that has to be secure, keep the machines on an isolated subnet (no traffic in/out except to the domain controller, the app server, and a RDP/terminal server.) That way, private data is secured, but people can hit the Web and do what they want, and data can't leak into the RDP link. Best of all worlds.
Another idea is putting the data behind Citrix. Internal machines will still need to be secured, but the machines are more of glorified thin clients, as opposed to actually handling/manipulating internal stuff.
The cloud is cheap, but so is stashing one's valuables in a box underneath a bush by a park bench as opposed to a safety deposit box. As intrusions become more brutal (where sensitive data like employee bank accounts and HR records just doesn't go to the bad guys, but gets posted for the world to see just out of spite), the cloud solution that worked in 2010 has a good chance to destroy a company due to lawsuits in 2015.
Only reason I can guess is politics. QNX makes sense from a legal standpoint because if something does happen that is caused by the audio head, Ford could attest that they used a "known realtime hardened OS", with FIPS, Common Criteria, and other certifications.
With function creep, even though it is abhorrent, the audio head is becoming more and more a part of the CAN, where if it glitches and shits the bus, there goes the ECM and TCM. While something like Linux can work well, I'm guessing Ford wants some CYA documentation and having anything that touches the CAN be a realtime OS might be important for the legal eagles signing off on vehicle models.
In an ideal world, the audio head (especially with remote app functionality) should not be let near the core CAN, and if it has to have some functions (like climate control), that goes through a controller that has sanity checks and the ability to ignore requests if they don't make sense or would cause damage. That way, if the audio head's BlueTooth stack glitches or someone's cat picture uploaded as a background is malformed and crashes the graphics rendering part, the vehicle will still function normally.
There is also unintended consequences. Say every country demands this where their citizens' stuff is stored on domestic data centers. Now, the government of Elbonia passes a law stating that for anti-"terrorism" purposes, their version of a secret police has to have real time access to all servers, which in addition to a vague law or two about seditious speech, starts getting people tossed into prison.
It is the lesser of two evils. The US isn't perfect, but I can have a banner in a window cursing the President and Congress out and not worry about a knock on the door, or a kick in the door. Other countries, citizens there may not be so lucky, and a law forcing Google and others to store data domestically might just be the exact thing a repressive government is dreaming of.
QNX may not be everywhere, but it was a mature product when Linux was just a kernel and people were grafting Minix functionality into the user space.
It does sound like an advertising pitch, but this is accurate about QNX. The OS isn't cheap, but it does offer realtime functionality. It also is designed to be quite stable to where a bug or a hang can cause tremendous disasters, be it software with X-ray machine or figuring out what position to move a set of control rods in a reactor. QNX has excellent internal security, and a decent development kit.
In embedded development, I'd probably use Linux for most items (because it has a wide variety of tools available), however if it is any way connected to something that can kill or seriously injure, like a component on a car's CANbus, I'd go QNX because it is going on 30 years and a very mature product. Realtime OS functionality isn't needed everywhere, but when it is needed, nothing else will do.
As for Ford's use, is it better than SYNC? This is more of an opinion question than anything else. I have had good luck with SYNC across a number of devices (Android and iOS), but others have had horror stories. Time will tell if end users prefer the QNX based audio head over previous ones.
Incorrect. The NSA/NIST produce official, standardized versions of crypto libraries (which is a good thing because there are a lot of people who are clueless about the math principles behind crypto, and would use something braindead like ECB, or if hashing passwords, not bother with a salt.)
In the early 1990s, there was the Clipper chip that would have Skipjack loaded onto it on a secure site. This was something cryptographers were worried about because once that chip became common, the other shoe would drop, which was to make crypto illegal.
There were attempts to make crypto illegal. Around 1991, the honorable senator from Connecticut, Joe Lieberman, was trying to pass bills to make encryption illegal, which is why PRZ wrote PGP 1.0 (and subsequent versions) in the first place, so there was a tool out there, legal or not, to protect people.
As it stand now, whatever encryption algorithm I use is legal here in the US. Realistically, a mainstream algorithm is a good choice since there are a lot of homegrown ones which would get easily broken by a decent cryptographer.
RedHat is in an interesting niche, where it can work on an OS that is a direct downstream of what it makes as a product, and not worry about revenue.
Two reasons: Certifications like FIPS and Common Criteria, and paid support. No company past a SOHO business is going to run production critical servers on an OS without support, especially when contracts, regulations (Sarbanes-Oxley, HIPAA, FERPA, PCI-DSS3), or other items are involved... especially come audit time, both for licensing as well as security and financial.
Apple's system is better, and it is worse in a number of ways. A Mac only will get a certain number of OS X releases, and after that, if you want major security fixes, updates for applications, or other items, you have to replace your hardware. So, OS X is "free" in one sense... but if one factors in the fact that the hardware only will work with new releases for a certain amount of time (for example, six years and counting for my late 2008 aluminum MacBook), Apple does get its due.
With MS, even the latest edition of Windows can run on some pretty ancient hardware, so MS earns their cash by the OS and revisions. If MS got a chunk of change for every PC made, the model might be different.
I think Microsoft sees that the RedHat model of machine subscriptions is lucrative, and wants to go with that. The infrastructure is in place for this. All it would take is moving all machines to a KMS-like model for activation, except pointed at either a server on the LAN to authorize the activations or go to MS to pick up the activation credential.
However, MS pretty much already has that model with SA contracts. No SA contract, then the new versions will cost a good chunk of change.
Problem is, who is going to buy it? Businesses don't want to have further infrastructure aggravations, and already the KMS model ties all Windows machines in a company to the Internet, as the KMS server has to be Internet connected, and machines have to connect to that. People don't want to dig up an old, disused computer, then have to pay a fee to MS per month to turn it on.
Of course, there is the cost issue. Not everyone has the money to pay a monthly subscription, especially in this economy. What will happen is that machines will get activated... but it may not be a genuine MS server or genuine MS OS doing the activation process. Even a price of $10 a month can be too much for a lot of people, either in the US or abroad.
In general, there has been a trend away from both local protection privilege escalation (from user to root.) Mainly the focus has been keeping people out of the box proper, although this does go against the defense in depth concept since once the box gets breached somehow (a security bug that commandeers a Web browser, for example), an attacker can gain a lot by running just with that user's context [1], or even using exploits to get root. Once root, burying kernel modules becomes quite doable.
There needs to be more focus on defense in depth. For example, there needs to be a separate context for a user's Web browser than his/her shell. This way, if/when the browser or add-ons get compromised, the hacked code doesn't have full run of the user account.
Local user protection on Linux has not been that much of an item that has been worked on. Usually at best, there might be a bootloader password or a LUKS encryption prompt to get the boot process past the initial RAM disk. What would be nice to see is work on both signed executables as well as the ability to use the TPM with LUKS for keeping volumes encrypted... but allowing the machine to boot completely without interaction (as the TPM supplies the keys to unlock the volumes.)
As for NFS v3 and earlier, it can be made decently secure if used only by a few hosts, and there can be made networking infrastructure to guard against spoofing, but if this can't be done, NFS v4 or even samba/CIFS might be the protocol of choice. However, as stated above, securing NFS in a shop takes a lot of time, either by having infrastructure in place for Kerberos for NFS v4 to work or having dedicated paths that are difficult for an unauthorized party to access so NFS v3 is secure. There is always going with samba/CIFS in general, but compatibility with the protocol can vary widely between UNIX variants, Linux distributions, or even versions in Linux distributions.
[1]: For the big bucks, just getting access to a user is enough. From there, an attacker can masquerade as that user with fake E-mail, upload documents used, use the user's LAN access to attack other boxes, or just encrypt all the documents for ransom. Spambots and such don't need root access to go out on port 25, nor do botnets need root to perform successful DDoS attempts.
Slashdot Mirror
Nail, head, hit. My vehicle (which was bought with a non touch screen) has all the basic controls available by buttons or dials. No need to take the eyes of the road to look at the touch screen, punch a tab on it to select the A/C or heat, tap and drag a slider up and down, then hit another tab to control fan speed. Of course, with how UIs are, there will be lag where you can't tell the device noticed your tap or not. At least with a dial, you know that it registered it due to tactile clicks.
My biggest complaint about newer cars is the fact that a touch screen is needed, coupled with the fact that the audio head is on the same CAN as the radio... which means if the radio glitches, the car can stall or go haywire in random ways.
There is a balance between going back to paper and double-entry books versus putting the whole thing so close to the Internet that a single compromised box can make it easy for an attacker to slurp everything down. There are also tools to help separate data, but yet allow people to do their daily jobs.
VDIs come to mind. If one can serve up apps from different desktops, a user can have an external Web browser, internal Web browser, E-mail, the internal finance application, with appropriate separation between all of them.
On a different level is putting assets behind Citrix or RDP. The user can manipulate them, but doesn't have access to fetch the files. This helps limit potential damage, the worst thing being RATs, next would be screenshot snappers/keyloggers, but again, the signature of a RAT should be detected by the network IDS/IPS, especially if that network doesn't allow access to the external Internet other than through an application.
So, there is a balance between unfettered Internet access and a complete airgap, with security maintained. As an extreme, there is always moving back to a text terminal emulator and using SSH or even a 3270 emulator as opposed to going all the way back to paper and pencil.
Hacking something on the Internet is one thing. Compromising SIPRNet or NIPRNet... completely different.
I wonder when businesses will stop trying to put band-aids on this problem and actually build a WAN between themselves that isn't the Internet, nor is connected to the Internet directly. It wasn't that long ago when the Internet wasn't the only WAN (DECNet anyone.) Maybe it is time for businesses to start getting leased lines, laying fiber, and creating networks that are well separated. For smaller businesses, ISPs could offer connections not just to the Internet, but to the business WAN, with ACL rules in place so if machines are not arranged to communicate with each other, they can't.
Again, this isn't a 100% measure... but it sure ups the ante to requiring physical access, especially if endpoints encrypt all traffic between each other.
As for malware, a decent IDS/IPS would have stopped those attacks cold. Some SANs (NetApp for one) can offer tools to look at logical drives and scan off-box for the bad stuff.
The movie might not be the greatest, but maybe a random drawing for gift cards for LG and Samsung products might help as well.
Good kimchi on the house wouldn't hurt either.
Sounds like the Alamo Drafthouse needs to show the 2012 remake of Red Dawn...
The ironic thing about this is that as posted above, electric cars are going mainstream. For a household that already has a normal car for trips, an electric car like the i-MyEV from Mitsubishi makes sense, especially if the commute is short. It is perfect for congested areas because when stopped, the engine requires zero energy to keep going, it requires very little upkeep, can easily keep up with traffic, and don't require going out of one's way to fuel up. Of course, the downside is that for a long trip, one needs to go fetch the ordinary gasser/diesel vehicle, but for most things, the EV does the job.
This was the same with solar. It used to be a "hippie" thing to have solar panels. Now both the granolas and the Tea Party people both have the PV frames and chargers on the roof.
The demand for electric cars is only going to grow. People in the US are not the smartest, but even with gas prices at a low, they know this won't stay this way for long, and it only takes one issue in the Middle East before gas goes back up to $4-$5 a gallon and stays there.
I wouldn't blame the politicians, as they are pawns here. I would blame the fact that the US is the only civilized country that allows anyone to hand money over to a candidate's election campaign without any oversight whatsoever. It doesn't even matter if the money comes from overseas, as anonymous contributions are gladly accepted, and the FEC has little to no oversight on this due to SCOTUS decisions.
If campaigns were regulated like European countries, Canada, or virtually any other organized nation, as opposed to being a game of who has the deepest pockets to buy that election, the US would have far fewer problems and far more responsive elected officials.
Yes, cars require a lot of equipment, and some makes of vehicles can get downright finicky. For example, one European make of car has warnings about loss of performance and potential permanent damage to a vehicle's ECM should the battery be replaced and the replacement battery not "registered" at a dealer. Another make doesn't even have an oil drain plug, and you change the oil by putting a tube into the crankcase and firing up an oil evac pump.
In general, newer cars are decently reliable. Keep the oil changed, replace other consumables when they need it, and 100,000 miles is not a problem. However, when it comes time to fixing them, that is where the "fun" starts. If the ECM, or some other gewgaw on the CAN malfunctions, it may be impossible to track the fault down, pretty much forcing the owner to replace the vehicle.
One local theater chain is doing something about this:
They replaced the scheduled times of The Interview with a Team America sing-along.
Sony and the other theater chains have really screwed the US (and the West in general.) They caved in. NK doesn't have a monopoly on hacking, and in the future, this has emboldened every blackhat group worldwide because they know that they can not just breach a company, but actively control what that company does.
Going into tinfoil hat territory, I wonder if one of the hackers got some dirt on someone high up at Sony (and/or the theater chains) and was blackmailing them with it, so Sony used the NK thing as a way to pull the movie.
What were the smaller threats? A brick through a window? Used to happen all the time when Austin was in a recession in the early 1990s.
Would I go? Yes, because it is very hard to find a barber here in Austin at a reasonable time.
Would I say yes, no matter what? Not without more info, but in general, it wouldn't affect me. If it was a threat significant enough to be worried about, the local PD would have their MRAP there.
The cloud is more than just storage, but usually people use the storage functionality for this.
Realistically, the cloud needs to be treated as another storage medium, just like optical, tape, floppy disks, HDDs, SSDs, and everything else. You plan for media failure, and you build in anti-compromise measures.
The cloud is the same way. If you are an enterprise, you turn on encryption in NetBackup or other program, create a storage pool, and have a mirror on other media (be it an Avamar, a tier 3 disk, or a LTO-6 silo.)
If you are a home user, you encrypt your cloud backups, either by storing things in an encrypted container (TrueCrypt, BitLocker protected windows image, Mac Disk Image, LUKS, PGP Disk volume, etc.), or using a backup program that encrypts. At the worst, there are utilities like BoxCryptor which act similar to CryptFS and map an encrypted layer on top of the cloud drives. Any of this is better than nothing.
Of course, with encryption comes the major bugaboo -- key management. You may have the data securely stashed on the cloud... but without keys, it will be inaccessible. I like having several printed out physical notebook with keys in it, as well as archive grade optical media, and a USB flash drive. Each copy of the notebook goes with a key person (corporate officer), and there is one kept in the local tape safe. This way, if the data center gets completely flattened, it may take days to weeks, but data is still recoverable. This also helps if there is an audit or motion of discovery.
The cloud has its big issues... but treat it as its own piece of media, and it can come in handy. To be more specific, treat each cloud offering as its own media. Amazon Glacier is great for long term archiving, but one needs to well index it, to minimize the stuff retrieved, and Glacier should be the absolute last resort if data is needed, due to the charges for fetching data.
This is a niche that nothing fills. In the past, there were a number of players (Archos, Creative, etc.) which filled this place. However, some players required special software, others would not allow copying music from the device (as it encrypted the files, not just renamed them), and some had poor build quality (one brand of player failed to deburr the metal case, and after two returns due to obvious machining fails, I gave up.)
Eventually, the third parties moved to "media" players, so if one wanted something for audio, one had to buy a much larger physical box because the maker assumed people would watch movies on it.
For a time, only Apple and MS's Zune had MP3 players that had reasonable (greater than 64 GB) capacities.
Right now, there is a hole in the MP3 player market. Someone who can make a MP3 player with 250 gigs of capacity, a MTP/PTP interface (or just allowing the device to mount as a physical drive), support for popular audio formats, and a reasonable battery life even when playing FLAC, would have a definite niche. Not a huge place... but it would have a spot in almost every studio.
For work use, a 3270 terminal does the job well, especially for point of sale systems. Just a terminal is pretty secure, as most likely the serial term servers are not connected to the Internet, and physically tapping the RS232 cable would require physical access.
I would agree that now, having a 3270 emulator is a clean way of doing things. However, I wouldn't be surprised for an intruder to be able to use a RAT on someone's Windows box to slurp the user's password and use the 3270 via remote. If this wasn't the case, then I'd definitely recommend this route (although I'd present an alternative using a 3151/3153 and an AIX/Solaris backend with a curses interface as opposed to VM/ESA since old school UNIX experience seems easier to come by than Big Iron guys.)
I definitely want to sub to your newsletter. In a way, all these breaches are making serial terminals sexy again, just because of the simplicity. Going back to serial terminals may not look as cool at some POS display with a flashy logo, but they do work, and with a good application designer, would work just as well as a graphical application, perhaps better, if the UI was made to be responsive. An attacker would have to have physical access, or have to go after the UNIX server, which is likely extremely hardened [1].
[1]: Solaris 11 turns root into a role, and AIX can be configured to disallow root altogether, so UID 0 is just another user, no special attributes attached. Modern commercial UNIX variants can be locked down quite well.
IT can be completely different, depending on organization structure and people involved.
I have worked in companies where the IT department always had stuff in testing and stayed ahead of the game, not just putting out reports, but workarounds when it became time to roll major upgrades out. I've worked in other departments which were purely reactionary, and the only thing they really did was fight fires with every purchase being under an emergency budget. I've seen the spectrum in between the two extremes.
The problem with IT's reputation is that it is a cost center, and a highly visible one. IT also has a lot of factors, some at opposed ends. For example, if a sales guy demands that he is able to store confidential un-announced products on his personal laptop, how does one answer that demand and still preserve security? The exact answer depends on the organization [1].
IT has always had that pitfall of the new and shiny, be it internal wikis that were deployed, then just sit there, untouched for years, to the cloud, to business social networks, to internal chat mechanisms, and so on. It takes both technical and social expertise to take all the noise and clamor from vendors busting down the door and create a usable, secure setup, while keeping in budget.
The one most important factor is reacting to change. Flexibility is crucial. For example, even though individual machines with drive arrays work well, moving to a SAN in the data center [2] is a necessary move for most applications. Similar with moving from racks of physical hardware to a VM infrastructure [3]. Network-wise, the future will be about dealing with edge devices (IoT stuff), and perhaps even having a separate WAN that is shared among companies that uses leased lines so that business transactions run on a separate network than the Internet.
[1]: One organization would give the sales guy the middle finger. Another would just allow him to email the plans to customers and call it done. In between would be a company laptop with decent FDE on it (BitLocker + TPM), and so on.
[2]: Pick your protocol. iSCSI is the cheapest to implement, but FC is decent, as it is most likely a separate fabric so if the network goes down, your drives stay up. Ideally, if you have compute nodes (like ESXi machines), you have everything boot from the SAN.
[3]: Again, this varies on application.
I think text consoles, though secure, are dead. Instead, for a network that has to be secure, keep the machines on an isolated subnet (no traffic in/out except to the domain controller, the app server, and a RDP/terminal server.) That way, private data is secured, but people can hit the Web and do what they want, and data can't leak into the RDP link. Best of all worlds.
Another idea is putting the data behind Citrix. Internal machines will still need to be secured, but the machines are more of glorified thin clients, as opposed to actually handling/manipulating internal stuff.
The cloud is cheap, but so is stashing one's valuables in a box underneath a bush by a park bench as opposed to a safety deposit box. As intrusions become more brutal (where sensitive data like employee bank accounts and HR records just doesn't go to the bad guys, but gets posted for the world to see just out of spite), the cloud solution that worked in 2010 has a good chance to destroy a company due to lawsuits in 2015.
Only reason I can guess is politics. QNX makes sense from a legal standpoint because if something does happen that is caused by the audio head, Ford could attest that they used a "known realtime hardened OS", with FIPS, Common Criteria, and other certifications.
With function creep, even though it is abhorrent, the audio head is becoming more and more a part of the CAN, where if it glitches and shits the bus, there goes the ECM and TCM. While something like Linux can work well, I'm guessing Ford wants some CYA documentation and having anything that touches the CAN be a realtime OS might be important for the legal eagles signing off on vehicle models.
In an ideal world, the audio head (especially with remote app functionality) should not be let near the core CAN, and if it has to have some functions (like climate control), that goes through a controller that has sanity checks and the ability to ignore requests if they don't make sense or would cause damage. That way, if the audio head's BlueTooth stack glitches or someone's cat picture uploaded as a background is malformed and crashes the graphics rendering part, the vehicle will still function normally.
There is also unintended consequences. Say every country demands this where their citizens' stuff is stored on domestic data centers. Now, the government of Elbonia passes a law stating that for anti-"terrorism" purposes, their version of a secret police has to have real time access to all servers, which in addition to a vague law or two about seditious speech, starts getting people tossed into prison.
It is the lesser of two evils. The US isn't perfect, but I can have a banner in a window cursing the President and Congress out and not worry about a knock on the door, or a kick in the door. Other countries, citizens there may not be so lucky, and a law forcing Google and others to store data domestically might just be the exact thing a repressive government is dreaming of.
QNX may not be everywhere, but it was a mature product when Linux was just a kernel and people were grafting Minix functionality into the user space.
It does sound like an advertising pitch, but this is accurate about QNX. The OS isn't cheap, but it does offer realtime functionality. It also is designed to be quite stable to where a bug or a hang can cause tremendous disasters, be it software with X-ray machine or figuring out what position to move a set of control rods in a reactor. QNX has excellent internal security, and a decent development kit.
In embedded development, I'd probably use Linux for most items (because it has a wide variety of tools available), however if it is any way connected to something that can kill or seriously injure, like a component on a car's CANbus, I'd go QNX because it is going on 30 years and a very mature product. Realtime OS functionality isn't needed everywhere, but when it is needed, nothing else will do.
As for Ford's use, is it better than SYNC? This is more of an opinion question than anything else. I have had good luck with SYNC across a number of devices (Android and iOS), but others have had horror stories. Time will tell if end users prefer the QNX based audio head over previous ones.
I was wondering that. When used with a website, it would have to be a browser extension.
In any case, this isn't too hard to defeat, just run it in a VM or a sandbox, and call it done.
Incorrect. The NSA/NIST produce official, standardized versions of crypto libraries (which is a good thing because there are a lot of people who are clueless about the math principles behind crypto, and would use something braindead like ECB, or if hashing passwords, not bother with a salt.)
In the early 1990s, there was the Clipper chip that would have Skipjack loaded onto it on a secure site. This was something cryptographers were worried about because once that chip became common, the other shoe would drop, which was to make crypto illegal.
There were attempts to make crypto illegal. Around 1991, the honorable senator from Connecticut, Joe Lieberman, was trying to pass bills to make encryption illegal, which is why PRZ wrote PGP 1.0 (and subsequent versions) in the first place, so there was a tool out there, legal or not, to protect people.
As it stand now, whatever encryption algorithm I use is legal here in the US. Realistically, a mainstream algorithm is a good choice since there are a lot of homegrown ones which would get easily broken by a decent cryptographer.
RedHat is in an interesting niche, where it can work on an OS that is a direct downstream of what it makes as a product, and not worry about revenue.
Two reasons: Certifications like FIPS and Common Criteria, and paid support. No company past a SOHO business is going to run production critical servers on an OS without support, especially when contracts, regulations (Sarbanes-Oxley, HIPAA, FERPA, PCI-DSS3), or other items are involved... especially come audit time, both for licensing as well as security and financial.
Apple's system is better, and it is worse in a number of ways. A Mac only will get a certain number of OS X releases, and after that, if you want major security fixes, updates for applications, or other items, you have to replace your hardware. So, OS X is "free" in one sense... but if one factors in the fact that the hardware only will work with new releases for a certain amount of time (for example, six years and counting for my late 2008 aluminum MacBook), Apple does get its due.
With MS, even the latest edition of Windows can run on some pretty ancient hardware, so MS earns their cash by the OS and revisions. If MS got a chunk of change for every PC made, the model might be different.
I think Microsoft sees that the RedHat model of machine subscriptions is lucrative, and wants to go with that. The infrastructure is in place for this. All it would take is moving all machines to a KMS-like model for activation, except pointed at either a server on the LAN to authorize the activations or go to MS to pick up the activation credential.
However, MS pretty much already has that model with SA contracts. No SA contract, then the new versions will cost a good chunk of change.
Problem is, who is going to buy it? Businesses don't want to have further infrastructure aggravations, and already the KMS model ties all Windows machines in a company to the Internet, as the KMS server has to be Internet connected, and machines have to connect to that. People don't want to dig up an old, disused computer, then have to pay a fee to MS per month to turn it on.
Of course, there is the cost issue. Not everyone has the money to pay a monthly subscription, especially in this economy. What will happen is that machines will get activated... but it may not be a genuine MS server or genuine MS OS doing the activation process. Even a price of $10 a month can be too much for a lot of people, either in the US or abroad.
In general, there has been a trend away from both local protection privilege escalation (from user to root.) Mainly the focus has been keeping people out of the box proper, although this does go against the defense in depth concept since once the box gets breached somehow (a security bug that commandeers a Web browser, for example), an attacker can gain a lot by running just with that user's context [1], or even using exploits to get root. Once root, burying kernel modules becomes quite doable.
There needs to be more focus on defense in depth. For example, there needs to be a separate context for a user's Web browser than his/her shell. This way, if/when the browser or add-ons get compromised, the hacked code doesn't have full run of the user account.
Local user protection on Linux has not been that much of an item that has been worked on. Usually at best, there might be a bootloader password or a LUKS encryption prompt to get the boot process past the initial RAM disk. What would be nice to see is work on both signed executables as well as the ability to use the TPM with LUKS for keeping volumes encrypted... but allowing the machine to boot completely without interaction (as the TPM supplies the keys to unlock the volumes.)
As for NFS v3 and earlier, it can be made decently secure if used only by a few hosts, and there can be made networking infrastructure to guard against spoofing, but if this can't be done, NFS v4 or even samba/CIFS might be the protocol of choice. However, as stated above, securing NFS in a shop takes a lot of time, either by having infrastructure in place for Kerberos for NFS v4 to work or having dedicated paths that are difficult for an unauthorized party to access so NFS v3 is secure. There is always going with samba/CIFS in general, but compatibility with the protocol can vary widely between UNIX variants, Linux distributions, or even versions in Linux distributions.
[1]: For the big bucks, just getting access to a user is enough. From there, an attacker can masquerade as that user with fake E-mail, upload documents used, use the user's LAN access to attack other boxes, or just encrypt all the documents for ransom. Spambots and such don't need root access to go out on port 25, nor do botnets need root to perform successful DDoS attempts.