Ouch!

 

Image from Pixabay

Snap. The sound of a withered twig giving way under the footsteps of a forest walker. Only this time it wasn’t in the forest. And it certainly wasn’t a twig.

We’ve lived in this house for exactly ten years now, and the bed has been in the same spot for just as long. But when I walked into the bedroom recently, the bed must have taken a step forward. Snap. The leg of the bed showed no damage. That could only mean one thing: the sound came from my little toe. Most accidents happen in a small corner, we say here. Or in a small toe, I now know. Oh well, that bone will grow back together. (But it’s annoying.)

A day later, Maarten van Rossem, the always cheerfully grumbling Dutch tv personality, had an unfortunate fall. The historian had tripped over a curb in Utrecht, right in front of the building that served as the headquarters of the fascist National Socialist Movement during the war and which now houses a childcare centre. He was lost in historical and ironic reflections on the fate of the building. Consequences: a black and blue face and a hurt knee. So I was in good company that week, in terms of being a victim of one’s own carelessness.

Shouldn't we have been more careful? Absolutely! But one does a lot of things on autopilot. As I said, nothing has changed in the layout of our bedroom for ten years. And that curb has probably been there for a long time too. You can blindly walk a route like these a thousand times without any accidents. And on that one day you put your foot down just a little differently. There’s no footage, I can't analyze it. But there was a deviation, that's for sure.

I once heard someone say: walking is like fall in a controlled way. You lean slightly forward and prevent a fall by putting one leg forward. Seen in this light, walking is a rather clumsy activity for bipeds. Does it surprise you that we sometimes take a misstep? No doubt, thick books have been written about this that may or may not be worth reading, but this is not a blog about kinematics, so I will leave this subject alone for now.

In presentations I have sometimes made my audience think about the way they cross a road. If you see a car approaching, you make an assessment of whether you can still cross. You base this on the distance to the car and on its and your speed. If you give yourself a green light, you start walking. But now we are going to do this risk analysis again – because that is what it is – but in more detail. You not only consider distance and speed, but you also take into account the possibility that you stumble. Does the driver have enough time to brake? Can he see you at all, or is he hindered by darkness or the low sun? Or is he perhaps fiddling with his phone while driving?

If you include those factors in your analysis, you will probably increase the minimum distance that the car must have at a certain speed, in order to be able to cross the road in confidence. But who does something like that? I can tell you: people who have just had an accident. Because they have personally experienced how things can go wrong and what the consequences are. And after a while, that increased vigilance wanes again, and with that the chance of accidents increases again.

In information security, it is no different. If nothing ever happens, attention lapses. And then it becomes easier for malicious actors – our standard term for anyone who deliberately wants to do something with our systems and data that we do not agree with – to do their thing. Practicing helps against lapses in attention. Developing scenarios also helps. You have a certain interest that you want to protect and you try to think of how a malicious actor would carry out an attack on it. This can lead to surprising insights and solutions.

My bed was not malicious. Bad (!) luck, most people would say. For the time being, I walk past it with increased respect. I also put my feet down much more consciously in other places. That takes quite a bit of energy. Actually, I am already looking forward to my attention slackening a bit. Although I sincerely hope the bed will stay where it is.

 

And in the big bad world…

• AI surprisingly often misses the mark.
• the US government no longer considers Russia a cyber threat.
• Your Pokémon Go location data may be flowing to Saudi Arabia.
• Twitter/X poses a threat to countries outside the US according to this Australian article.
• The new Dutch government workstations only store metadata in the cloud. [DUTCH]
• Apple is protesting the British backdoor.
• Signal’s CEO warns of AI agents.
• Apple seems to have implemented a good idea in a messy way.
• Many Chromecasts have an expired certificate, which means the device will no longer work.
• Instagram's teenage accounts offer only a false sense of security. [DUTCH]

 

Playing with toilet paper

 

Image from Pixabay

If you are eating right now and have a bit of a delicate soul, you better save this blog for after dinner. It has an, uh, sanitary approach. I try to keep it as neat as possible.

