Live Patching | Breaking Cybersecurity News | The Hacker News

SecDevOps is, just like DevOps, a transformational change that organizations undergo at some point during their lifetime. Just like many other big changes, SecDevOps is commonly adopted after a reality check of some kind: a big damaging cybersecurity incident, for example. A major security breach or, say, consistent problems in achieving development goals signals to organizations that the existing development framework doesn't work and that something new is needed. But what exactly is SecDevOps, why should you embrace it – and how can you do it more easily in practice? The fundamentals of SecDevOps By itself, SecDevOps is not just one single improvement. You may see it as a new tool, or set of tools, or perhaps a different mindset. Some might see SecDevOps as a culture. In reality, it's all of those factors wrapped into a new approach to development that's intended to put security first. SecDevOps rely on highly reproducible scenarios, touching on topics such as system

Conflicting business requirements is a common problem – and you find it in every corner of an organization, including in information technology. Resolving these conflicts is a must, but it isn't always easy – though sometimes there is a novel solution that helps. In IT management there is a constant struggle between security and operations teams. Yes, both teams ultimately want to have secure systems that are harder to breach. However, security can come at the expense of availability – and vice versa. In this article, we'll look at the availability vs. security conflict, and a solution that helps to resolve that conflict. Ops team focus on availability… security teams lock down Operations teams will always have stability, and therefore availability, as a top priority. Yes, ops teams will make security a priority too but only as far as it touches on either stability or availability, never as an absolute goal. It plays out in the "five nines" uptime goal that sets an incredibly high

Government agencies publish notices and directives all the time. Usually, these are only relevant to government departments, which means that nobody else really pays attention. It's easy to see why you would assume that a directive from CISA just doesn't relate to your organization. But, in the instance of the latest CISA directive, that would be making a mistake. In this article, we explain why, even if you're in the private or non-government sector, you should nonetheless take a close look at CISA Binding Operational Directive 22-01. We outline why CISA was forced to issue this directive, and why that firm action has implications for all organizations – inside and outside of government. Acting on cybersecurity issues isn't as simple as flicking a switch, of course, so keep reading to find out how you can address the core issue behind the CISA directive. Okay, so what exactly is a CISA directive? Let's take a step back to gain some context. Just like any organ

Sysadmins know what the risks are of running unpatched services. Given the choice, and unlimited resources, most hardworking administrators will ensure that all systems and services are patched consistently. But things are rarely that simple. Technical resources are limited, and patching can often be more complicated than it appears at first glance. Worse, some services are so hidden in the background, that they just don't make it onto the list of things to be patched. QEMU is one of those services that tend to create difficulties with patching. It works away in the background and is easy to take for granted. Plus, patching QEMU involves significant technical and practical challenges – while requiring enormous resources. In this article, we'll address some of the difficulties around patching QEMU, and point to a solution that takes the toughest bits out of QEMU patching. Ignoring QEMU patching is a big risk You'll probably know about it if you're using QEMU – shor