Marvin Waschke

Author Archives: Marvin Waschke

IDG Contributor Network: How to handle risks of hypervisor hacking

Global cloud computing and digital systems today would not exist without virtualization and hypervisors. Virtualization and hypervisors are basic tools for implementing digital systems that respond from moment to moment to varying demands without slow and expensive physical reconfiguration of hardware and rebuilding of software execution stacks and heavy investment in hardware that is only used during peak loads.Last blog, I described the dangers of a hypervisor attack. How can such an attack occur? There are a number of ways.Resource simulations A hypervisor provides software simulations of basic computing resources — like CPUs, memory, storage and network connections — that isolate VMs from one another. But the isolation may have soft spots. For example, freed simulated memory for one VM might be the same physical memory the hypervisor allocates to another VM. If the hypervisor does not blank out the reallocated physical memory, the second VM has access to data from the first VM and a data breach ensues. All resource simulations are subject to dangerous implementation errors. Simulated CPU registers, storage buffers and network buffers, all present opportunities for coding mistakes that permit data or control breaches.To read this article in full or to leave Continue reading

IDG Contributor Network: Are VMs more secure than containers?

We often say, “HTTPS is secure,” or “HTTP is not secure.” But what we mean is that “HTTPS is hard to snoop and makes man-in-the-middle attacks difficult” or “my grandmother has no trouble snooping HTTP.”Nevertheless, HTTPS has been hacked, and under some circumstances, HTTP is secure enough. Furthermore, if I discover an exploitable defect in a common implementation supporting HTTPS (think OpenSSL and Heartbleed), HTTPS can become a hacking gateway until the implementation is corrected.HTTP and HTTPS are protocols defined in IETF RFCs 7230-7237 and 2828. HTTPS was designed as a secure HTTP, but saying HTTPS is secure and HTTP is not still hides important exceptions.To read this article in full or to leave a comment, please click here

IDG Contributor Network: Are VMs more secure than containers?

We often say, “HTTPS is secure,” or “HTTP is not secure.” But what we mean is that “HTTPS is hard to snoop and makes man-in-the-middle attacks difficult” or “my grandmother has no trouble snooping HTTP.”Nevertheless, HTTPS has been hacked, and under some circumstances, HTTP is secure enough. Furthermore, if I discover an exploitable defect in a common implementation supporting HTTPS (think OpenSSL and Heartbleed), HTTPS can become a hacking gateway until the implementation is corrected.HTTP and HTTPS are protocols defined in IETF RFCs 7230-7237 and 2828. HTTPS was designed as a secure HTTP, but saying HTTPS is secure and HTTP is not still hides important exceptions.To read this article in full or to leave a comment, please click here

IDG Contributor Network: Containers and virtual machines: Which is best for you?

If you want to stop someone from driving a car, you can take away the keys. Quick, easy and effective. Alternatively, removing the wheels and engine will work, too.A container is an OS extension that takes away keys, leaving the OS intact. A virtual machine (VM) reworks the architecture, separating the car from the wheels and engine. Taking the keys is easy, but the driver might have spares, and a car can be hot-wired in about a billion ways. Removing the wheels and engine is a lot of trouble, but the car won’t move without them. And when you mount snow tires, that removable wheel architecture is handy.Time-sharing computers Containers and VMs go back to the beginning of time-sharing, an outstanding advance in mid-twentieth century computing. A single time-sharing computer supports multiple users running multiple tasks at the same time. Each user thinks they control the entire machine.To read this article in full or to leave a comment, please click here

IDG Contributor Network: Cloud failures can occur anywhere on the hype cycle

Cloud architecture has settled into its “plateau of productivity” phase in the hype cycle. It has gone through experimental adoption, irrational enthusiasm, and despondent disillusion. Does that mean cloud projects are more likely to succeed now? Good question. The answer depends on both the business and engineering side of the project.On the productivity plateau, the battle is over. Efficient implementations blithely pile up profits for the stakeholders. Stop! This is not exactly my experience as a software engineer and architect. Projects succeed and fail in every stage of the hype cycle. The predominant reasons for failure may change with the phase, but a more mature technology is no guarantee of success. An engineer builds systems to meet the stakeholders’ requirements. The hype cycle is perception and expectation, not requirements.To read this article in full or to leave a comment, please click here