About five years ago, Dutch comedian Kasper van der Laan appeared on a couple of tv shows. He made an interesting suggestion there to save toilet paper. When you wipe your bottom, you continue until you see a clean piece of paper, that's how his argument begins. But, according to Van der Laan, then your buttocks were already clean. You could have stopped one wiping round earlier. The big question now is: do you dare to gamble on it? Like, “I think I’m done here,” in the comedian's words. Do you remember the sudden, unfounded fear that toilet paper would run out during the covid pandemic? Perhaps there were more people then who put Van der Laan's thought experiment into practice.

Using toilet paper is – if I'm being a bit broad – a kind of security measure. It protects you from skid marks, skin irritation and unpleasant odors. This immediately raises the question of how other animal species deal with this, especially with the second risk (the first does not apply and they will not have to deal with the third as much). But come on, let me not digress. What Van der Laan did here was a genuine risk analysis. And in view of the summer holidays, in which many people have to go to a camping toilet, whether pleasant or not, with a roll of toilet paper under their arm, and others will encounter hotel paper in various qualities, it is urgent to work this out in more detail.

The basic formula for risk analyses is: risk = likelihood × impact. In this toilet case we play with likelihood: if you keep going until you produce a clean piece of paper, the likelihood of skid marks is practically zero. If you put the idea described above into practice, the likelihood will always be greater than zero. But how much greater? That's difficult to determine, because you have to deal with another variable: the, er, output. If it were always of the same quality, you would know after a few swipes: after so many swipes it's done, so I can switch to that many swipes minus one. But we all know that our biological output can vary over time. For example, because of what you have eaten, because of a different climate or because you are ill or nervous. The chance of an incorrect assessment, and therefore also the chance that the risk will become reality, is variable.

Estimating the probability of an event which damages information security is in itself difficult. We usually do a qualitative risk analysis, which means we use terms such as low, medium and high. The counterpart is quantitative risk analysis, which involves calculating with numbers - for example with statistical data for the likelihood and with amounts for the damage. In all these analyses, the probability is not a fixed factor, nor is it in the sanitary example. However, most of the time we pretend that this is the case. And I don't think that should be a problem with quantitative analyses, because the necessary margin is already built into the terms used such as high and low.

However, if you are in a situation where the odds can go either way, you will have to assume worst case. This may mean that the measures you take to deal with the risk are 'too good' some of the time. After all, we do not strive for maximum, but for optimal security – not too little, but also not too much. If you are allowed to drive 30 km/h somewhere because of road works, that is fine, but if no one is working at that moment, that measure feels unnecessarily strict.

What to do? Do you tailor your measures to what the average is? Then you run the risk that the measures are too weak at times. How bad that is depends on the impact it may have. If the expected impact is acceptable, then you can do with a bit less. But if that temporary speed limit is not only there to protect road workers, but also because there is a large hole in the road, things are different.

In Japan they have toilets that make toilet paper redundant. You will be sprayed clean and blown dry from within the bowl. And sometimes you can even play a sound via the control panel to disguise certain typical bathroom sounds. They have taken all risks into account and implemented smart measures.

The Security (b)log will return after the summer holidays.

And in the big bad world...

• There is currently (Friday) a worldwide computer outage due to an incorrect update from a security company.
• there are also problems in the Microsoft cloud.
• it is a bad idea to connect a traffic light to the internet without security.
• The Trump shooter's phone was cracked within 40 minutes.
• we now know which phones Cellebrite can crack.
• the US Postal Service shared their customers' addresses with advertising and tech companies.
• the Dutch Data Protection Authority foresees a rat race around artificial intelligence. [DUTCH]
• a mistake of € 29,000 to your disadvantage will be corrected. [DUTCH]
• you also need to have your security in order if your name is Hackney (which, to Dutch people, sounds a bit like “don’t hack”).
• many Dutch government domains are still insufficiently secure. [DUTCH]

 

RITA

 

Image from Pixabay

