Oracle and Sybase as well have this type of licensing, unless something has changed.

IBM addressed this with POWER7 and newer in a fairly innovative way. They have an option called TurboCore mode which turns off half the cores. The ones still running can use the disabled core's caches, and because of the space available for heat dissipation, clock speed could be bumped up. The result was half the cores, but almost the same performance due to the faster clock and cache available.

I don't know a single cloud provider that would provide that contract. In other lines of work, there would be a third party escrow company. However, with a cloud provider, since decryption would be needed, the only way to provide any assurance is to have some backend appliances that do encryption and are rented, with a paid deposit that once the rental ceases, all keys are wiped. That way, a bankrupt provider would have all their servers sold, but the encryption appliances would be owned by another party. Of course, this may not mean much as it might be a fight wresting the leased items from the bankruptcy trustee, but in theory, it helps put at least a layer in place of protection.

However, I don't know any cloud provider who would spend the time and effort to do this, just because the current system of assuring people that "passwords", "encryption", and "firewalls" is good enough.

How would a cloud provider assure customers that their data will remain secure if they go bankrupt or just quit the business?

As of now, if a provider tanks, the servers go to the auction house, and in theory, are blanked. However, in reality, there is no assurance of that, and the buyer will get all data stored free and clear. If they wanted to do a multi-terabyte torrent of a failed bank's account and transaction data, they can, and nothing legally could stop them.

I personally have used Xymon with more than that many systems. It takes time to classify them, but it is doable.

The price is right on Xymon, however, if I were to recommend a monitoring solution for both real time, "oh shit" monitoring such as a drive array about to fail as well as a historical log (for security and finding a baseline), I'd go with Splunk if possible due to the tools available, and the fact that you can send management-friendly reports about the health of the enterprise up the chain.

