“Just write a short motivation letter regarding this conversation” is a sentence that I speak to cybersecurity professionals on a regular basis. Internal research at Cqure has shown that the motivation letter does not always have the desired result, while it is apparently a good piece of text. How is that actually possible? And why is good motivation letter so important?...
With independent articles, interviews and videos by professionals, for professionals.
This week I released a cheat sheet for the Kusto Query Language (KQL), which you can find on my GitHub page: kql_cheat_sheet.pdf. When I started with KQL to analyse security events, the primary resources for me to get started were the official KQL documentation from Microsoft and the Pluralsight course from Robert Cain. Something was missing: a cheat sheet. So, I created one. I hope this cheat sheet will help others in using KQL. If you have additions or remarks, please contact me.
As a chief information security officer, one of the biggest challenges I faced was in measuring the value of our organization’s cybersecurity investment. Fortunately, tools and methodologies to translate cybersecurity more specifically into costs and benefits are now available, so CISOs can be more detailed than ever before in measuring the effectiveness of risk mitigation.
By attaching real numbers to cybersecurity—this is how much a breach will cost us, this is how much we can reduce risk by making this specific investment—CISOs can work with the C-suite to make more informed decisions.
Cybersecurity risk mitigation is more critical than ever. With most companies embracing digital transformation, the impact of a breach can be crippling, in terms of money lost, damage to brand reputation and partner/customer goodwill. At the same time, the threat landscape is increasingly sophisticated, better funded and more coordinated.
In this day and age having a functioning and secure Software Development Life Cycle (SDLC) process in place is becoming a key component of a successful organization. And one methodology that is becoming increasingly popular is DevOps. Mainly, because the methodology itself is designed to produce fast and robust software development. In this article, we will focus on how we can incorporate security into CI/CD and turning DevOps into DevSecOps easily and with automation in mind.
It’s quite a long article, so in case you are already familiar with some of the terms, feel free to skip to whatever part pleases your curiosity :)
The Dutch Central Bank released a discussion paper on general principles on AI in Finance which you can read here. On the surface, it seems rather well thought out. But as it is a discussion paper, there’s ample room for discussion…
Starting with the decades-old big error of apparently haphazard classification of risks. When the classification isn’t mutually exclusive and collectively exhaustive, one loses the ground for hope of any suitable quality of subsequent classification(s). For example, this happened with the operational risk classification in the Basel-II framework, left dangling in versions ‑III and ‑IV for apparent reasons. And now again, we see in the principles, quite some overlaps and double counting.
This post concerns application security teams, so it’s written assuming you are part of one. However, I believe it could help you understand application security a bit more even if you are not.
If you are part of an application security team, you probably struggle with the amount of work on your shoulders every day. Let’s say you have a small team of 5 people to test all web applications produced by a group of 200 developers, and you still need to provide guidance on how to fix some vulnerabilities. You try to offload some work by handing developers with security testing tools, but the learning curve is long - causing frustration. Basically, you have a scaling issue!
Jira is one of the most widely adopted Issue and Project Tracking Software out there. Atlassian’s Jira has been named the #1 software development tool for agile teams. And Probely now allows you to synchronize your security issues into your Jira issue tracker. So, how do you manage vulnerabilities in Jira using Probely?
Multidisciplinary Aspects of Blockchain is a different book on a fundamental digital technology under development and published in Dutch (hardcopy) and English (eBook) as part of a series of the Royal Dutch Society for Computer and Information Professionals. Blockchain, which reportedly changes society as the ultimate disruptor and most important invention after the introduction of the World Wide Web of Internet. Blockchain is a collective term for digital databases, which are distributed, mathematically-protected and chronological in nature.
“I rob banks because that is where the money is”, is a famous quote attributed to (in)famous bank robber Willie Sutton. It is also known as Sutton’s Law. Suttons law still holds true for many things, including modern (cyber)crime. If you want to earn money from your crimes, focus on what people value most.
Ransomware is an example of just this. Criminals target what is most valuable to organisations and individuals, their data or memories.
Data leaks have become an all-too-common societal problem. Still, 99% of the problems do not involve scary zero-day bugs. So why is security still hard? We need to accept that technology isn’t going to save us. Rather, thinking it can, got us in this situation in the first place. We need a new way of teaching and implementing security across our organizations. I am introducing the AVA=Risk Security Model to help us get there.
We note divergent digital law trends of statutory nature – many of which have been going on for some time, starting-out two or even three decades ago. Just to give an idea in an at random sequence: modernizing and extending intellectual property laws, updating penal legislation with new crimes like hacking and computer sabotage, amending the Criminal Procedure Code with extensive powers for the police and public prosecution, strengthening the legal position of the online consumer, introducing and tightening data privacy laws, adjusting evidence laws, and implementing security regulations.
A month ago we, Ruben and Marcus, released the first version of DeTT&CT. It was created at the Cyber Defence Centre of Rabobank, and built atop of MITRE ATT&CK. DeTT&CT stands for: DEtect Tactics, Techniques & Combat Threats. Today we released version 1.1, which contains multiple improvements: changelog. Most changes are related to additional functionality to allow more detailed administration of your visibility and detection.
By creating DeTT&CT we aim to assist blue teams using ATT&CK to score and compare data log source quality, visibility coverage, detection coverage and threat actor behaviours. All of which can help, in different ways, to get more resilient against attacks targeting your organisation.
In this blog we start off with an introduction on ATT&CK and continue with how DeTT&CT can be used within your organisation. Detailed information about DeTT&CT and how it can be used, is documented on the GitHub Wiki pages. Therefore, the explanation we give in this blog will be high-level.
Not too long ago I was in a SANS course, about the Critical Security Controls. More than once our teacher Russell nudged us, suggesting that “you could be applying these to your home network as well!” which brought us to the subject of testlabs. “What would make a good testlab for us?” was something asked along the way.
To sum things up: it really doesn't have to be glamorous! As long as your lab helps you experiment and learn, it's a good lab for your! So here's a few quick reminders for IT folks who would like to get their feet wet in setting up their own labs.
At BitnessWise we recently did a review of a few Two Factor Authentication (2FA) plugins for WordPress. First we selected some candidates based on usability and free-version features and after that performed a technical review of the plugin. This revealed a vulnerability we’d like to discuss in this post for future reference and to better understand the issue.
In most organisations using Active Directory and Exchange, Exchange servers have such high privileges that being an Administrator on an Exchange server is enough to escalate to Domain Admin. Recently I came across a blog from the ZDI, in which they detail a way to let Exchange authenticate to attackers using NTLM over HTTP. This can be combined with an NTLM relay attack to escalate from any user with a mailbox to Domain Admin in probably 90% of the organisations I’ve seen that use Exchange. This attack is possible by default and while no patches are available at the point of writing, there are mitigations that can be applied to prevent this privilege escalation. This blog details the attack, some of the more technical details and mitigations, as well as releasing a proof-of-concept tool for this attack which I’ve dubbed “PrivExchange”.