Recently, RITA came into my life. She just fluttered in during a risk analysis, and I listened with fascination to what a colleague had to say about her (thank you Henk!). Later I Googled her and was impressed by her engaging personality. Her image is a bit less flattering, but I still prefer to judge RITA on her character rather than her appearance.

RITA is an acronym that stands for Reliable Internetwork Troubleshooting Agent. It's an April Fool's joke from 1998, presented as an RFC. That abbreviation stands for Request for Comments. An RFC is literally a request to comment on something. That ‘something’ are protocols and other documents that describe the operation of the internet. Ultimately, an RFC becomes a standard, but strangely enough it’s still called an RFC.

RFC 2321 describes “usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today’s complex nondeterministic networks and environments”. The difficult word, which appears twice in the previous sentence, means that outcomes are variable even when the conditions are the same. I put aside the common assumption among laymen that computers always produce the same output in identical situations - especially with identical input - at the very beginning of my career. At the time, I was responsible for the COBOL software that took care of the nightly processing of income tax data. One evening an operator (hello Oscar!) called me because the processing had stalled. I told him to just restart the processing. Never heard anything about it again.

RITA is charmingly simple, and the way she makes her diagnosis is equally so. Moreover, the outcome is easy to understand because it is binary: it is right or wrong, there is no in between. RITA's primary area of use is hardware and software, but I think RITA can also be successfully used in countless other environments, even outside IT.

RITA is a rubber chicken with a length of 51.25 cm (20 3/16”) and its operation is very simple. You place it on the device to be analyzed or, in the case of software, on a still packaged copy of the software, or if necessary on a printout of the source code (that old COBOL software of mine was easily a decimetre (4”) thick). And here’s the punchline: if RITA flies away, then the object to be analyzed is error-free. If, on the other hand, RITA remains down, then something is wrong. You get the idea: rubber chickens don't fly – unless they're thrown, of course.

Moral of the story: hardware and software always contain errors, because they are incredibly complex. And, I always add, some of those errors have bad consequences for the security of the object, and possibly even for the security of the wider environment in which it is active (a hacked baby monitor is not only annoying because the hacker is in your home, but also because the device can be misused in a DDoS attack on an organization on the other side of the world).

In our risk analyses, we always ask how vulnerable a particular object is to errors in software, broken down into self-built and purchased software. Vulnerability is determined by the measures you have taken to address a threat. The application of the DTAP model is invariably mentioned as a measure: the development, testing, acceptance and finally running of the software in production takes place in separate environments, the intention being that an error will come to light in one of these phases. Attack & penetration testing is often used to determine whether an attacker can gain access to the object. And vulnerability scanning regularly checks whether a product contains known vulnerabilities. What remains after all this good work are the mistakes that have still been overlooked. And believe me: RITA will never take to the skies. The only question is who will discover a risky error first: a crook or an honest person.

 

And in the big bad world...

This section contains a selection of news articles I came across in the past week. Because the original version of this blog post is aimed at readers in the Netherlands, it contains some links to articles in Dutch. Where no language is indicated, the article is in English.

• Laxity is a factor that few take into account.
• Signal now protects your privacy even better.
• cloud computing is sucking in government. [DUTCH]
• This American newspaper article predicts a positive effect on the US of a ruling by the European Court of Human Rights.
• there is still something to be gained in the high ranks of the Luftwaffe in the field of security awareness. [DUTCH]
• the US government is leaning toward banning ransom payments.
• Ivanti 's problems keep the NSA busy.
• the NSA also gives tips about security in the cloud.
• the beer supply will not be in danger for the time being.
• the man in the middle takes off in your Tesla.
• sometimes the opponent is in your own organization.
• many Dutch passports are for sale on the dark web. [DUTCH]

 

 

Misjudged

 

On October 22, 1895, the train you see in the photo left Granville on the Normandy coast at a quarter to nine in the morning with destination Paris. As the crow flies, that is about three hundred kilometers (186 miles), which takes a modern train three and a half hours. At the time, the journey took an entire day.