Again, a monitoring server is one of the most sensitive boxes you can have (and usually one that isn't secure), so take the time to harden it and do it right.

I would elaborate on that a bit. I would have in the colo facility a Cisco ASA or other hardened appliance, and use that for the VPN connection.

I would then build a hardened server that accepts the stuff the parent points out, SNMP traps, syslog (both TCP and UDP), but I would recommend a tool like Splunk or a similar item. Splunk has served me well in my dealings. Once that is in place, I'd set up Splunk forwarders on critical machines for more detailed monitoring.

From there, I'd create a dashboard for realtime reporting, and a daily report detailing notable events from the past 24 hours. One can customize this to their liking. You can even have the reports mailed to you via the VPN to an internal site.

The Splunk server will need locked down, but if one is in IT, this is an assumed part of the skillset. I would at least leave SELinux enabled, enroll the Splunk server's SSL key in your PKI, and for the OS, enable SSH keys and two factor authentication. I might even consider placing the Splunk indexes on an encrypted filesystem so if the hardware is physically stolen, the data on your machines is protected.

Again, the thing to be careful about is the fact that so much sensitive data is on this machine, so it needs a separate firewall, and the box itself needs to be hardened.

Why should content protection be part of the Internet standard? Why do my devices (routers, computers, etc.) have to have built in DRM which will end up getting cracked, or at least possibly exploited from offshore?

This also is going to be met with a lot of suspicion. Who keeps the keys, gets to keep content locked, owns the license servers, and is able to come in via backdoors mandated as part of the protocol? The UN? Give me a break. China? Sure, we can trust them allright, provided we give them 51% ownership of any venture. It won't be the US because BRIC will sooner create their own network and completely split off.

I don't reject change... but what does this new protocol give me? IPv4 and to a lesser extent IPv6 have been torture tested, are completely open, and one can cobble together adequate defenses against attacks not too expensively (Cisco ASAs on the low end are a couple C-notes, and there are always smaller routers). A protocol based around DRM and content protection, stuff that is made to obfuscate and lock down is not going to be of any benefit to anyone but a few.

To boot, this seems like a complex mess. A network protocol should be brain-dead simple in order to reduce the attack surface, and reduce bugs. Adding DRM at layer 2 is at best will slow things down, at worst, allow the bad guys to hide behind bogus certificates.

Grabbing my tinfoil hat, I'm wondering if this protocol is something that will end up mandated within hours as soon as a "warhol event", or something more known as a "cyber 9/11" happens. I would not be surprised if this is already written and ready to be thrown on the floor as a bill on both houses the second some major security breach happens that causes catastrophic damage.

I'm seeing shades of the Clipper chip again, with the same problems. The bad guys getting access to the backdoors, compromising everyone in a way that cannot be patched, the bad guys closing the backdoors so they can't be investigated by LEOs... and the biggest losers are the good guys.

Does FERPA have any teeth in it? I've yet to hear about it actually being enforced. Similar with HIPAA, I've read about a slap on the wrist here and there after some medical facility had all their info lost. Even PCI-DSS seems to be more lip service than anything else, mainly CYA if that.

The only way we are going to see anything but miserable, failed excuses of security as SOP in the industry is if there are grave consequences for breaches, and not just XYZ company getting fined, declaring bankruptcy and reforming as ABC company (with all the assets owned by holding organizations), but actual "go to jail, do not pass go, do not collect $200" consequences on someone other than some low-level lackey who is still standing when the music stops.

Easy fix... one time pads. Tank number 128 gets a transaction, it decodes it using the OTP it has in a secure part of the controller, then blows e-fuses on the other equipment.

Since there isn't a need for public key encryption, having a remote site and the tank share a pad is feasible and as per basic crypto theory, if the key is as long or longer than the encrypted communication, there is no feasible way to break it. An attack would have to be done at the remote site, or at the tank itself.

If I can get code to execute in a context of a jailed UNIX process, such as a webserver, which would allow me to send traffic in and out, a malware writer has a usable client for a botnet, for spam, DDoS, and other uses. Even if they just have control of that webserver's port 80, they can use that and modify the server to occasionally serve malformed pages in hopes of nailing a buggy browser or browser add-on.

Similar to a program that just gets access to a user context in Windows. With just user access, their files can be encrypted for random, pictures can be copied off for blackmail, and the machine can still function as a botnet client.

Layers are critical. Even with limited contexts, firewalls are still crucial (to prevent a web server from making outgoing communication, for example), as well as integrity checks.

In a way, I'm hoping for more eyes on Linux for security vulnerabilities. The reason is that if they appear, they can get fixed almost immediately. MS is decent at handling patches, but most bugs end up waiting until Patch Tuesday, unless it warrants an out of band fix.

Maybe I'm showing my age... part of the standard procedure of getting Linux set up and deployed was getting onto security mailing lists like Bugtraq and its successors. It is a lot of mail, but better some time spent finding and fixing a vulnerability, than the time it takes dealing with a successful attack, or even an intrusion attempt, especially if an organization has different IT groups (network, system, SAN, etc.)

On one hand, Linux has had a reputation for being secure. On the other hand, Windows has made great strides in improving things.

On the gripping hand, security really belongs to the person sitting at the admin console [1]. The first thing a lot of Linux users do is kill SELinux, which weakens the security model tremendously, where it takes is just one weak SUID program or one running as root to have the machine. The second thing is that because Linux doesn't have signed executable functionality [2], something like AIDE or tripwire is a must.

From there, it is about basic security practices. If a server sits for months to years without updates, it doesn't matter what OS it runs, eventually there will be a hole, and eventually it will get pwned.

[1]: Be it an actual window, a serial port, a VMWare console, SCVMM window, remoted in via SSH or RDP.

[2]: It would be nice if the Linux kernel had functionality compared to trustchk in AIX. It isn't signed executables per se (since it uses a manifest list), but it does help prevent unauthorized stuff from loading, even libraries.

grsec, and AppArmor. SELinux is a very good system, but AppArmor is easier to understand and work with.

Going blue-sky, having the ability to turn on a trusted executable list similar to AIX would be nice. It doesn't have to be signed executables per se, but a way to have a manifest list of OK things to run.

Or something close to the BSD jail() command.

What would be close to ideal would be something like jail() except that the jailed program would get its own loopback filesystem. This way, if a malicious task does things like make a lot of files in effort to consume all free inodes or create a directory link so deep rm() can't unlink it, the damage just affects that partition, and nothing else. I've found malware that did that in Windows, so when I use sandboxes, they go to their own dedicated volume that can be easily reformatted.

Even earlier than that, my ancient HTC Wizard, a 2006 vintage device, could handle a couple gigs on its miniSD card, and for e-books, that can hold a lot of stuff. The 2009 vintage Motorola CLIQ with a MicroSD card, similar.

It doesn't take much for a device to handle e-books.

One thing I wish Exchange [1] had was the ability (and would be turned off by default like POP and IMAP support) to have application passwords, as well as the ability to support 2FA if someone is logging in via the Internet.

It is ironic that all of my "free" E-mail accounts have 2FA on them, while my paid providers don't have this functionality.

[1]: Probably AD as well, for storing the random seed key for the secondary authenticator, as well as when to ask for the authenticator versus just the password only.