Since Fable 5 and Mythos 5 landed back in June, I keep seeing the same reaction online - "AI can now hack anything, we're doomed." I've been mulling this over, mostly in the context of a self-hosted, encrypted project I'm tinkering with, and I don't think the panic is pointed at the right thing.
mddoco is a Python module to generate HTML and PDF documents from Markdown. It was inspired by typst with the same idea, but I wanted something simpler, and not have to learn a new language. With markdown being such a widely used format, I thought it's best to stick to that.
Every few years, something new comes along and the infosec community collectively loses its mind. AI is no different. Businesses are moving fast, GRC teams are scrambling to catch up, and everyone is asking the same question - how do we manage this risk?
I've been in this space long enough to know that the answer is usually simpler than it looks.
The Zero Trust methodology has been around for a while, and many organisations have been implementing Zero Trust principles. When considering applications deployed in an enterprise, organisations typically implement zero trust at the infrastructure layer, protecting access to and from applications and securing network communications.
Infrastructure-level protection is essential, but there's another threat vector: the application itself. While SDLC processes and security tools help secure code, there's an opportunity to implement Zero Trust principles directly within applications.
"Build my cyber security dashboard, and put metrics on the board" - A statement I have heard all too often, and when you go into the design phase to choose the metrics, there are blank stares all around the room. We want to measure something, but we don't know what.
Some companies like to combine their Security and Compliance teams into one entity. I've worked in environments like that before, and I can tell you from experience that it is usually a bad idea to mix the two. Let's dig into it.
Many of us have the need to develop code, code that may have access to very sensitive data, or code that has the ability to wreck havoc on an environment. Whatever the development requirement is, there is a need to be vigilant with the code you develop, and ensuring that you do not inadvertently introduce security issues that could otherwise have been avoided.
An involuntary data breach is a data breach where you information got compromised without your direct involvement. This is typically where your information is stored in a data location that you're unaware of, or have no control over. In a recent security incident, my own contact details have been exposed, through a friend's compromised phone. This is the story of that event.
Single Sign-On (SSO) is an authentication process that allows users to access multiple applications or services with one set of login credentials—typically a username and password. Instead of having to log in separately to each application, users authenticate once through a central identity provider, which then grants access to connected systems. This approach simplifies the user experience by reducing password fatigue and improving productivity, as users no longer need to manage multiple accounts or remember numerous passwords. SSO also enhances security by centralizing authentication and allowing for more robust controls, such as multi-factor authentication and centralized monitoring, thereby reducing the attack surface for potential breaches.
Another security breach has made the news. This time the folks at Ticketek are having a hard time explaining why ...customers' names, emails and dates of birth may have been accessed in cyber security breach.