Firewall and AV products will not catch 0-day exploits of the Web browser and add-ons. If they are pulled via SSL, even the best SPI firewall will be bested, unless one goes with a MITM system and forces all inside machines to trust the MITM appliance's key as a root one.
Browser exploits are the biggest vector of infection these days, and XP has little to no resistance innately against those, other than running as a non-admin user... and even then, malware can do a lot with a regular user's context.
Even without admin rights, malware can do a lot of harm with just user profile data.
XP is very lightweight (runs well in 512MB of RAM), so it makes for a great OS to run in a VM for Web browsing. Have the user that the Web browser is running in be a non-admin, use the above add-ons, and use a sandboxing program like sandboxie, and one can have decent protection. Every few weeks or so, roll back the snapshot so if something did get past the sandbox, it would be gone. Of course, bookmarks would have to be saved somewhere else, but that isn't an impossible task. For AV protection, something like Malwarebytes that blocks rogue IPs is decent, but usually AV software is useless against most attacks due to the 0 day nature.
What is annoying is the pulse and glide hypermiling thing... accelerating to 70, dropping to 55, repeating... supposedly is good for gas, but hoses traffic because of the speed changes.
The irony is -- it seems to be only Priuses. Camry hybrid drivers don't have that issue. Neither do the people driving the Lexus models that are hybrids. Neither do Ford hybrid drivers, nor the Insight/Civic drivers... it is just that one model of vehicle that seems to attract the people who tailgate the semis, pulse and glide, refuse to accelerate, etc.
Even more ironic... the Prius isn't that bad a vehicle. I've test-driven one and they go about the same as other small cars... not extremely fast, but not a Geo Metro either.
To boot, I can tack an inverter on the traction battery and have enough wattage available to jump start almost anything on the road with a charger. The inverter also comes in handy if there is a power blackout, since the Prius can be used as a fairly efficient generator that is decently quiet, and with the emissions on it, it puts out less harmful exhaust than a putt-putt generator of the same wattage.
btrfs has been "experimental" for quite a long time (2009?) To compare, Linux went from MINIX's filesystem to ext2 in two years, which lasted quite a while. It takes time to get a filesystem going, but five years is almost an eternity in the computer world, and realistically, Linux should have chucked the LVM2/ext4 combination long ago for ZFS or something ZFS-like.
The good thing is that with FB's devs hammering on btrfs, that will do nothing but improve things and get btrfs ready for prime time use in the enterprise.
You are not the only person who have reported data loss on btrfs. Normally I wouldn't worry about Linux filesystems (even ext4 became rock solid after a while.) However, I worry about what I hear from people who use btrfs.
One concern is that a filesystem can't check for bit rot by itself. True bit rot checking requires at least some working with the LVM layer to check CRCs, find a damaged sector and fix it. I've read that btrfs can catch some bitrot issues, (and please correct me if wrong), but it can't catch/correct anywhere near as much as ZFS or Storage Spaces + ReFS can. btrfs also uses a 32 bit CRC, rather than a 64 bit one.
I'm hoping that Facebook's coders can find the issues with btrfs and squash them. There are not many companies with the sheer server use of FB, and if they can get it working solidly, btrfs should be more than ready for prime time for everyone else.
I appreciate that link. That is very useful. It would be nice if it was part of EPEL directly. I thought the ZFS development was dead on this, but apparently there was a release last August.
IMHO, this is a very good thing. btrfs doesn't have as many capabilities that ZFS or Storage Spaces/ReFS possesses.
However, it is finally time that Linux has a filesystem that supports the latest/greatest enterprise features (deduplication and the ability to combat bit rot.)
Realistically, it would be nice to see the native (not FUSE based) code from OpenZFS be included as an alternative, but the CDDL/GPL conflicts likely will make this a no-go.
Why should they be on a network at all? My refrigerator does just fine with a basic thermostat, electrical fusing, a device to pour water into a mold, dump it in a bin when frozen, then stop dumping it when the bin fills up, a switch to turn on the light when the door opens and a fan so it runs without the need to be defrosted. The additional gewgaws don't help with core operation.
Same with a stove or a microwave. For safety's sake, it should only be able to be turned on by someone who is physically present.
Sometimes, there is just no real point in adding a device to the IoT, and the fewer devices that have networks, the fewer attack vectors an attacker will have to operate with.
This doesn't mean that isolated networks are bad... for example a vehicle needs the CANBus. However, if one doesn't need to have that functionality in a toaster, why built it in?
If we have to have a network or bus for statuses, why not a read-only bus, essentially like a serial port with the return line cut so the device can send status messages out, but not have them go back. The basic concept of a data diode. This way, one can tell if their fridge is over temperature, but a blackhat can't log on and turn the fridge off and spoil someone's steak stash.
Very true. In fact, this is something mentioned in the pramble of Phil Zimmerman's PGP, with that people should encrypt their writings just as one sticks papers in an envelope and doesn't send everything via postcards.
However, appearance matters, and TOR has a negative connotation. Having a website that appears on the up and up to discuss full disclosure, and have it have the appearances of being legit is a completely different issue from getting TOR out of the shadows.
The problem is that there is craploads of bandwidth available on the LAN... but here in the US, WAN connections are relatively slow and pricy.
A good example of this is the few terabytes of space I have on Google Drive. If I want to kick a terabyte of data across a cable link, there is a good chance that I'd be handed a $250 bill for the bandwidth used. If I tried moving a TB over LTE... that will be a five digit bill on every single cellular provider in the US. So, the cloud storage is nice... but storing it becomes expensive, as the $250 to kick a TB over could buy two hard disks that the data gets copied on and then stored separate places... and access to data via a USB port is free (for now...)
So, cloud technology sounds great... but having a grand warehouse is one thing... but if the roads are all one lane tollways that take 2-3 days to get out of a city to store stuff there, it is pointless.
The future of storage really can't be the cloud, other than using the cloud as a piece of media that has a high cost for access, high reliability, low security (you encrypt data before it goes out), and high accessibility.
TOR is one thing, but I'd rather have the EFF step in, so there isn't any appearance of the list being shady. It might be legal to hide in a back alley and make sales transactions in cash, but it is a lot better for first impressions to have a storefront and the appearance of being a mainstream service.
This FD list is probably one of the most critical items to general computer security we have next to a vetted cipher suite.
It isn't "IT", but there are degrees in IS, along the lines of business management. This is another path, likely a profitable one since it gets one closer to PM/PHB types of jobs... those are the jobs that will stay even after the corporate axemen come to visit with the pink slips.
5: Locks and integrity. You have two threads updating one variable. Without some sort of transaction/lock/mutex/semaphore system, one can get very unpredictable results. This is a subset of #3 above, but variable manipulation can be a basic thing overlooked.
6: Choosing the proper variable type in a strongly typed language. Yes, one can always use long doubles for every floating point calculation, similar with long longs... but when a counter never gets past 16, it wastes space. Yes, the pressure to conserve RAM and disk space isn't as much as it used to be, but embedded programming is only going to grow, so resource use will be an issue for a number of projects.
I've never understood the point of a degree from a non-accredited institution. If the university isn't accredited, I'd probably be better off licensing an official Miskatonic University degree plaque from HP Lovecraft's estate.
The parent nailed it. I'd see about the reimbursement item.
Also, sometimes OS certificates can get one in the door as well. A CCIE can get one in the door, similar with a MCSE. For the tech people, it doesn't mean as much, but the HR department are the people that round-file resumes or pass resumes on, so those are the people that one has to get past first, then one will need to show the IT people what one can really do.
I'm pretty sure that the rationale for slack physical security (other than the cash box) is that the store clerk or the camera pointed at it will discourage people from drilling holes in the CPU.
As per a previous/. article, maybe ATM makers moving to a new OS and PC might help matters. Linux is a good candidate. No AutoRun/AutoPlay capability present for starters (although Windows can have it easily turned off as well.)
Ideally, what might be best is to move to a motherboard that is designed from the ground up to make it tamper resistant. Yes, the initial expense might be a bit high, but once made, the only thing needed to upgrade future ATMs would be new graphics for the dancing animals in the background and signed OS updates for future security issues. ARM itself has TrustZone and TPM capabilities... and an ATM is where those capabilities would be perfect for the job without expensive additional hardware or ASICs.
It isn't the absolute best fix, but MS's EMET (Enhanced Mitigation Experience Toolkit), does stop any attacks via this route. I'm sure EMET probably breaks some apps (easily fixed by adding exceptions, and probably why this tool isn't included in the base OS), but it is worth installing and using.
This reminds me of the desktop publishing "industry" back in the late 1980s. Slap a Mac SE/30, a copy of PageMaker and a laser printer in front of someone, and that ended up a desktop publishing service.
3D printing is around the same type of thing. We will see features get added to printers (more filaments, higher "resolution", easier to use software, ability to have stuff automatically fabbed by sintered Iconel from a nearby shop, etc.), the price drop to a few hundred dollars, then the printers will be "good enough", and people will move to the next thing. Once operating systems have native 3D printing support (i.e. allow a printer to be plugged in and work without needing to install any third party stuff) , the technology will be pretty mature.
Maybe with the conventional model of "it builds! Ship it!" and bottom dollar offshored dev houses, this is understandable, but a well written program, this shouldn't be the case.
Ideally, a program should be written, alpha tested, beta tested, then the version 1.0.0 release put out, which would really be 1.14.102 by today's standards.
A good example of this is Netware 3.1.1. It is pointless to bother with by today's standards, but it had an extremely long life without needing constant updates for security issues.
TFA tells us nothing. Even the followup about 2.6.18 being the worst culprit and the note that upgrading the kernel will not help makes it even more pointless.
My fix: yum upgrade, and if the update does grab a new kernel, reboot. There was a kernel bug (long since patched) a few years ago that allowed attacks past even SELinux... but if one is running a recent distro, this shouldn't be an issue.
Of course, one should doublecheck what is likely the real culprit... applications like apache and its modules, and perhaps check for compromised credentials [1].
[1]: On Internet-facing machines, if possible, I configure ssh to only allow public/private keys and no passwords. That way, if the remote machine gets completely pwned, the attacker will have my SSH public key, which is a lot less of an issue than having a hashed password list.
I've seen XP on some ATMs, not XPe, although it does get annoying when an ATM is down due to an XP activation screen.
The ATM industry needs to stop being pennywise and pound foolish.
Instead, they need to design their platform once, do it right, then as time goes on, add a UI refresh every so often so the cute cartoon characters get a facelift every year or two.
Were it up to me with ATM design, I'd probably charge off a quarter profit to do the architecture right, then once done, pretty much coast from there.
First, I'd give a lot of consideration to QNX. ATMs are not really needing a RTOS, but QNX has an excellent reputation for security (with decent government certifications to back that.) From there, add a TPM chip, userland, and the application. Done right, someone plugging in an unauthorized USB flash drive won't be able to do as much, compared to XP with AutoPlay/AutoRun turned on.
Linux is also a good choice. One could go with a full userland or an Android style userland, both with SELinux to minimize damage. Linux may not have the C2 cert that QNX does, but it will hold its own in security, if done right.
What I meant to state is that is a very good thing that PGP supports more than just a file on a USB flash drive. Having something like a smart card + reader, eToken or a similar USB based device is a lot better than a file on media, just because an attacker can't just copy the contents off, which is a possibility if the USB flash drive was left plugged into the machine.
One of my laptops still uses an Aladdin eToken (before they were bought out by Safenet) as a means of booting. That way, I know that if I have the token on my physical keyring, the laptop isn't going to be decrypted anytime soon... and if someone does get the token and types the PIN wrong more than three times, the token will physically lock... blocking brute force attempts completely.
PS: Thanks for the release notes on your other note. I hit the Symantec site, and they were behind on what was supported. I definitely stand corrected there.
Funding a new moon shot and colony would make a new economic boom. The last Space Age gave us a lot of useful items. Another moon race, this time with tech from this decade instead of 1960s technology may bring about a lot of useful side projects.
At the minimum, it would bring a renaissance to both embedded programming and computer development in general (mainly because there is no room for error, and shipping an "early alpha" as release code just won't cut it.) It might even result in software development models that are not "at this date, build the tree and ship regardless of the bug report states" which seems to be the usual case.
Maybe it might get funding for a space elevator which would make getting on and off the Earth a lot easier, coupled with a similar one on the moon.
Even if the money made nothing, it sure at least paid for some research which might be useful later on, similar to Corning's Gorilla Glass.
TrueCrypt is decent, but it can't hurt to have a utility that is updated and maintained with similar functionality. Truecrypt is going over two years without an update. It is a very good program, but PGP has a lot of functionality (public/private key exchange and upkeep, web of trust, etc.) that TC doesn't have.
Of course, one can use GNUpg and TrueCrypt. The command line works well, but GUI-wise, Symantec Encryption Desktop Professional (i.e. PGP Desktop) is just a lot easier to get around in.
One side note -- PGP Desktop isn't officially supported on Windows 8 and 8.1... but it does work.
I agree with you. I don't know what to call it, other than a reverse Midas touch.
The ironic thing is that Symantec's PGP was the only program available for OS X that did FDE encryption before FileVault 2 came out. It was fairly messy how it loaded in, but it did work and did protect all data on the HDD.
PGPDisk also has the ability to grow/shrink an encrypted volume, which is a nice thing to have. TrueCrypt sort of has this capability, but uses sparse files (i.e. if the file gets copied via Samba, it will take up the full space given, even though most of the encrypted volume is zeroes.)
Going back earlier, Symantec also had a very well written edition of PGP for PalmOS and Windows Mobile, with encrypted volumes.
Symantec has a very kick-ass opportunity right now. They can capitalize on the general concern of both businesses and people and sell not just PGP Desktop, but a complete infrastructure going past BitLocker where a cryptographic token would be required for the OS to load. Not just a file on a USB flash drive, but a token where the key is well protected even from physical attack.
It blows my mind that they have the encryption market cornered with a solution that starts on boot, handles Samba shares, can handle files as disks similar to TrueCrypt, can function as a ZIP archiving utility, and can encrypt individual files with ease. However, they either let things sit, or price themselves out of the market.
Another example is the PGP server. This functionality is very useful for a company. It allows key recovery and ADKs, without going down the black hole of key escrow.
Symantec just has so much potential with the companies they own. Things like Ghost and Veritas's LVM replacement come to mind.
Even with compilers, they also have had things like a very solid C++ compiler for DOS and Windows 3.1 which shipped with more than 2 and a half feet of printed manuals, with every single function all described in good detail. I've not seen something that well documented outside of some IBM Redbooks.
I completely agree with the parent -- Symantec needs to "unfuck" some of their offerings and go for the target markets at a non-enterprise price. At the minimum, spin PGP out as a separate corporation and sell not just to the enterprise, but the average person. I'm sure with all the historic lineage of PGP combined with word of mouth, people would pay something like $19.95 to $29.95 for it without a second thought.
Yes, TrueCrypt can do similar, but having another commercially supported and updated encryption program that has its own independant signing system is very useful and flexible.
It wouldn't hurt to revamp Norton as well. Chasing virus/malware signatures is all but pointless. Instead, blocking by IP similar to Malwarebytes or perhaps even offering sandbox functionality for Web browsers would do far more than just having Norton be another "virus condom" utility.
They have products worth buying. Namely, the whole PGP desktop/mobile IP.
If Symantec sold the desktop version with more features and with a hardware crypto token, all for a reasonable price, virtually every geek would buy it, if only for a place to store the mandatory private key, even if it never gets used.
Backup Exec and NetBackup, similar. They need to take a page from Tolis's BRU and allow complete installation of their software for restores without needing serial numbers. That way, people don't have the catch 22 of needing info stored on a backup to unlock the backup program to restore... Making a version that can compete with Retrospect would be useful for SMBs as well. Heck, just make a smaller version of the NetBackup Appliance and sell that for $599.
Symantec has a lot of cool stuff (heck, they used to be the main compiler maker for Mac until the PowerPC days.) They just need to start bringing it out and consider going for volume. A couple thousand people paying $20 for PGP desktop for personal use/security will make more money than 1-2 people paying $250 for the same program.
Slashdot Mirror
Firewall and AV products will not catch 0-day exploits of the Web browser and add-ons. If they are pulled via SSL, even the best SPI firewall will be bested, unless one goes with a MITM system and forces all inside machines to trust the MITM appliance's key as a root one.
Browser exploits are the biggest vector of infection these days, and XP has little to no resistance innately against those, other than running as a non-admin user... and even then, malware can do a lot with a regular user's context.
Even without admin rights, malware can do a lot of harm with just user profile data.
XP is very lightweight (runs well in 512MB of RAM), so it makes for a great OS to run in a VM for Web browsing. Have the user that the Web browser is running in be a non-admin, use the above add-ons, and use a sandboxing program like sandboxie, and one can have decent protection. Every few weeks or so, roll back the snapshot so if something did get past the sandbox, it would be gone. Of course, bookmarks would have to be saved somewhere else, but that isn't an impossible task. For AV protection, something like Malwarebytes that blocks rogue IPs is decent, but usually AV software is useless against most attacks due to the 0 day nature.
What is annoying is the pulse and glide hypermiling thing... accelerating to 70, dropping to 55, repeating... supposedly is good for gas, but hoses traffic because of the speed changes.
The irony is -- it seems to be only Priuses. Camry hybrid drivers don't have that issue. Neither do the people driving the Lexus models that are hybrids. Neither do Ford hybrid drivers, nor the Insight/Civic drivers... it is just that one model of vehicle that seems to attract the people who tailgate the semis, pulse and glide, refuse to accelerate, etc.
Even more ironic... the Prius isn't that bad a vehicle. I've test-driven one and they go about the same as other small cars... not extremely fast, but not a Geo Metro either.
To boot, I can tack an inverter on the traction battery and have enough wattage available to jump start almost anything on the road with a charger. The inverter also comes in handy if there is a power blackout, since the Prius can be used as a fairly efficient generator that is decently quiet, and with the emissions on it, it puts out less harmful exhaust than a putt-putt generator of the same wattage.
btrfs has been "experimental" for quite a long time (2009?) To compare, Linux went from MINIX's filesystem to ext2 in two years, which lasted quite a while. It takes time to get a filesystem going, but five years is almost an eternity in the computer world, and realistically, Linux should have chucked the LVM2/ext4 combination long ago for ZFS or something ZFS-like.
The good thing is that with FB's devs hammering on btrfs, that will do nothing but improve things and get btrfs ready for prime time use in the enterprise.
You are not the only person who have reported data loss on btrfs. Normally I wouldn't worry about Linux filesystems (even ext4 became rock solid after a while.) However, I worry about what I hear from people who use btrfs.
One concern is that a filesystem can't check for bit rot by itself. True bit rot checking requires at least some working with the LVM layer to check CRCs, find a damaged sector and fix it. I've read that btrfs can catch some bitrot issues, (and please correct me if wrong), but it can't catch/correct anywhere near as much as ZFS or Storage Spaces + ReFS can. btrfs also uses a 32 bit CRC, rather than a 64 bit one.
I'm hoping that Facebook's coders can find the issues with btrfs and squash them. There are not many companies with the sheer server use of FB, and if they can get it working solidly, btrfs should be more than ready for prime time for everyone else.
I appreciate that link. That is very useful. It would be nice if it was part of EPEL directly. I thought the ZFS development was dead on this, but apparently there was a release last August.
IMHO, this is a very good thing. btrfs doesn't have as many capabilities that ZFS or Storage Spaces/ReFS possesses.
However, it is finally time that Linux has a filesystem that supports the latest/greatest enterprise features (deduplication and the ability to combat bit rot.)
Realistically, it would be nice to see the native (not FUSE based) code from OpenZFS be included as an alternative, but the CDDL/GPL conflicts likely will make this a no-go.
Why should they be on a network at all? My refrigerator does just fine with a basic thermostat, electrical fusing, a device to pour water into a mold, dump it in a bin when frozen, then stop dumping it when the bin fills up, a switch to turn on the light when the door opens and a fan so it runs without the need to be defrosted. The additional gewgaws don't help with core operation.
Same with a stove or a microwave. For safety's sake, it should only be able to be turned on by someone who is physically present.
Sometimes, there is just no real point in adding a device to the IoT, and the fewer devices that have networks, the fewer attack vectors an attacker will have to operate with.
This doesn't mean that isolated networks are bad... for example a vehicle needs the CANBus. However, if one doesn't need to have that functionality in a toaster, why built it in?
If we have to have a network or bus for statuses, why not a read-only bus, essentially like a serial port with the return line cut so the device can send status messages out, but not have them go back. The basic concept of a data diode. This way, one can tell if their fridge is over temperature, but a blackhat can't log on and turn the fridge off and spoil someone's steak stash.
Very true. In fact, this is something mentioned in the pramble of Phil Zimmerman's PGP, with that people should encrypt their writings just as one sticks papers in an envelope and doesn't send everything via postcards.
However, appearance matters, and TOR has a negative connotation. Having a website that appears on the up and up to discuss full disclosure, and have it have the appearances of being legit is a completely different issue from getting TOR out of the shadows.
The problem is that there is craploads of bandwidth available on the LAN... but here in the US, WAN connections are relatively slow and pricy.
A good example of this is the few terabytes of space I have on Google Drive. If I want to kick a terabyte of data across a cable link, there is a good chance that I'd be handed a $250 bill for the bandwidth used. If I tried moving a TB over LTE... that will be a five digit bill on every single cellular provider in the US. So, the cloud storage is nice... but storing it becomes expensive, as the $250 to kick a TB over could buy two hard disks that the data gets copied on and then stored separate places... and access to data via a USB port is free (for now...)
So, cloud technology sounds great... but having a grand warehouse is one thing... but if the roads are all one lane tollways that take 2-3 days to get out of a city to store stuff there, it is pointless.
The future of storage really can't be the cloud, other than using the cloud as a piece of media that has a high cost for access, high reliability, low security (you encrypt data before it goes out), and high accessibility.
TOR is one thing, but I'd rather have the EFF step in, so there isn't any appearance of the list being shady. It might be legal to hide in a back alley and make sales transactions in cash, but it is a lot better for first impressions to have a storefront and the appearance of being a mainstream service.
This FD list is probably one of the most critical items to general computer security we have next to a vetted cipher suite.
It isn't "IT", but there are degrees in IS, along the lines of business management. This is another path, likely a profitable one since it gets one closer to PM/PHB types of jobs... those are the jobs that will stay even after the corporate axemen come to visit with the pink slips.
I'd add a couple:
5: Locks and integrity. You have two threads updating one variable. Without some sort of transaction/lock/mutex/semaphore system, one can get very unpredictable results. This is a subset of #3 above, but variable manipulation can be a basic thing overlooked.
6: Choosing the proper variable type in a strongly typed language. Yes, one can always use long doubles for every floating point calculation, similar with long longs... but when a counter never gets past 16, it wastes space. Yes, the pressure to conserve RAM and disk space isn't as much as it used to be, but embedded programming is only going to grow, so resource use will be an issue for a number of projects.
I've never understood the point of a degree from a non-accredited institution. If the university isn't accredited, I'd probably be better off licensing an official Miskatonic University degree plaque from HP Lovecraft's estate.
The parent nailed it. I'd see about the reimbursement item.
Also, sometimes OS certificates can get one in the door as well. A CCIE can get one in the door, similar with a MCSE. For the tech people, it doesn't mean as much, but the HR department are the people that round-file resumes or pass resumes on, so those are the people that one has to get past first, then one will need to show the IT people what one can really do.
I'm pretty sure that the rationale for slack physical security (other than the cash box) is that the store clerk or the camera pointed at it will discourage people from drilling holes in the CPU.
As per a previous /. article, maybe ATM makers moving to a new OS and PC might help matters. Linux is a good candidate. No AutoRun/AutoPlay capability present for starters (although Windows can have it easily turned off as well.)
Ideally, what might be best is to move to a motherboard that is designed from the ground up to make it tamper resistant. Yes, the initial expense might be a bit high, but once made, the only thing needed to upgrade future ATMs would be new graphics for the dancing animals in the background and signed OS updates for future security issues. ARM itself has TrustZone and TPM capabilities... and an ATM is where those capabilities would be perfect for the job without expensive additional hardware or ASICs.
It isn't the absolute best fix, but MS's EMET (Enhanced Mitigation Experience Toolkit), does stop any attacks via this route. I'm sure EMET probably breaks some apps (easily fixed by adding exceptions, and probably why this tool isn't included in the base OS), but it is worth installing and using.
This reminds me of the desktop publishing "industry" back in the late 1980s. Slap a Mac SE/30, a copy of PageMaker and a laser printer in front of someone, and that ended up a desktop publishing service.
3D printing is around the same type of thing. We will see features get added to printers (more filaments, higher "resolution", easier to use software, ability to have stuff automatically fabbed by sintered Iconel from a nearby shop, etc.), the price drop to a few hundred dollars, then the printers will be "good enough", and people will move to the next thing. Once operating systems have native 3D printing support (i.e. allow a printer to be plugged in and work without needing to install any third party stuff) , the technology will be pretty mature.
Maybe with the conventional model of "it builds! Ship it!" and bottom dollar offshored dev houses, this is understandable, but a well written program, this shouldn't be the case.
Ideally, a program should be written, alpha tested, beta tested, then the version 1.0.0 release put out, which would really be 1.14.102 by today's standards.
A good example of this is Netware 3.1.1. It is pointless to bother with by today's standards, but it had an extremely long life without needing constant updates for security issues.
TFA tells us nothing. Even the followup about 2.6.18 being the worst culprit and the note that upgrading the kernel will not help makes it even more pointless.
My fix: yum upgrade, and if the update does grab a new kernel, reboot. There was a kernel bug (long since patched) a few years ago that allowed attacks past even SELinux... but if one is running a recent distro, this shouldn't be an issue.
Of course, one should doublecheck what is likely the real culprit... applications like apache and its modules, and perhaps check for compromised credentials [1].
[1]: On Internet-facing machines, if possible, I configure ssh to only allow public/private keys and no passwords. That way, if the remote machine gets completely pwned, the attacker will have my SSH public key, which is a lot less of an issue than having a hashed password list.
I've seen XP on some ATMs, not XPe, although it does get annoying when an ATM is down due to an XP activation screen.
The ATM industry needs to stop being pennywise and pound foolish.
Instead, they need to design their platform once, do it right, then as time goes on, add a UI refresh every so often so the cute cartoon characters get a facelift every year or two.
Were it up to me with ATM design, I'd probably charge off a quarter profit to do the architecture right, then once done, pretty much coast from there.
First, I'd give a lot of consideration to QNX. ATMs are not really needing a RTOS, but QNX has an excellent reputation for security (with decent government certifications to back that.) From there, add a TPM chip, userland, and the application. Done right, someone plugging in an unauthorized USB flash drive won't be able to do as much, compared to XP with AutoPlay/AutoRun turned on.
Linux is also a good choice. One could go with a full userland or an Android style userland, both with SELinux to minimize damage. Linux may not have the C2 cert that QNX does, but it will hold its own in security, if done right.
I should have stated differently.
What I meant to state is that is a very good thing that PGP supports more than just a file on a USB flash drive. Having something like a smart card + reader, eToken or a similar USB based device is a lot better than a file on media, just because an attacker can't just copy the contents off, which is a possibility if the USB flash drive was left plugged into the machine.
One of my laptops still uses an Aladdin eToken (before they were bought out by Safenet) as a means of booting. That way, I know that if I have the token on my physical keyring, the laptop isn't going to be decrypted anytime soon... and if someone does get the token and types the PIN wrong more than three times, the token will physically lock... blocking brute force attempts completely.
PS: Thanks for the release notes on your other note. I hit the Symantec site, and they were behind on what was supported. I definitely stand corrected there.
Funding a new moon shot and colony would make a new economic boom. The last Space Age gave us a lot of useful items. Another moon race, this time with tech from this decade instead of 1960s technology may bring about a lot of useful side projects.
At the minimum, it would bring a renaissance to both embedded programming and computer development in general (mainly because there is no room for error, and shipping an "early alpha" as release code just won't cut it.) It might even result in software development models that are not "at this date, build the tree and ship regardless of the bug report states" which seems to be the usual case.
Maybe it might get funding for a space elevator which would make getting on and off the Earth a lot easier, coupled with a similar one on the moon.
Even if the money made nothing, it sure at least paid for some research which might be useful later on, similar to Corning's Gorilla Glass.
TrueCrypt is decent, but it can't hurt to have a utility that is updated and maintained with similar functionality. Truecrypt is going over two years without an update. It is a very good program, but PGP has a lot of functionality (public/private key exchange and upkeep, web of trust, etc.) that TC doesn't have.
Of course, one can use GNUpg and TrueCrypt. The command line works well, but GUI-wise, Symantec Encryption Desktop Professional (i.e. PGP Desktop) is just a lot easier to get around in.
One side note -- PGP Desktop isn't officially supported on Windows 8 and 8.1... but it does work.
I agree with you. I don't know what to call it, other than a reverse Midas touch.
The ironic thing is that Symantec's PGP was the only program available for OS X that did FDE encryption before FileVault 2 came out. It was fairly messy how it loaded in, but it did work and did protect all data on the HDD.
PGPDisk also has the ability to grow/shrink an encrypted volume, which is a nice thing to have. TrueCrypt sort of has this capability, but uses sparse files (i.e. if the file gets copied via Samba, it will take up the full space given, even though most of the encrypted volume is zeroes.)
Going back earlier, Symantec also had a very well written edition of PGP for PalmOS and Windows Mobile, with encrypted volumes.
Symantec has a very kick-ass opportunity right now. They can capitalize on the general concern of both businesses and people and sell not just PGP Desktop, but a complete infrastructure going past BitLocker where a cryptographic token would be required for the OS to load. Not just a file on a USB flash drive, but a token where the key is well protected even from physical attack.
It blows my mind that they have the encryption market cornered with a solution that starts on boot, handles Samba shares, can handle files as disks similar to TrueCrypt, can function as a ZIP archiving utility, and can encrypt individual files with ease. However, they either let things sit, or price themselves out of the market.
Another example is the PGP server. This functionality is very useful for a company. It allows key recovery and ADKs, without going down the black hole of key escrow.
Symantec just has so much potential with the companies they own. Things like Ghost and Veritas's LVM replacement come to mind.
Even with compilers, they also have had things like a very solid C++ compiler for DOS and Windows 3.1 which shipped with more than 2 and a half feet of printed manuals, with every single function all described in good detail. I've not seen something that well documented outside of some IBM Redbooks.
I completely agree with the parent -- Symantec needs to "unfuck" some of their offerings and go for the target markets at a non-enterprise price. At the minimum, spin PGP out as a separate corporation and sell not just to the enterprise, but the average person. I'm sure with all the historic lineage of PGP combined with word of mouth, people would pay something like $19.95 to $29.95 for it without a second thought.
Yes, TrueCrypt can do similar, but having another commercially supported and updated encryption program that has its own independant signing system is very useful and flexible.
It wouldn't hurt to revamp Norton as well. Chasing virus/malware signatures is all but pointless. Instead, blocking by IP similar to Malwarebytes or perhaps even offering sandbox functionality for Web browsers would do far more than just having Norton be another "virus condom" utility.
They have products worth buying. Namely, the whole PGP desktop/mobile IP.
If Symantec sold the desktop version with more features and with a hardware crypto token, all for a reasonable price, virtually every geek would buy it, if only for a place to store the mandatory private key, even if it never gets used.
Backup Exec and NetBackup, similar. They need to take a page from Tolis's BRU and allow complete installation of their software for restores without needing serial numbers. That way, people don't have the catch 22 of needing info stored on a backup to unlock the backup program to restore... Making a version that can compete with Retrospect would be useful for SMBs as well. Heck, just make a smaller version of the NetBackup Appliance and sell that for $599.
Symantec has a lot of cool stuff (heck, they used to be the main compiler maker for Mac until the PowerPC days.) They just need to start bringing it out and consider going for volume. A couple thousand people paying $20 for PGP desktop for personal use/security will make more money than 1-2 people paying $250 for the same program.