Author: otmar

Categories
CERT Pet Peeves

On Cybersecurity Alert Levels

Last week I was invited to provide some input to a tabletop exercise for city-level crisis managers on cyber security risks and the role of CSIRTs. The organizers brought a color-coded threat-level sheet (based on the CISA Alert Levels) to the discussion and asked whether we also do color-coded alerts in Austria and what I think of these systems.

My answer was negative on both questions, and I think it might be useful if I explain my rationale here. The first was rather obvious and easy to explain, the second one needed a bit of thinking to be sure why my initial intuition to the document was so negative.

Escalation Ratchet

The first problem with color-coded threat levels is their tendency to be a one-way escalation ratchet: easy to escalate, but hard to de-escalate. I’ve been hit by that mechanism before during a real-world incident and that led me to be wary of that effect. Basically, the person who raises the alert takes very little risk: if something bad happens, she did the right thing, and if the danger doesn’t materialize, then “better safe than sorry” is proclaimed, and everyone is happy, nevertheless. In other words, raising the threat level is a safe decision.


On the other hand, lowering the threat level is an inherently risky decision: If nothing bad happens afterwards, there might be some “thank you” notes, but if the threat materializes, then the blame falls squarely on the shoulders of the person who gave the signal that the danger was over. Thus, in a CYA-dominated environment like public service, it is not a good career move to greenlight a de-escalation.


We’ve seen this process play out in the non-cyber world over the last years, examples include

  • Terror threat level after 9/11
  • Border controls in the Schengen zone after the migration wave of 2015
  • Coming down from the pandemic emergency

That’s why I’ve been always pushing for clear de-escalation rules to be in place whenever we do raise the alarm level.

Cost of escalation

For threat levels to make sense, any level above “green” need to have a clear indication what the recipient of the warnings should be doing at this threat level. In the example I saw, there was a lot of “Identify and patch vulnerable systems”. Well, Doh! This is what you should be doing at level green, too.


Thus, relevant guidance at higher level needs to be more than “protect your systems and prepare for attacks”. That’s a standing order for anyone doing IT operation, this is useless advice as escalation. What people need to know is what costs they should be willing to pay for a better preparation against incidents.


This could be a simple thing like “We expect a patch for a relevant system to be released out of our office-hours, we need to have a team on standby to react as quickly as possible, and we’ve willing to pay for the overtime work to have the patch deployed ASAP.”. Or the advice could be “You need to patch this outside your regular patching cadence, plan for a business disruption and/or night shifts for the IT people.” At the extreme end, it might even be “we’re taking service X out of production, the changes to the risk equation mean that its benefits can’t justify the increased risks anymore.”.


To summarize: if there were no hard costs to a preventative security measure, then you should have implemented them a long time ago, regardless of any threat level board.

Counterpoint

There is definitely value in categorizing a specific incident or vulnerability in some sort of threat level scheme: A particularly bad patch day, or some out-of-band patch release by an important vendor certainly is a good reason that the response to the threat should also be more than business-as-usual.


But a generic threat level increase without concrete vulnerabilities listed or TTPs to guard against? That’s just a fancy way of saying “be afraid” and there is little benefit in that.

Postscript: Just after posting this article, I stumbled on a fediverse post making almost the same argument, just with April 1st vs. the everyday flood of misinformation.

Categories
Internet Pet Peeves

Kafka wohnt in der Lassalle 9

Ich bin wohl nicht der einzige technikaffine Sohn / Schwiegersohn / Neffe, der sich um die Kommunikationstechnik der älteren Generation kümmern muss. In dieser Rolle habe ich gerade was hinreichend Absurdes erlebt.

Angefangen hat es damit, dass A1 angekündigt hat, den Telefonanschluss einer 82-jährigen Dame auf VoIP umstellen zu wollen. Das seit ewigen Zeiten dort laufende “A1 Kombi” Produkt (POTS + ADSL) wird aufgelassen, wir müssen umstellen. Ok, das kam jetzt nicht so wirklich überraschend, in ganz Europa wird das klassische Analogtelefon Schritt für Schritt abgedreht, um endlich die alte Technik loszuwerden.

Also darf ich bei A1 anrufen, und weil die Dame doch etwas an ihrer alten Telefonnummer hängt, wird ein Umstieg auf das kleinste Paket, das auch Telefonie beinhaltet, ausgemacht. Also “A1 Internet 30”. 30/5 Mbit/s klingt ja ganz nett am Telefon, also bestellen wir den Umstieg (CO13906621) am 18.11.2023. Liest man aber die Vertragszusammenfassung, die man per Mail bekommt, so schaut das so aus:

