Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

The idea of converging cyber intelligence, AML, and fraud prevention activities to eliminate the gaps between these silos of financial crime risk management has been discussed for years. However, recent developments in global real-time payments, open banking, and booming digital transactions have escalated the need for this convergence. In this era of instant payments and CNP transactions, traditional siloed approaches to financial crime prevention are loosing their effectiveness.

Change is prolific in organizations’ IT environments. Hardware assets change. Software programs change. Configuration states change. Some of these modifications are authorized insofar as they occur during an organization’s regular patching cycle, while others cause concern by popping up unexpectedly. Organizations commonly respond to this dynamism by investing in asset discovery and secure configuration management (SCM).

Like any great technology, the interest in and adoption of Kubernetes (an excellent way to orchestrate your workloads, by the way) took off as cloud native and containerization grew in popularity. With that came a lot of confusion. Everyone was using Kubernetes to move their workloads, but as they went through their journey to deployment, they weren’t thinking about security until they got to production.

Dealing with hundreds of security alerts on a daily basis is a challenge. Especially when many are false positives that waste our time and all take up too much of our valuable time to sift through. Let me tell you how our security team fixed this, as we built security around the JFrog products. First, let me tell you a little bit about our team.

Fairwinds Insights is Kubernetes governance and security software that enables DevOps teams to monitor and prevent configuration problems in their infrastructure and applications. Not only does Fairwinds simplify Kubernetes complexity, but it also reduces risk by surfacing security and reliability issues in your Kubernetes clusters.

Just when the Microsoft Exchange exploit CVE-2021-26855 thought it would win the “Exploit of the year” award, it got unseated by the – still evolving – Log4J exploit just weeks before the end of the year! Had somebody asked Sysadmins in November what Log4J was then I suspect that the majority would have had no idea. It seems that the biggest challenge the Log4J exploit poses for Sysadmins is simply the fact that nobody knows all the places where Log4J is being used.