At 3:55 p.m., the train rumbled into Paris, but it was several minutes late. The very experienced driver, Guillaume-Marie Pellerin , thought that he could partly make up for this delay by braking only at the last moment. But this time, the brakes failed and the train crashed through the buffer and glass facade of Paris-Montparnasse station, where it came to a stop, as the photo shows, in an unreal position. There was one fatality to regret. Marie Augustine Aguillard wasn't even a passenger on this train – no, she was minding her husband's kiosk at the Place de Rennes for a while; he had gone to get the evening papers. She was killed by falling debris.

The American George Westinghouse had invented a brake based on compressed air some twenty-five years earlier. The brake engages when the air lines are deflated and will not release until a compressor has repressurized the lines. Because each carriage has its own brake, the entire train is braked. That system seems inherently safe: if something breaks, the pressure drops and the brakes kick in. However, on this train the Westinghouse brake failed anyway, and the brakes of the locomotive alone could not stop the train in time.

Engineer Pellerin took a risk. Has he thought carefully about what could go wrong and what the consequences could be – precisely at this location, a terminus? His train's inherently safe brakes gave Pellerin enough confidence to brake a little later than usual. If he had looked just a little further, he might have thought that if the brakes failed, it could have disastrous consequences in this very spot.

Risk is often expressed with the simple formula Risk = Likelihood x Severity. We often do not calculate with numbers, but with estimates: small, medium, large – both left and right possibly flanked by 'very'. The formula shows that an event, which is unlikely to occur (Westinghouse brake failure), can nevertheless lead to a high risk, because the expected consequences are very serious (deaths and injuries). The limits of the risks you want to take are determined by your risk appetite. Adventurous people have a greater risk appetite than cautious people, and manufacturers of hip technology products take greater risks than a government organization, just to name a few extremes.

You yourself also perform risk analyses every day, for example when you cross the road. You make an assessment of whether you will make it before that car reaches you, and you mainly look at the distance and speed of the car, and how well you are on your feet. But do you also consider the possibility of tripping? Do you still have enough time to get away, or does the driver have sufficient reaction time and is his braking distance long enough? We usually don't think about such a scenario, probably because it usually goes well. And that was precisely Pellerin's problem. It cost him a fine of fifty francs and two months of suspended prison.

Do me a favor and take care crossing the street when you go out later.

There will be no Security (b)log next week.

 

And in the big bad world…

This section contains a selection of news articles I came across in the past week. Because the original version of this blog post is aimed at readers in the Netherlands, it contains some links to articles in Dutch. Where no language is indicated, the article is in English.

• the FBI hacked Russian state hackers.
• this security company is very open about an attack on their systems.
• the British plead for more transparency in cyber attacks.
• Rian van Rijbroek's husband seems to be quite confused himself.  [DUTCH]
• you should watch out for fake windows updates. 
• you should also watch out for malicious QR codes.
• the emergence of AI and the possibility of cloning on the fly may lead to additional legal protection for individuals.  [DUTCH]
• YouTube is experimenting with banning ad blockers.
• many Dutch people can protect themselves better than they do now.  [DUTCH]
• phishing is the main form of cybercrime that citizens have to deal with.  [DUTCH]

Bus drivers on strike

 

Image from Pixabay

Hilversum was the place where I had to go to last Monday. As befits a good civil servant, I prefer to travel by public transport. Regional transport was on strike this week, but the trains were running normally, it was emphatically stated. Nice. I shouldn't have been bothered by the strike. It turned out differently.

When I travel by train, I always take the city bus to the station. I am a man of definitions; For me, regional transport is transport between places and city buses run in the city – and therefore not in the region. But because I also understand that drivers who work for a carrier that serves both the region and the city are not exclusively city bus or regional bus drivers, I had my wife take me to the station a few weeks ago, when they also went on strike. That turned out not to be necessary: the city buses ran on schedule. My definitions were correct.

So they would also run last Monday, I assumed. At one point at the bus stop, a girl asked me: “Are you going to the station?” I glanced at my watch and replied, "I don't think so." She consoled me by telling me that line 231 would arrive in six minutes. However, that would be too late to catch my train, and moreover, line 231 is a regional bus…