Da die Performance der alten ADSL Leitung auch eher durchwachsen und instabil war (ja, die TASL ist lang), erwarte ich eher den minimalen Wert, was einen Faktor 2 bzw. 5 weniger ist als beworben. Das Gefühl, hier über den Tisch gezogen worden zu sein, führt zu dem Gespräch: “Brauchst du wirklich die alte Nummer? Die meisten der Bekannten im Dorf sind doch schon nur mehr per Handy erreichbar.”

Ok, dann lassen wir die Bedingung “Telefon mit alter Nummer” sausen und nehmen das Rücktrittsrecht laut Fern- und Auswärtsgeschäfte-Gesetz in Anspruch und schauen uns nach etwas Sinnvollerem um. An sich klingt das “A1 Basis Internet 10” für den Bedarf hier angebracht, aber wenn man hier in die Leistungsbeschreibungen schaut, dann werden hier nur “0,25/0,06 Mbit/s” also 256 kbit/s down und 64 kbit/s up wirklich zugesagt. Meh. So wird das nichts, daher haben wir den Umstieg storniert und den alten Vertrag zum Jahresende gekündigt &emdash; was auch der angekündigte POTS-Einstellungstermin ist.

Der Rücktritt und die Kündigung wurden telefonisch angenommen und auch per Mail bestätigt.

So weit, so gut, inzwischen hängt dort ein 4g Modem mit Daten-Flatrate und VoIP-Telefon, was im Großen und Ganzen gut funktioniert.

Die nächste Aktion von A1 hatte ich aber nicht erwartet: In der Schlussabrechnung nach der Kündigung von Mitte Jänner war folgender Posten drinnen:

"Restgeld für vorzeittige Vertragsauflösung: 381 €

Und da 82-jährige manchmal nicht die besten E-Mail Leserinnen sind, ist das erst aufgefallen, als die Rechnung wirklich vom Konto eingezogen wurde.

Das “Restentgelt” macht in mehrerer Hinsicht keinen Sinn: der “A1 Kombi” Vertrag läuft seit mehr als 10 Jahren, und ich hatte bei der initialen Bestellung auch gefragt, ob irgendwelche Vertragsbindungen aktiv sind. Und das Ganze hat überhaupt erst angefangen, weil A1 die “A1 Kombi” einstellt, aber jetzt wollen sie uns genau dieses aufgelassene Produkt bis Ende 2025 weiterverrechnen.

Also ruf ich bei der A1 Hotline an, in der Annahme, dass man dieses Missverständnis schnell aufklären kann, wahrscheinlich hat einfach das Storno des Umstiegs den Startzeitpunkt des Vertrags im System neu gesetzt. So kann man sich täuschen:

  • Per Telefon geht bei ex-Kunden rein gar nichts mehr. Der Typ an der Hotline hat komplett verweigert, sich die Rechnung auch nur anzusehen.
  • Man muss den Rechnungseinspruch schriftlich einbringen. Auf die Frage nach der richtigen E-Mail-Adresse dafür war die Antwort “Das geht nur über den Chatbot.”
  • Also sagte ich der “Kara” so lange, dass mir ihre Antworten nicht weiterhelfen, bis ich einen Menschen dranbekomme, dem ich dann per Upload den schriftlichen Einspruch übermittle.
  • Nach Rückfrage bei der RTR-Schlichtungsstelle haben wir den Einspruch auch noch schriftlich per Einschreiben geschickt.

Wir haben hier ein Problem.

Ein Konzern zieht einer Pensionistin 400+ EUR vom Konto ein, weil sie einen Fehler in ihrer Verrechnung haben, und verweigern am Telefon komplett, sich das auch nur anzusehen. Laut RTR haben sie 4 Wochen Zeit, auf die schriftliche Beschwerde zu reagieren.

Ja, wir könnten bei der Bank den Einzug Rückabwickeln lassen, aber da ist dann A1 (laut Bank) schnell beim KSV und die Scherereien wollen wir auch nicht. Sammelklagen gibt es in Österreich nicht wirklich. Ratet mal, wer da dagegen Lobbying macht. Schadenersatz für solche Fehler? Fehlanzeige.

