Maybe that might be the best answer -- if one can spend the energy it takes to pull apart hydrogen from water, one can pull CO2 from the air and make propane. Propane has 73% of the energy of gasoline... but for most tasks, that is good enough. Plus, Truma has their VeGA [1] fuel cells which can use propane, so it can be actively burned in a vehicle's engine, or used in a fuel cell to keep the batteries topped off.
[1]: Would be nice if Truma sold more than their propane gauge in the US. I'm not sure if they are afraid of lawsuits, or just find Americans not good enough for their products, but they are at least two generations ahead of the RV appliance makers on this side of the pond with what they offer.
SDN as a concept is sort of evolution. Things like OpenFlow just make sense, and was only a matter of time before we would see L2 and L3 packet manipulation merged into one device just like we saw hubs and switches merge. Cisco's Nexus series is an example of this.
The big hurdle is combining network fabric with storage fabric. FCoE does this, but the big leap will be FC, so a switch can function either as a FC switch, or use FC just for media and be an Ethernet device. This way, one can deploy network devices, and it doesn't really matter if part of the device is zoned for logical devices and part of it is for IP addresses.
Of course, there is the issue of redundancy... you don't want a DDoS on core fabric taking out your SAN. However, as time goes on, we will see two devices that would combine with LAGGs or MPIO (depending on the storage technology) to provide redundancy both for storage and network. You will see smarter devices that can separate getting hammered due to network traffic without that interfering with I/O for disks. It might be that even drive controller functionality winds up part of the core fabric, with features like caching, deduplication, encryption, snapshots, WORM functionality (where once files are written, they stay in place until they expire), and other features normally handled by the SAN.
It likely will come back. As of now, a company has to use the Internet for all transactions, which means every ingress and egress avenue is vulnerable. It only is a matter of time before carriers will move to dedicated lines and creating their own WANs which are not connected to the Internet for specific tasks (B2B communication, payment processing, etc.)
As stated above, non-interconnected networks are coming, be it China, Russia, Brazil, or others. North Korea has their own "public" WAN, not connected to anyone else. It is about doing this job right that is going to change things fundamentally. Select the wrong trunk on the ESXi cluster, and it can cause a catastrophe.
Ironically, this might be the thing which might help IPv4 address space.
In IT, there isn't really much that is new. Cloud systems evolved from offsite data centers. However, there are a few things which are important:
1: IoT. Securing these is like trying to use bandaids after someone stood in front of a 3000 rpm gunship weapon. However, if it does take off, one will have to factor in every doodad that might require Wi-Fi, or might have a 3G card so it can phone home and the black hats can hack into it.
2: Separation of the Internet into sub-networks. It is only a matter of time before this happens. With the state-sponsored armies of blackhats, you can't win a war of defense. The only real way to keep your stuff secure (as a business) is to separate out functions with physically different networks (SIPRNet, NIPRnet are examples), so the Internet is not the only means of communication. This involves real leased lines, additional fiber laid, and additional network fabric, perhaps virtual circuits, so only machines that are configured to communicate with each other can.
3: Bit rot, CAS systems, and ensuring files archived are still readable in a media-agnostic way. That way, if finance needs a document from 2005, it doesn't matter if it is on tape or disk, they can obtain it with minimal operator intervention.
L1 encryption could be quite brain-dead simple. One could use preshared keys and call it done (with an algorithm to use session keys derived from D-H sessions encrypted by the "master" PSK, and change every so often.)
I've wondered why communications lasers are not more often used, especially IR ones.
Regardless of the method, education is needed. There are few worst things than being clueless.
Cluelessness of the law can get one arrested. There are people who don't realize that one stupid thing like saying "no" when asked to leave can mean six months to a year in the county can for trespass, or that driving a car when a passenger is carrying dope can mean the car becomes property of the county and the driver becomes property of the local correction system for 2-10. Cluelessness is doing anything other than hanging up with some phishing bill collector demands you pay some debt (which you never incurred) from a company you never heard of. Say anything, they will sue and said the debt was acknowledged. Cluelessness is someone shrugging and being apologetic because some shitbag rear-ended them... and said shitbag then uses that apology in court as admission of guilt.
In the wild, cluelessness is someone going on a camping trip, then wondering what to do when hiking and gets surrounded by feral dogs looking for an easy meal.
Look at the US. The education system is what makes a country great or hamstrings it.
FISMA regs are pretty sane as this stuff goes (especially for government work). I'm pretty sure had they been followed, this most likely would not have happened.
FISMA, NIST guidelines, and PIV cards cover a lot of issues. The only real one that remains is creating a government network like NIPRNet or SIPRNet, but for all entities, and have that completely separate from the Internet, using dedicated lines, virtual circuits, and end to end encryption. That way, if two machines are not expressly allowed to communicate with each other, they can't.
I might be wrong, but the last time I checked, the forms feature in Acrobat would allow the stuff in the PDF to be submitted via SSL. It didn't submit the PDF as a file... just the stuff in the forms.
If possible, I'd definitely host E-mail myself if I were running something bigger than a SOHO where hosted Exchange is my best bet.
First, I keep physical control of my Exchange mailboxes. Mail might be intercepted, but internal users that send and receive at the same domain are not going to be at the mercy of some nosy (or hacked) provider.
Second, I know how redundant and secure my E-mail system is. Ideally, I have an edge instance of Exchange for incoming stuff, which gets scanned and then passed to the an instance that runs as a hub. Then, I have another edge Exchange instance for outgoing E-mail, and yet another edge instance for ActiveSync and OWA. This isn't 100%, but it will at least give an intruder a fun time in getting to the juicy stuff, and the actual mailboxe servers are nestled well away from the outside world via firewalling.
Third, it doesn't take much to use a "legit" relay provider. I personally use Rackspace's Mailgun (although similar offerings are just as good or better.)
Of course, the downside is the infrastructure. Four copies of Exchange, Active Directory, a good firewall that supports DMZs, and the utilities it takes to back up mailboxes. However, this makes eDiscovery and other regulation compliance quite easy to deal with.
This is a tough choice. A cloud provider is better than services poorly run, but the best of all is a well run enterprise with company servers so the data has good physical control.
I have had the same problem, and this is regardless of providers. Lists of dynamic IP ranges (be it cable, DSL, or other providers) wind up on DUL (dial-up lists), and those are often part of blackhole lists. Since most botnet clients are from DUL-based IPs, E-mail providers just block those as a matter of course.
What I did was have my private E-mail server use the SMTP server of my ISP for relaying. Problem fixed. However, if you don't have a SMTP server available that allows for different domains, there are commercial services which can relay your outgoing E-mail, which provides "legitimacy" to your messages.
The exception were direct Exchange connectors. Those were established from Exchange server to Exchange server, so mail would go directly via a secure pipe, and not be relayed.
Samsung did a decent job so far. It took a five digit bounty to even achieve root (much less a usable bootloader unlock) on the 5S using the towelroot exploit.
If the hack results in a jailbreak, I'm sure there will be a patch or a workaround on Cydia. I remember this happening with a SSL issue a few years ago.
The ironic thing is that with either CyanogenMod or XPrivacy installed, Android will prompt on first use of a permission (contact list, phone, camera), and even allow it just for a certain period of time.
I think both ecosystems feed from each other. Android's NFC is useful since HID card readers can use it, so it can be used either instead of a badge, or as a backup in case someone forgets their ID.
Android devices have walled gardens, and it is up to the customer to choose how high the walls are, and if they get a key to the gate.
On one hand, you have the flagship Samsung phones which for even just root, it took a bounty and a heavyweight iOS jailbreaker to just punch a hole past Knox... and that's not even a bootloader unlock. On the other hand, you have the Nexus line of devices which allow full access with just a "fastboot oem unlock" command, and HTC devices which unlock with a key obtained from their website.
One has to do a little bit of research buying a device. GPE (Google Play Experience) devices tend to be unlockable, and run with minimal crapware.
I'm also worried about data coming in. If GM and OnStar can shut down cars, then what prevents some bad guy from shutting all Chevies down on the highway during a hurricane evacuation just to cause problems.
This already happened in Austin when a car dealer that used a "pay to play" system on their vehicles (where the buyer had to enter a code after every payment to allow the vehicle to start)... a disgruntled employee logged in via another person's account and shut down every single car, be it paid for or not. If a guy with no hacking skillz other than knowing another employee's password can do that, it wouldn't be far-fetched for a blackhat to seize control of GM's OnStar system and use it for mischief. Criminals would stand in line for this access (disable cars on a remote stretch of highway for ease of looting.)
Even with office suites, one could export whatever documents to some "standard" and switch to a new product, although some formatting would be lost/destroyed. For example, a document open in Pages, saved, then opened in LibreOffice would take some editing to have it formatted correctly.
Databases are permanent. Realistically, unless there is absolutely no other way to do it (for example, if the RDBMS program is written for a 16 bit OS), no company or organization will change database backends. It just takes way too much time to rebuild applications, make sure the data is exported/imported correctly, all tables are in place, and doing all this in production so it impacts day to day business as little as possible.
Amazon's product may be good, but I would be leery of trusting a cloud-only solution. What happens if there is a new regulation that forces certain data to be in house, or what happens if there is a data breach? At least with Oracle or SQL server, I have some options with both local machines as well as cloud based RDBMS backends. Of course, what happens if Amazon decides to stop being a provider? With an RDBMS, it just means running obsolete software until one can get around to moving. With a cloud provider going under, one has to have a solution before they turn off the lights in place, or else all data is gone.
Finally... what about backups? Someone takes down some Amazon cloud servers, and the company using them is royally hosed. There are no tapes local, if there are backups on AWS or Glacier, they might be on the same datacenter or even the same SAN as the failed cloud servers. A conventional solution at least has the ability to have some tangible medium where the data is stored so it can be recovered.
Oracle is expensive, but they have a niche that nobody else can take them from... where almost every application will work with Oracle as a DB backend. They are similar to AutoCAD in the safe bet regard [1]. Not because they are light years ahead of the competition... but they have ended up in a place where it is easier to pay for upgrades rather than switch to another RDBMS.
Their only real competition in their market is DB/2 or maybe Sybase (because Sybase works as a backend to SAP.) For something used for a backend Web database, there are other solutions that work just as well, if possibly not better.
[1]: IBM used to have this, but I'd say the crown of "you can't be fired by buying this company's stuff" really belongs to Microsoft.
Oracle is a mixed bag. One one hand, it is really nice to be able to get up and running without having to make sure you have every single license key somewhere. On the other hand, there are the audits.
1: The ability to click-to-play for add-ons. Chrome has this, and it does a great job at dealing with the loud ads that autoplay. This also adds security so that malware from a compromised or dodgy ad server doesn't get free reign to execute.
2: A VM-like structure similar to Chrome, so that a compromised window or tab is limited to just that context and can't take down the whole browser, or even worse, the user context it runs in. Chrome's VM is a big security plus. Not 100% security, but quite useful.
We also need guidelines and standards for security. This isn't something that I can quantify, toss a high amount at a CISSP and get some unit of security. PCI-DSS3 is an example of decent guidelines. Another are the NIST SCAP items.
What would be an ideal would be some standard body making up security standards, not just guidelines (segment and firewall networks), but actual steps to secure operating systems and appliances with varying levels of security [1]. This wouldn't just be something that an organization could do once, but something that would have to be made at least quarterly with emergency workarounds coming out 24/7, such as replacing bash with Busybox or compiling a binary from the fixed source.
There are also issues and publications that wouldn't be as obvious... for example, guidelines on securing HVAC systems or basic power. Recommendations for organization charts to protect against social engineering, so someone name-dropping a VP doesn't get a file full of root passwords just by asking. Even physical guidelines like protecting against tailgaters at building entrances [2], or what type of lock cylinders to use (as some brands of cylinders had reports about security gaps which got remedied in later models.) Security is a moving target, and it would take a lot of cash to keep an organization funded which keeps on top of this... but it would do far more to help things than adding new regulations [3].
Right now, the major vendors have security tools usually baked into the OS which are pretty good. The trick is to have one coherent clearinghouse that can help people use what tools are available and still remain vendor neutral.
[1]: For example, on AIX, if I wanted one level of security, I'd sign all binaries on the system and configure trustchk to disallow anything else to be run. If I wanted higher than that, I'd disable root (so UID 0 processes had no "special-ness" about them) and set trustchk with LOCK_KERN_POLICIES on so there is no process on the system that can allow untrusted binaries, libraries, or even shell scripts to run.
[2]: Badge policies have to apply equally in a company, and if all someone needs to do is wear a suit or a uniform to get in, then physical security has failed. 99% of the time, it may just be nothing... but there is always that 1% where calling security on someone might have just stopped an attack.
[3]: Sarbanes-Oxley comes to mind. I've yet to read about it being enforced... except when it was used against an individual who had an improperly fished grouper.
Along the lines to this question, how can Tor's PR be helped? As of now, part of an IT person's job is to block Tor's exit nodes, on the application, kernel, and router level, because those nodes to be a source of many attacks. So, because of the bad reputation, it gets entirely locked out of many websites. This can be fixed by running a VPN over Tor so the exit comes from the VPN's servers, but there goes the anonymity for the most part.
One can accuse Kaspersky of being a mouthpiece for Russian propaganda, but in this case, this is a genuine threat.
One Wi-Fi network at a local eatery always tries to replace one of my E-mail provider's SSL keys with one from 192.168.168.168. Most people would just click "continue" or "accept"... or even have their Exchange client configured to accept any SSL key. This makes it plausible that a black bag group could step in to do stuff like this.
Of course, since people are so inundated with updates for Flash, Web browsers, and Java, clicking on yet another update becomes muscle memory, so a Trojan horse is definitely an avenue of attack. Couple this with a transparent proxy that is configured to MITM a key or two, and it isn't surprising how a group like this can score big.
The solution? There is no single magic bullet, but there are things that can help. The most important is user training, but next to that:
1: VPNs. The only key that can be attacked by a compromised local Wi-Fi AP would be the VPN's, and a good profile would just disallow access if this is the case.
2: Home Depot announced that it is moving to Macs. No, OS X is not 100% secure (as the exploit posted last week shows), but the bad guys have their tools honed for Windows. For the most part, Macs are not on the bad guys' menu. Running an alternative platform might be an idea.
3: Going with Citrix, and have the laptop be essentially a dumb terminal. Bad guys can still compromise it, especially with a RAT and taking over the session, but going with this raises the bar, especially if 2FA is used. Again, this isn't 100%, but it does help.
4: Tools like enterprise DeepFreeze. Store data on an encrypted, thawed partition, have the OS and applications be on the "frozen" drive. This makes cleanup a matter of just rebooting, assuming the documents are not compromised.
5: Tools like AppLocker or other programs to ensure unauthorized stuff isn't put on. For salespeople, this isn't going to happen, as they are the company breadwinners.
6: VMs. If the user knows what they are doing, VMs/sandboxes and a VDI can be useful, however, with non-technical people, the KISS principle is important, as they may not want to waste the time firing up a VM in order to browse the web between their presentations.
As for antivirus, this attack is a Dancing Pigs/Dancing Bunnies attack, and no AV software will protect against it, unless the user is denied admin rights on their laptop.
What we might have happen is that we end up with a mix, where a core is weighted towards a task... but compared to running a job at say, 80% as effectively as a core that is built for the job, versus not running the task at all, the scheduler [1] would drop tasks on non-optimal cores if it would help performance. If it is something definitely not optimal (FPU instructions on an integer-only core), the weighting would account for that and might not even place a task on there come the next quantum.
The 10x10 is interesting. However, on an average desktop, we could see quite a number of cores that (in addition to the normal CPU/GPU/FPU lineup) would be useful with special purposes:
1: A core running as a hypervisor, using something similar to ARM's TrustZone to ensure complete separation of tasks. This core (or perhaps two cores... one low power that uses very little wattage when the box is idle, and one that is faster when there is a lot of VM context shifting.)
2: A core that deals with I/O, with a lot of cache. Until the cache fills up, this would turn a lot of random I/O into sequential I/O, which is a lot easier for a hard disk or RAID array to deal with. This could even use fast SSD as another level, although a RAM cache handled by the OS might be just as good. This core can also offload software RAID commands (such as what ZFS, Storage Spaces, LVMs, and btrfs do), so performance would be improved on that end without having a dedicated RAID controller. Adding a battery backed up write cache (especially if the OS knows about it and can work with that) would only help things.
3: Cores to handle encryption are a given. AES is so often used that having space on a die to handle the S boxes and array shifting goes without saying.
4: High power and low power cores. Some phones have two sets of cores, one for when the device is not doing much, and one for when it is active use. For servers, this would come into handy because a DB server that doesn't get touched after 5:00 could just sit on a low-draw core, and when the DB starts getting hit by transactions, moved back to a faster one. This in itself would save a lot of wattage at the expense of die space.
5: Similar to #1, but the core would have its own separate I/O, memory, and other space. This could be used for the hypervisor, or tasks that need to be isolated from everything in the machine. A Harvard architecture could be used to further prevent attacks like smashing the stack or heap.
6: Ye Olde FPGAs. One never knows when these may come in handy, and having an application with oddball CPU requirements be able to use one may help performance immensely.
7: A dedicated CPU just for scanning RAM space. This could be used for a host IDS/IPS, or performance/health monitoring.
8: A dedicated NIC-like core whose purpose is optimized for packetization/depacketization. Pretty much a FCoE CNA, except with the added ability to work as a firewall outside of the host machine's OS. Around 10 years ago, some computers had "smart NICs", and could have firewalling code on there that would guard the machine (say, keep port 25 from going anywhere) even if the box's main OS was compromised. Give the machine SFP slots, and depending on the SFP inserted, the machine could use that slot as a FC HBA, a FCoE CNA, an iSCSI adapter, or "just" used for plain Ethernet traffic. That way, one doesn't have to even replace cards to move to a new SAN technology... just the media adapter gets replaced.
I'm sure there are many others, but once making chips smaller has diminishing returns, then going with sheer number of cores stops being working, going with special purpose cores, or ones weighted towards a task is the next step.
Some devices have had a NFC based pay system. SoftCard comes to mind. It uses NFC, and an application on the SIM card, which is harder to attack than just another app on the phone.
Of course, there is the fact that SoftCard requires one to use a specific credit card... but the technology has been in place in a secure manner from the SIM card on up.
I'm just hoping Android's implemention of this is decently secure. CurrenC is waiting in the wings, and if Apple Pay and Android implementations flop, this will be waiting to become the primary payment provider... and it completely bypasses the credit card fraud protections, so if money is stolen... the consumer is stuck with the losses.
The fuel cells I've seen are not going to replace a generator anytime soon. They put out a couple hundred watts out at most, which might be enough to keep a battery bank charged over a period of time, but don't put out enough oomph to directly power electric motors.
As for disasters, I've seen people use an inverter with Prius and other hybrid models which is functionally equivalent to a generator, although the inverter had to be a PSW model.
Of course, generators are a good option, but usually I see people buy a generator, use it, stick it in the garage, and in 1-2 years, pull it out, and find that the carb is completely gummed up. Generators either need to be properly fogged or at least run occasionally, and if stored with fuel, need a fuel preservative (Sta-Bil, Star-Tron, Seafoam, or others) added to minimize varnish, especially with ethanol blends, as ethanol sucks water in from the air.
Slashdot Mirror
Maybe that might be the best answer -- if one can spend the energy it takes to pull apart hydrogen from water, one can pull CO2 from the air and make propane. Propane has 73% of the energy of gasoline... but for most tasks, that is good enough. Plus, Truma has their VeGA [1] fuel cells which can use propane, so it can be actively burned in a vehicle's engine, or used in a fuel cell to keep the batteries topped off.
[1]: Would be nice if Truma sold more than their propane gauge in the US. I'm not sure if they are afraid of lawsuits, or just find Americans not good enough for their products, but they are at least two generations ahead of the RV appliance makers on this side of the pond with what they offer.
SDN as a concept is sort of evolution. Things like OpenFlow just make sense, and was only a matter of time before we would see L2 and L3 packet manipulation merged into one device just like we saw hubs and switches merge. Cisco's Nexus series is an example of this.
The big hurdle is combining network fabric with storage fabric. FCoE does this, but the big leap will be FC, so a switch can function either as a FC switch, or use FC just for media and be an Ethernet device. This way, one can deploy network devices, and it doesn't really matter if part of the device is zoned for logical devices and part of it is for IP addresses.
Of course, there is the issue of redundancy... you don't want a DDoS on core fabric taking out your SAN. However, as time goes on, we will see two devices that would combine with LAGGs or MPIO (depending on the storage technology) to provide redundancy both for storage and network. You will see smarter devices that can separate getting hammered due to network traffic without that interfering with I/O for disks. It might be that even drive controller functionality winds up part of the core fabric, with features like caching, deduplication, encryption, snapshots, WORM functionality (where once files are written, they stay in place until they expire), and other features normally handled by the SAN.
It likely will come back. As of now, a company has to use the Internet for all transactions, which means every ingress and egress avenue is vulnerable. It only is a matter of time before carriers will move to dedicated lines and creating their own WANs which are not connected to the Internet for specific tasks (B2B communication, payment processing, etc.)
As stated above, non-interconnected networks are coming, be it China, Russia, Brazil, or others. North Korea has their own "public" WAN, not connected to anyone else. It is about doing this job right that is going to change things fundamentally. Select the wrong trunk on the ESXi cluster, and it can cause a catastrophe.
Ironically, this might be the thing which might help IPv4 address space.
In IT, there isn't really much that is new. Cloud systems evolved from offsite data centers. However, there are a few things which are important:
1: IoT. Securing these is like trying to use bandaids after someone stood in front of a 3000 rpm gunship weapon. However, if it does take off, one will have to factor in every doodad that might require Wi-Fi, or might have a 3G card so it can phone home and the black hats can hack into it.
2: Separation of the Internet into sub-networks. It is only a matter of time before this happens. With the state-sponsored armies of blackhats, you can't win a war of defense. The only real way to keep your stuff secure (as a business) is to separate out functions with physically different networks (SIPRNet, NIPRnet are examples), so the Internet is not the only means of communication. This involves real leased lines, additional fiber laid, and additional network fabric, perhaps virtual circuits, so only machines that are configured to communicate with each other can.
3: Bit rot, CAS systems, and ensuring files archived are still readable in a media-agnostic way. That way, if finance needs a document from 2005, it doesn't matter if it is on tape or disk, they can obtain it with minimal operator intervention.
L1 encryption could be quite brain-dead simple. One could use preshared keys and call it done (with an algorithm to use session keys derived from D-H sessions encrypted by the "master" PSK, and change every so often.)
I've wondered why communications lasers are not more often used, especially IR ones.
Regardless of the method, education is needed. There are few worst things than being clueless.
Cluelessness of the law can get one arrested. There are people who don't realize that one stupid thing like saying "no" when asked to leave can mean six months to a year in the county can for trespass, or that driving a car when a passenger is carrying dope can mean the car becomes property of the county and the driver becomes property of the local correction system for 2-10. Cluelessness is doing anything other than hanging up with some phishing bill collector demands you pay some debt (which you never incurred) from a company you never heard of. Say anything, they will sue and said the debt was acknowledged. Cluelessness is someone shrugging and being apologetic because some shitbag rear-ended them... and said shitbag then uses that apology in court as admission of guilt.
In the wild, cluelessness is someone going on a camping trip, then wondering what to do when hiking and gets surrounded by feral dogs looking for an easy meal.
Look at the US. The education system is what makes a country great or hamstrings it.
FISMA regs are pretty sane as this stuff goes (especially for government work). I'm pretty sure had they been followed, this most likely would not have happened.
FISMA, NIST guidelines, and PIV cards cover a lot of issues. The only real one that remains is creating a government network like NIPRNet or SIPRNet, but for all entities, and have that completely separate from the Internet, using dedicated lines, virtual circuits, and end to end encryption. That way, if two machines are not expressly allowed to communicate with each other, they can't.
I might be wrong, but the last time I checked, the forms feature in Acrobat would allow the stuff in the PDF to be submitted via SSL. It didn't submit the PDF as a file... just the stuff in the forms.
If possible, I'd definitely host E-mail myself if I were running something bigger than a SOHO where hosted Exchange is my best bet.
First, I keep physical control of my Exchange mailboxes. Mail might be intercepted, but internal users that send and receive at the same domain are not going to be at the mercy of some nosy (or hacked) provider.
Second, I know how redundant and secure my E-mail system is. Ideally, I have an edge instance of Exchange for incoming stuff, which gets scanned and then passed to the an instance that runs as a hub. Then, I have another edge Exchange instance for outgoing E-mail, and yet another edge instance for ActiveSync and OWA. This isn't 100%, but it will at least give an intruder a fun time in getting to the juicy stuff, and the actual mailboxe servers are nestled well away from the outside world via firewalling.
Third, it doesn't take much to use a "legit" relay provider. I personally use Rackspace's Mailgun (although similar offerings are just as good or better.)
Of course, the downside is the infrastructure. Four copies of Exchange, Active Directory, a good firewall that supports DMZs, and the utilities it takes to back up mailboxes. However, this makes eDiscovery and other regulation compliance quite easy to deal with.
This is a tough choice. A cloud provider is better than services poorly run, but the best of all is a well run enterprise with company servers so the data has good physical control.
I have had the same problem, and this is regardless of providers. Lists of dynamic IP ranges (be it cable, DSL, or other providers) wind up on DUL (dial-up lists), and those are often part of blackhole lists. Since most botnet clients are from DUL-based IPs, E-mail providers just block those as a matter of course.
What I did was have my private E-mail server use the SMTP server of my ISP for relaying. Problem fixed. However, if you don't have a SMTP server available that allows for different domains, there are commercial services which can relay your outgoing E-mail, which provides "legitimacy" to your messages.
The exception were direct Exchange connectors. Those were established from Exchange server to Exchange server, so mail would go directly via a secure pipe, and not be relayed.
Samsung did a decent job so far. It took a five digit bounty to even achieve root (much less a usable bootloader unlock) on the 5S using the towelroot exploit.
If the hack results in a jailbreak, I'm sure there will be a patch or a workaround on Cydia. I remember this happening with a SSL issue a few years ago.
The ironic thing is that with either CyanogenMod or XPrivacy installed, Android will prompt on first use of a permission (contact list, phone, camera), and even allow it just for a certain period of time.
I think both ecosystems feed from each other. Android's NFC is useful since HID card readers can use it, so it can be used either instead of a badge, or as a backup in case someone forgets their ID.
Android devices have walled gardens, and it is up to the customer to choose how high the walls are, and if they get a key to the gate.
On one hand, you have the flagship Samsung phones which for even just root, it took a bounty and a heavyweight iOS jailbreaker to just punch a hole past Knox... and that's not even a bootloader unlock. On the other hand, you have the Nexus line of devices which allow full access with just a "fastboot oem unlock" command, and HTC devices which unlock with a key obtained from their website.
One has to do a little bit of research buying a device. GPE (Google Play Experience) devices tend to be unlockable, and run with minimal crapware.
I'm also worried about data coming in. If GM and OnStar can shut down cars, then what prevents some bad guy from shutting all Chevies down on the highway during a hurricane evacuation just to cause problems.
This already happened in Austin when a car dealer that used a "pay to play" system on their vehicles (where the buyer had to enter a code after every payment to allow the vehicle to start)... a disgruntled employee logged in via another person's account and shut down every single car, be it paid for or not. If a guy with no hacking skillz other than knowing another employee's password can do that, it wouldn't be far-fetched for a blackhat to seize control of GM's OnStar system and use it for mischief. Criminals would stand in line for this access (disable cars on a remote stretch of highway for ease of looting.)
Even with office suites, one could export whatever documents to some "standard" and switch to a new product, although some formatting would be lost/destroyed. For example, a document open in Pages, saved, then opened in LibreOffice would take some editing to have it formatted correctly.
Databases are permanent. Realistically, unless there is absolutely no other way to do it (for example, if the RDBMS program is written for a 16 bit OS), no company or organization will change database backends. It just takes way too much time to rebuild applications, make sure the data is exported/imported correctly, all tables are in place, and doing all this in production so it impacts day to day business as little as possible.
Amazon's product may be good, but I would be leery of trusting a cloud-only solution. What happens if there is a new regulation that forces certain data to be in house, or what happens if there is a data breach? At least with Oracle or SQL server, I have some options with both local machines as well as cloud based RDBMS backends. Of course, what happens if Amazon decides to stop being a provider? With an RDBMS, it just means running obsolete software until one can get around to moving. With a cloud provider going under, one has to have a solution before they turn off the lights in place, or else all data is gone.
Finally... what about backups? Someone takes down some Amazon cloud servers, and the company using them is royally hosed. There are no tapes local, if there are backups on AWS or Glacier, they might be on the same datacenter or even the same SAN as the failed cloud servers. A conventional solution at least has the ability to have some tangible medium where the data is stored so it can be recovered.
Oracle is expensive, but they have a niche that nobody else can take them from... where almost every application will work with Oracle as a DB backend. They are similar to AutoCAD in the safe bet regard [1]. Not because they are light years ahead of the competition... but they have ended up in a place where it is easier to pay for upgrades rather than switch to another RDBMS.
Their only real competition in their market is DB/2 or maybe Sybase (because Sybase works as a backend to SAP.) For something used for a backend Web database, there are other solutions that work just as well, if possibly not better.
[1]: IBM used to have this, but I'd say the crown of "you can't be fired by buying this company's stuff" really belongs to Microsoft.
Oracle is a mixed bag. One one hand, it is really nice to be able to get up and running without having to make sure you have every single license key somewhere. On the other hand, there are the audits.
I'd add two things onto that:
1: The ability to click-to-play for add-ons. Chrome has this, and it does a great job at dealing with the loud ads that autoplay. This also adds security so that malware from a compromised or dodgy ad server doesn't get free reign to execute.
2: A VM-like structure similar to Chrome, so that a compromised window or tab is limited to just that context and can't take down the whole browser, or even worse, the user context it runs in. Chrome's VM is a big security plus. Not 100% security, but quite useful.
I will be a bit of a devil's advocate here:
We also need guidelines and standards for security. This isn't something that I can quantify, toss a high amount at a CISSP and get some unit of security. PCI-DSS3 is an example of decent guidelines. Another are the NIST SCAP items.
What would be an ideal would be some standard body making up security standards, not just guidelines (segment and firewall networks), but actual steps to secure operating systems and appliances with varying levels of security [1]. This wouldn't just be something that an organization could do once, but something that would have to be made at least quarterly with emergency workarounds coming out 24/7, such as replacing bash with Busybox or compiling a binary from the fixed source.
There are also issues and publications that wouldn't be as obvious... for example, guidelines on securing HVAC systems or basic power. Recommendations for organization charts to protect against social engineering, so someone name-dropping a VP doesn't get a file full of root passwords just by asking. Even physical guidelines like protecting against tailgaters at building entrances [2], or what type of lock cylinders to use (as some brands of cylinders had reports about security gaps which got remedied in later models.) Security is a moving target, and it would take a lot of cash to keep an organization funded which keeps on top of this... but it would do far more to help things than adding new regulations [3].
Right now, the major vendors have security tools usually baked into the OS which are pretty good. The trick is to have one coherent clearinghouse that can help people use what tools are available and still remain vendor neutral.
[1]: For example, on AIX, if I wanted one level of security, I'd sign all binaries on the system and configure trustchk to disallow anything else to be run. If I wanted higher than that, I'd disable root (so UID 0 processes had no "special-ness" about them) and set trustchk with LOCK_KERN_POLICIES on so there is no process on the system that can allow untrusted binaries, libraries, or even shell scripts to run.
[2]: Badge policies have to apply equally in a company, and if all someone needs to do is wear a suit or a uniform to get in, then physical security has failed. 99% of the time, it may just be nothing... but there is always that 1% where calling security on someone might have just stopped an attack.
[3]: Sarbanes-Oxley comes to mind. I've yet to read about it being enforced... except when it was used against an individual who had an improperly fished grouper.
Along the lines to this question, how can Tor's PR be helped? As of now, part of an IT person's job is to block Tor's exit nodes, on the application, kernel, and router level, because those nodes to be a source of many attacks. So, because of the bad reputation, it gets entirely locked out of many websites. This can be fixed by running a VPN over Tor so the exit comes from the VPN's servers, but there goes the anonymity for the most part.
One can accuse Kaspersky of being a mouthpiece for Russian propaganda, but in this case, this is a genuine threat.
One Wi-Fi network at a local eatery always tries to replace one of my E-mail provider's SSL keys with one from 192.168.168.168. Most people would just click "continue" or "accept"... or even have their Exchange client configured to accept any SSL key. This makes it plausible that a black bag group could step in to do stuff like this.
Of course, since people are so inundated with updates for Flash, Web browsers, and Java, clicking on yet another update becomes muscle memory, so a Trojan horse is definitely an avenue of attack. Couple this with a transparent proxy that is configured to MITM a key or two, and it isn't surprising how a group like this can score big.
The solution? There is no single magic bullet, but there are things that can help. The most important is user training, but next to that:
1: VPNs. The only key that can be attacked by a compromised local Wi-Fi AP would be the VPN's, and a good profile would just disallow access if this is the case.
2: Home Depot announced that it is moving to Macs. No, OS X is not 100% secure (as the exploit posted last week shows), but the bad guys have their tools honed for Windows. For the most part, Macs are not on the bad guys' menu. Running an alternative platform might be an idea.
3: Going with Citrix, and have the laptop be essentially a dumb terminal. Bad guys can still compromise it, especially with a RAT and taking over the session, but going with this raises the bar, especially if 2FA is used. Again, this isn't 100%, but it does help.
4: Tools like enterprise DeepFreeze. Store data on an encrypted, thawed partition, have the OS and applications be on the "frozen" drive. This makes cleanup a matter of just rebooting, assuming the documents are not compromised.
5: Tools like AppLocker or other programs to ensure unauthorized stuff isn't put on. For salespeople, this isn't going to happen, as they are the company breadwinners.
6: VMs. If the user knows what they are doing, VMs/sandboxes and a VDI can be useful, however, with non-technical people, the KISS principle is important, as they may not want to waste the time firing up a VM in order to browse the web between their presentations.
As for antivirus, this attack is a Dancing Pigs/Dancing Bunnies attack, and no AV software will protect against it, unless the user is denied admin rights on their laptop.
What we might have happen is that we end up with a mix, where a core is weighted towards a task... but compared to running a job at say, 80% as effectively as a core that is built for the job, versus not running the task at all, the scheduler [1] would drop tasks on non-optimal cores if it would help performance. If it is something definitely not optimal (FPU instructions on an integer-only core), the weighting would account for that and might not even place a task on there come the next quantum.
The 10x10 is interesting. However, on an average desktop, we could see quite a number of cores that (in addition to the normal CPU/GPU/FPU lineup) would be useful with special purposes:
1: A core running as a hypervisor, using something similar to ARM's TrustZone to ensure complete separation of tasks. This core (or perhaps two cores... one low power that uses very little wattage when the box is idle, and one that is faster when there is a lot of VM context shifting.)
2: A core that deals with I/O, with a lot of cache. Until the cache fills up, this would turn a lot of random I/O into sequential I/O, which is a lot easier for a hard disk or RAID array to deal with. This could even use fast SSD as another level, although a RAM cache handled by the OS might be just as good. This core can also offload software RAID commands (such as what ZFS, Storage Spaces, LVMs, and btrfs do), so performance would be improved on that end without having a dedicated RAID controller. Adding a battery backed up write cache (especially if the OS knows about it and can work with that) would only help things.
3: Cores to handle encryption are a given. AES is so often used that having space on a die to handle the S boxes and array shifting goes without saying.
4: High power and low power cores. Some phones have two sets of cores, one for when the device is not doing much, and one for when it is active use. For servers, this would come into handy because a DB server that doesn't get touched after 5:00 could just sit on a low-draw core, and when the DB starts getting hit by transactions, moved back to a faster one. This in itself would save a lot of wattage at the expense of die space.
5: Similar to #1, but the core would have its own separate I/O, memory, and other space. This could be used for the hypervisor, or tasks that need to be isolated from everything in the machine. A Harvard architecture could be used to further prevent attacks like smashing the stack or heap.
6: Ye Olde FPGAs. One never knows when these may come in handy, and having an application with oddball CPU requirements be able to use one may help performance immensely.
7: A dedicated CPU just for scanning RAM space. This could be used for a host IDS/IPS, or performance/health monitoring.
8: A dedicated NIC-like core whose purpose is optimized for packetization/depacketization. Pretty much a FCoE CNA, except with the added ability to work as a firewall outside of the host machine's OS. Around 10 years ago, some computers had "smart NICs", and could have firewalling code on there that would guard the machine (say, keep port 25 from going anywhere) even if the box's main OS was compromised. Give the machine SFP slots, and depending on the SFP inserted, the machine could use that slot as a FC HBA, a FCoE CNA, an iSCSI adapter, or "just" used for plain Ethernet traffic. That way, one doesn't have to even replace cards to move to a new SAN technology... just the media adapter gets replaced.
I'm sure there are many others, but once making chips smaller has diminishing returns, then going with sheer number of cores stops being working, going with special purpose cores, or ones weighted towards a task is the next step.
Some devices have had a NFC based pay system. SoftCard comes to mind. It uses NFC, and an application on the SIM card, which is harder to attack than just another app on the phone.
Of course, there is the fact that SoftCard requires one to use a specific credit card... but the technology has been in place in a secure manner from the SIM card on up.
I'm just hoping Android's implemention of this is decently secure. CurrenC is waiting in the wings, and if Apple Pay and Android implementations flop, this will be waiting to become the primary payment provider... and it completely bypasses the credit card fraud protections, so if money is stolen... the consumer is stuck with the losses.
The fuel cells I've seen are not going to replace a generator anytime soon. They put out a couple hundred watts out at most, which might be enough to keep a battery bank charged over a period of time, but don't put out enough oomph to directly power electric motors.
As for disasters, I've seen people use an inverter with Prius and other hybrid models which is functionally equivalent to a generator, although the inverter had to be a PSW model.
Of course, generators are a good option, but usually I see people buy a generator, use it, stick it in the garage, and in 1-2 years, pull it out, and find that the carb is completely gummed up. Generators either need to be properly fogged or at least run occasionally, and if stored with fuel, need a fuel preservative (Sta-Bil, Star-Tron, Seafoam, or others) added to minimize varnish, especially with ethanol blends, as ethanol sucks water in from the air.