I had to come up with an alternative. At the Mediapark in Hilversum, students of Make IT Work (a retraining program of the Amsterdam University of Applied Sciences) would soon expect me to give a guest lecture; I had to be on time. I calculated my options. I wouldn't make it to the station in time by bike; with the car I had another chance. With big, but careful steps – it was freezing – I returned home, texting my wife what my plan was, so that she wouldn't be shocked when the car suddenly disappeared. She was willing to drop me off too, but then I might have a problem on the way back. I got in and drove off. Traffic lights, that usually show me their red light, were favorable to me for once.

On the way, I pondered my parking options. There are two ways to go in the parking lot at the station: to the left and to the right. Turning left leads to the entrance of the station, turning right leads away from it. Turning right, the chance of a free space is therefore considerably greater – after all, everyone wants to be at the front. But if you park there, you have to walk further. If you turn left and you don't find a spot there, you still have to go to the other side and that means extra time loss. I took a gamble and turned left. My courage was rewarded: there was exactly one free spot, near the entrance. Moreover, it was a place that overlooked the busy road past the parking lot, which I liked very much, because a few decades ago my car was broken into in that parking lot and the radio was stolen (by the way, thanks to an attentive witness, the crooks were caught and I got my radio back). Satisfied, I walked into the station. I reached the platform at the same time as my train and I arrived at my destination in plenty of time. Incidentally, it would not have been disastrous if I had missed this train: My itinerary had a margin, the next train would also have delivered me on time.

It probably takes a fair amount of professional deformation to relate the above to my profession. Since I have quite a lot of that, my adventures from that morning became part of my lecture, its subject being risk analysis. If you look at the above account through that lens, then you realize that risk analyses are not limited to your work as an information security officer: they do not just take place if and when your agenda states that you have to do a risk analysis on that day and at that time and there will be not always a complicated, formal method. Risk analyses are carried out in daily life – usually unconsciously but it happens all the time. You do that too.

Let me explain. My initial decision to take the bus was based on historical data (during the previous strike the city buses did run), from which I deduced that the chances of a running bus were favorable. The decision not to take the bicycle, but the car, was based on the likelihood of catching my train in this way. The fact that I didn't run home but - despite my haste - just walked, had to do with the risk of slipping. Even the text to my wife was risk management driven. Left or right in the parking lot: OK, I admit, that was an irrational guess. But hey, I'm just a human who hopes for the occasional windfall. In risk analyses, the expected consequences of wrong choices also play a role, according to the old formula: Risk = Likelihood x Severity. With all the choices I made that morning, the possibility of missing my train hung over me like the sword of Damocles.

Think of me the next time you have to make decisions. Who knows, it might help you make well-founded choices.

 

And in the big bad world…

This section contains a selection of news articles I came across in the past week. Because the original version of this blog post is aimed at readers in the Netherlands, it contains some links to articles in Dutch. Where no language is indicated, the article is in English.

• no British or American citizen is allowed to do business with seven members of a Russian ransomware gang.
• there is something called a cybersecurity poverty line.
• quite a few bosses keep a digital eye on their employees. [DUTCH]
• dozens of ancient encrypted letters from Mary, Queen of Scots have been discovered and decrypted.
• Bluetooth vulnerabilities are popping up like mushrooms.
• suspicious links remain a tricky subject for the time being.
• the NIST has chosen an algorithm from Radboud University, among others, as the encryption standard for IoT devices.
• the eddit employee who reported being caught by a phish deserves a reward – for reporting it and preventing worse.
• job postings are used to distribute malware.
• unscrupulous criminals, of course, take advantage of other people's misery.
• the Dutch reported less cases of fraud last year. [DUTCH]
• the need to do principle principle also applies to police officers (you may only consult certain data if you need them for doing your job). [DUTCH]
• ransomware can also contain errors, of course. [DUTCH]
• this article explains once again how we are spied on by companies on websites and via e-mail.

 

That's how we do it

 