So sehr das US Recht oft idiotisch ist, die Drohung von hohen “punitive damages” geht mir wirklich ab. Wo ist die Feedbackschleife, dass die großen Firmen nicht komplett zur Service-Wüste werden?

Wenn ich aus Versehen bei einer Garderobe den falschen Mantel mitnehme, und dem echten Eigentümer, der mich darauf anspricht nur ein “red mit meinem chatbot oder schick mir einen Brief, in 4 Wochen kriegst du einen Antwort” entgegne, dann werde ich ein Problem mit dem Strafrecht bekommen.

Wie lösen wir sowas in Österreich? Man spielt das über sein Netzwerk. Mal sehen, wie lange es nach diesem Blogpost (plus Verteilung des Links an die richtigen Leute) braucht, bis jemand an der richtigen Stelle sagt “das kann’s echt nicht sein, liebe Kollegen, fixt das jetzt.”.

Update 2024-02-09: Eine kleine Eskalation über den A1 Pressesprecher hat geholfen. Die 1000+ Kontakte auf LinkedIn sind dann doch zu was gut.

Update 2024-04-05: Schau ich doch mal kurz auf die A1 Homepage, und was seh ich?

Gerichtsbeschluss

Anscheinend war des dem VKI auch zu bunt, wie unseriös die A1 mit Bandbreiten geworben hat.

Categories
CERT

A classification of CTI Data feeds

(Crossposted on the CERT.at blog.)

I was recently involved in discussions about the procurement of Cyber Threat Intelligence (CTI) feeds. This lead to discussions on the nature of CTI and what to do with it. Here is how I see this topic.

One way to structure and classify CTI feeds is to look at the abstraction level at which they operate. As Wikipedia puts it: 

  • Tactical: Typically used to help identify threat actors (TAs). Indicators of compromise (such as IP addresses, Internet domains or hashes) are used and the analysis of tactics, techniques and procedures (TTP) used by cybercriminals is beginning to be deepened. Insights generated at the tactical level will help security teams predict upcoming attacks and identify them at the earliest possible stages.
  • Operational: This is the most technical level of threat intelligence. It shares hard and specific details about attacks, motivation, threat actor capabilities, and individual campaigns. Insights provided by threat intelligence experts at this level include the nature, intent, and timing of emerging threats. This type of information is more difficult to obtain and is most often collected through deep, obscure web forums that internal teams cannot access. Security and attack response teams are the ones that use this type of operational intelligence.
  • Strategic: Usually tailored to non-technical audiences, intelligence on general risks associated with cyberthreats. The goal is to deliver, in the form of white papers and reports, a detailed analysis of current and projected future risks to the business, as well as the potential consequences of threats to help leaders prioritize their responses.
Continue reading “A classification of CTI Data feeds”
Categories
CERT Internet

Boeing vs. Microsoft

2019: Boeing uses a single “angle of attack” sensor to control the automatic pitch control software (MCAS). A software upgrade to use both AOA sensors was sold as an optional extra. Result: two planes crashed, killing 346 people. The damages and the subsequent grounding of the whole 373 Max fleet cost Boeing a few billion dollars.

2023: Microsoft sold access to advanced logs in their MS-365 service as an add-on, premium product. Luckily, someone did buy it, and used the data provided to detect a significant intrusion in the whole Azure infrastructure.

For good or bad, we do not treat security as seriously as safety.

Yet.

I think this will change for critical infrastructure.

Microsoft should think hard what that would mean. If one can ground a fleet of planes for safety reasons, I see no fundamental reason not to temporarily shut down a cloud service until it can prove that it solved a design flaw.

We just need a regulatory authority with a bit more desire to be taken seriously.

Categories
CERT

A network of SOCs?

Preface

I wrote most of this text quickly in January 2021 when the European Commission asked me to apply my lessons learned from the CSIRTs Network to a potential European Network of SOCs. During 2022, the plans for SOC collaboration have been toned down a bit, the DIGITAL Europe funding scheme proposes multiple platforms where SOCs can work together. In 2023, the newly proposed “Cyber Solidarity Act” builds upon this and codifies the concept of a “national SOC” and “cross-border SOC platforms” into an EU regulation.

At the CSIRTs Network Meeting in Stockholm in June 2023 I gave a presentation on  the strenghts and flaws in the CSoA approach. A position paper / blog-post on that is in the works.

The original text (with minor edits) starts below.

Continue reading “A network of SOCs?”
Categories
Austria Politics

