threatactor.club

I‘m busy preparing lectures (and will be for the rest of the term), both for foundations of cyber security and, more specialized, #incidentresponse & incident management. Last week I was wondering which recent motivational examples to use, this weekend it’s hard to decide between the oddly specific KiteWorks warning and yet another round of Citrix quality solutions. I’ll probably just take both and link them with their respective past issues and (exemplary) their impact in terms of resulting compromises. Would love to see numbers on total costs resulting from auch a single supply chain issue, but I doubt there’s more than more or less (un)realistic estimates, if any.

Full-cost pricing of deciding for a product from a vendor with a non-impressive security track record. „Customers similar to you, who bought this product, had 5y aggregated follow-up costs from resulting incidents and remediation of x k€.“ Now that would be market transparency.

I have accepted the offer of a professorship at FH Münster for computer science, esp. defensive IT Security and critical IT infrastructure. I joined at the beginning of the month. I am grateful for the opportunity, everything I learned at my previous employer and for a lot of people there, and for the warm and supportive welcome I received and am receiving at my new department.

USG decided once again to contribute to the tech sovereignty discussion, using the example of AI model access: https://www.anthropic.com/news/fable-mythos-access

Luckily for everyone (except Anthropic) the affected models were a) new and b) most probably too heavily fraught with safeguards to be already in relevant production use.

How do we know that we detect what we intend to detect? There are quite a few answers to that question, regrettably also along the lines of “we’ve implemented the detection, d’oh!”.

In the last two years we have been (and continue to be) busy with improving efficiency and effectiveness in detection engineering. The traditional manual approach clearly doesn’t cut it in a large heterogeneous IT landscapes of today, where security monitoring makes use of more than one or two technologies to gain visibility in a variety of system contexts. We thus quickly moved towards Detection as Code (DaC). The question of how a CI/CD pipeline in this context would look like then swiftly confronted us with the question of testability of detection mechanisms, which led to the question of how to automate tests. Having solved that, we arrived at: “if we agree that we want to verify detection effectiveness anyways, why don’t we define a test for a potential attacker action first, if and only accept detections for that specific vector, if they pass the test?“

Adapting from Kent Beck‘s concept of Test-Driven Development (TDD) in software engineering, we refer to our approach as Test-Driven Detection Engineering (TDDE).

We’ve written up the what and how in a short paper together with @seecurity, which we decided to submit to DIMVA as a mere poster, as all of that is WIP. We‘re happy that our submission has been accepted and I’m looking forward to discuss the approach with attendees and fellow practitioners.
Find a preprint of the short-paper here: https://tilmanfrosch.de/dl/preprint/Test_Driven_Detection_Engineering.pdf

Aloha! I expect this account to be rather low-traffic.