The Media Park in Hilversum is not an obvious work location for me. And yet I went to work there last Friday, on the eleventh anniversary of the Security (b)log. Despite the fact that the nation’s radio and tv stations call this place their home, no camera was involved, not even a microphone. I wasn’t there for them, but for a group of students of Make IT Work, a retraining program of the Amsterdam University of Applied Sciences.

The first sentence about this training on their website reads: “A Security Specialist is responsible for the operational aspects of information security.” And yet I was there to give a guest lecture on risk analysis. At first glance, that topic does not seem to fit with operational aspects, but when I was approached for this guest lecture and we discussed the topic, we came up with this anyway. Later, when discussing my concept, I got the suggestion to leave out certain somewhat more theoretical parts, “because these students are doers”. So I went to Hilversum with mixed feelings; I had a good story in my pocket, but would it also work with this group?

As you would expect in a retraining programme, the audience was of very diverse shapes. Someone who had worked in the offshore industry, and someone who had studied law but had never done anything with it, for example. But each and every one of them was on the edge of their seats, asking questions that made it clear that this topic was a bull's eye. In fact, I have rarely been in front of a group that was so interested and motivated. That makes me enthusiastic myself, and I seem to radiate that – it already gave us a new teammate a few years ago.

So my story was about risk analyses, but it started with the Baseline Information Security for Dutch government bodies (BIO). Because that document clearly states that all activities have to be risk driven. Even without that obligation, the organizational unit where I worked a few years ago, our data center, already realized that risk analyses are important and useful, and the board therefore decided that all services provided had to undergo a risk analysis. Such a decision is extremely important – now I don't have to knock on a team's door and ask if I can please come and do a risk analysis; instead, they ask me if I can come and help with this exercise. Management is not only responsible, but also in the lead. Nowadays I work for the CTO of our ICT organisation, the Chief Technology Officer. But our work on risk analyses has remained the same.

Back to my students. It was inevitable that I first threw some theory about the BIO and the risk analysis at them, but then we dived into practice: we actually did a bit of risk analysis, just like I would do in the office. One of their teachers had told me that the group was excited about the 2011 DigiNotar debacle (in short: DigiNotar was a digital certificate authority, was hacked and kept it silent; read more on Wikipedia). The subject of our risk analysis therefore was: certificate management. We covered some threats from the risk analysis list and discussed them as if the students were responsible for certificate management. It provided them with some nice eye-openers, but above all insight into what a risk analysis actually entails.

The organization had scheduled two hours for my guest lecture. When I asked just before the end if I was free to overrun my time, they replied with eagerly nodding heads. I ended up standing there for over three hours. Afterwards, the students told me what made my story unique: I was the first guest teacher to tell and show how we do our work in real life. I recalled the comment that these students are doers. I had interpreted that as a kind of level indication, but now I know that these people have much more to offer than carrying out operational tasks. 'Doers' here also means: people who know how to tackle complex matters with the help of the right tools. Exactly what a university of applied sciences stands for.

 

And in the big bad world…

This section contains a selection of news articles I came across in the past week. Because the original version of this blog post is aimed at readers in the Netherlands, it contains some links to articles in Dutch. Where no language is indicated, the article is in English.

• the police, together with the business community, are fighting against the misuse of login data. [DUTCH]
• A ransomware attack on a meal service may lead to hunger among the elderly. [DUTCH]
• ARTIS zoo has also been hit by ransomware. [DUTCH]
• advanced new malware atttacks routers in Europe and North America.
• the intelligence services experience the Assessment Committee Deployment of Powers as a nuisance. [DUTCH]
• a data company illegally collected medical records for years. [DUTCH]
• More sectors will soon have to make mandatory reporting of cyber incidents. [DUTCH]
• organizations need to deal better with open source components. [DUTCH]
• Using US cloud services does not automatically constitute a privacy violation. [DUTCH]
• one fifth of the tested SME employees fell for a phishing email. [DUTCH]
• many people still use the same password in multiple places.
• Food items are thrown into the fray to find out if packages have been opened en route. [DUTCH]