Ein paar Thesen zu aktuellen Gesetzesentwürfen

(Diesen Blogpost habe ich 2017 für den CERT.at Blog geschrieben. Das hier ist quasi eine Sicherheitskopie.)

Das Thema “LE going dark in the age of encrytion” kocht mal wieder hoch, und noch schnell vor den Neuwahlen wurden entsprechende Gesetzesentwürfe eingebracht. Ich will hier aus technischer Sicht ein paar Argumente in die Diskussion einwerfen, beschränke mich hier aber rein auf den Aspekt Überwachung trotz Verschlüsselung. Die anderen Punkte (Registrierung und Zugriff auf Kameras, Zugriff auf Daten der ISPs, …) sind zwar auch interessant, treffen aber nicht so sehr in das Kerngeschäft von CERTs, ich werde sie daher nicht mit dem CERT.at Hut kommentieren.

Continue reading “Ein paar Thesen zu aktuellen Gesetzesentwürfen”
Categories
Internet

Mastodon

I’m getting a lot of Usenet deja-vues when looking at the Mastodon architecture. A collection of servers that create a shared space for communication.

I like it. It should be this way: independent of a single operator.

But it’s hard to pull off the scaling and the abuse management. The Usenet Death Penalty (UDP) seems to have been built in and actually being used to keep misbehaving servers from ruining the experience for everybody.

Anyway, I’m otmar@infosec.exchange, let’s see if this link works as validation.

Categories
Austria Politics

#define gerechte Pensionen

Weil mal wieder der Generationenvertrag in Sachen Pensionen im Gespräch ist, und Alt gegen Jung diskutiert, will ich hier mal einen Gedanken einwerfen, der zu oft ignoriert wird.

Wir haben ein Umlagesystem bei den Pensionen: die jetzt Arbeitenden zahlen die Pensionen der vorigen Generation in der Erwartung, dass dann ihre Kinder und Enkel das Gleiche für sie machen werden. Alles gut und sinnvoll, aber was genau meinen wir eigentlich mit “das Gleiche machen”?

Durch die demoskopischen Entwicklungen und die Änderungen in der Lebenserwartung sind die Randbedingungen nicht konstant geblieben, die Frage hat daher keine triviale Antwort. Ich sehe grob zwei Ansätze, wobei ich bewusst nicht behaupte, dass der eine wahrer ist als der andere.

Der anspruchsbasierte Ansatz

Nach x Jahren Arbeit / ab dem y. Lebensjahr hat man einen Anspruch auf eine Pension in der Höhe von f(Arbeitseinkommen). Wenn die Generation, die jetzt in Pension ist, das für ihre Vorgänger ermöglicht hat, dann ist es nur fair, wenn auch sie zu den gleichen Konditionen in Pension gehen können. Ja, an ein paar der Parameter wurde in den letzten Jahren leicht gedreht, etwa der Funktion, die aus dem Einkommen über die Berufsjahre die Pensionshöhe ermittelt, aber der Ansatz blieb der gleiche: man hat sich eine Pension in einer gewissen Höhe verdient, und die haben die Kinder und der Staat zu garantieren. “Ist ja fair, wir haben das gleiche für unsere Vorfahren gemacht.”

Der kostenbasierte Ansatz

Wir können aber auch andersherum rechnen: die jetzigen Pensionisten mussten während ihres Arbeitslebens für die Unterstützung ihrer Eltern/Großeltern einen gewissen Teil ihres Einkommens abgeben. Teils direkt per SV-Abgaben auf ihr Einkommen, teils per Arbeitsgeberbeiträge auf ihren Lohn aber auch über Zuschüsse aus dem regulärem Staatsbudget. Das könnte man sicher aus historischen Statistik- und Budgetdaten für jedes Nachkriegsjahr ausheben. Der genaue Prozentwert spielt hier keine Rolle, aber ich bin mir sehr sicher, dass er über die Jahre hinweg gestiegen ist, weil die Bevölkerung nicht mehr so stark wächst (was das Ganze in Richtung Ponzi-Schema gerückt hat) und die Lebenserwartung viel stärker gestiegen ist als das Pensionseintrittsalter. Man kann gut argumentieren, dass das nicht fair ist. Warum sollen heutigen Arbeitenden mehr ihrer Wirtschaftsleistung an die Pensionisten abgeben, als was diese früher für ihre Vorgänger abgegeben haben?

Aus einer rein rationalen Sicht sind beide Ansätze gleich richtig. Beide sind in sich konsistent und logisch. Der Mathematiker und Informatiker in mir sagt: wenn man bei einer Optimierungsaufgabe die Zielfunktion nicht klar definiert (hier “Was ist gerecht?”), dann kann man nicht objektiv die beste Lösung suchen. Das geht mir bei der aktuellen Debatte ab. Die Anerkennung, dass es mehr als einen Blickwinkel auf das Thema gibt, und dass man daher einen politischen Kompromiss suchen wird müssen.

Aber in einem Bereich bin ich ganz hart für den kostenbasierten Ansatz: Angeblich sind die Politikerpensionen in Italien komplett aus dem Ruder gelaufen, weil schon kurze Karrieren dort großen Pensionsansprüche triggern. Hier wäre ein hartes “Aber in Summe kriegen sie nicht mehr als x% vom BIP.” hilfreich.  

Categories
Austria Internet Politics

ID Austria und der Bundestrojaner

[2022-08-16: ein paar Klarstellungen hinzugefügt.]

Letztens hat wer auf Twitter geschrieben, dass es doch sein könnte, dass in die für ID Austria vorgesehene Smartphone App (“Digitales Amt”) ein Bundestrojaner eingebaut ist. Ich halte das für ausgesprochen unwahrscheinlich, die Argumente dahinter (neben den trivialen “das schaffen sie nicht” und “das wäre illegal”) eignen sich aber nicht für Twitter, daher dieser Blogpost.

Auf die Frage, warum SMS nicht mehr sicher genug ist, und warum eine App am Smartphone als zweiten Faktor die Lösung sein soll, will ich hier nicht eingehen. Das ist ein anderes Thema, und ist in der Form auch gar nicht mehr wahr, da auch FIDO Tokens (Level 2) unterstützt werden. Auch das Thema Datenschutz will ich hier nicht ansprechen.

Continue reading “ID Austria und der Bundestrojaner”
Categories
System Administration

Parsing the EU Digital COVID Certificate

I recently go my first Covid-19 shot, and shortly after that I received my QR code that is supposed to prove to anybody that I’m vaccinated.

Of course, I was interested in the actual technical implementation of the thing so I started tinkering around. Initially, I wasn’t sure whether the QR code just links to a webpage or is a standalone document, but reading the documentation quickly made clear that it simply contains a signed document.

There is a python snippet floating around that does all the decoding (decode base45, decompress, decode cbor, ignore signature, cbor decode), but I was wondering whether I can just use standard Linux command-line tools to do the same.

To my big surprise, I could not find a simple base45 decoder to be used on the command line. Neither the GNU coreutils (which supports a bunch of encodings) or basez have implemented base45 yet. For a quick coding exercise, getting code into the coreutils was a bit too ambitious, so I rolled my own in a few minutes. I haven’t done coding in C for quite some time, so this was fun. (while probably not necessary, this should be doable as a one-liner in Perl)

Next step: The libz decompression. Here, too, I was surprised that my Debian box did not have a simple program ready to do it. After some googling, I found that
zlib-flate -uncompress
does the trick. zlib-flate is included in the qpdf package.

Update: The debian package zlib1g-dev contains a few example programs, zpipe.c does exactly what I need. Just copy the file from /usr/share/doc/zlib1g-dev/examples/ , compile with “cc -o zpipe zpipe.c -lz”.

Then cbor: at first this looked easy, there is a libcbor0 in Debian and appropriate modules for Perl and Python. But a command-line tool? That’s not included by default.

Initially, I tried using
python3 -m cbor2.tool
and then continue with jq to select the right element (jq ‘.”CBORTag:18″[2]’ seems to do the trick) but I ran into encoding issues: I did not manage to extract the element in binary form, I always had escape sequences like ‘\x04’ or ‘\u0012’ in there which are not suitable for next step of cbor decoding.

Update: I’ve now read a bit more about the cbor standard and on the things it can do that JSON can’t, is handling raw binary data. JSON knows strings, yes, but they are character strings encoded in utf-8, not sequences of octets. Back in the old days of latin1 that might not have mattered that much, but these days you really shouldn’t mix those two.

So this is still work in progress, watch this space for updates.

Updates:

  • I’m not the only one who tried this, see also this blogpost by Corentin Dupont.
  • Based on troubles with faked certificates, I had a closer look at the key distribtion and updates of the Austrian green pass system. I documented the results in a blogpost at CERT.at.