Image from Pixabay |
Last Tuesday, accompanied by a bright autumn sun, I
walked with a teammate through the Dinosaurs department of the zoo in
Amersfoort. Crazy, isn't it, that a zoo, which generally collects living
creatures, has also furnished a piece of forest with statues of long-extinct
animals. Just as crazy as the presence of a playground, by the way. Did you
come to watch animals or to seesaw?
If you think our presence there, during working hours, is
even stranger, then you have to consider that zoos also have spaces that they
rent out for gatherings. And so that afternoon we had a meeting of our
organizational unit, the CTO Office, responsible for the optimal and effective
use of technology throughout the organization. After a clear talk from our
director (the chief technology officer,
or CTO) we had to split up into groups to talk about a certain theme. You know the
drill: the groups are composed in advance in such a way that you do not sit
together with your own teammates, so that you also come into contact with other
people. I was, however, in a group of which I already knew two IT architects;
one through work, the other through a chat at the coffee machine. The others, a
license manager and a contract manager, I knew by sight.
The theme to be discussed te was called: fast, better,
safer. Technology must be made quickly available to our employees. Apparently
the quality can also be improved a bit and well, the realization that it has to
be safer has fortunately also penetrated the higher echelons. In many
organizations this means little more than comfortably abstractly shouting that everything
must become safer, leaving the workplace behind in a despairing "Yes, but how?"
Because the gap between the acknowledgment that it has to be safer and the
practical implementation of such an ukaze soon has canyonesque dimensions.
Welcome to the field of tension between 'that is not allowed' and 'but
otherwise it won't work'.
The fact that they put us to work with this theme shows
both guts and the need to actually give substance to it. The first thing we
wrote down was that you should not only be fast, better and safer, but also
flexible. That is, as it were, the catalyst that lends a helping hand to the
other three properties. Flexible in combination with safer means that you do
not strive for maximum security, but for optimal security. That also means that
you can be more flexible in certain situations – I am thinking of test
environments, for example. However, security policies and standards do not
provide for this; such documents seem to be blind to the complex environment of
a large ICT organization.
This brings us to risk appetite. How much risk is an
organization willing to take? A company that produces things with a short time
to market will generally have a greater appetite for risk than, say, a
government agency. After all, that product has to arrive in the shops quickly
and then you can't afford an overly frivolous security overhead. Just look at
smart devices such as baby monitors, security cameras and toasters, which turn the
Internet of Things into a dangerous
mess.
Our conclusion was that we need to differentiate between
the risks we face. An inextricable part of this is the unambiguous
determination of who is responsible for what. One of the architects wanted to
keep that responsibility as low in the organization as possible. I was able to
convince him that it should at least lie at the level of a department head,
because otherwise self-interest might weigh too heavily: if a team has to
achieve a goal, a team manager will generally accept risks more easily.
However, risks tend to have a broader impact than one team and must therefore
also be weighed in that broader context. Some distance from the work floor
helps with this.
Yesterday I spoke to a department head who often deals
with risk treatment. We have set up a process that regulates that when someone
wants something that is not allowed according to the rules, but is (at that
time) necessary to ensure progress, they must write down what that means and
what risk the organization runs. And that form must be submitted to the head of
department. Because things have been getting out of hand lately, he is actively
engaging with his peers to bring about change. In many cases, taking those
risks is not really necessary, provided that some effort is made to work on a
robust solution. This head of department clearly takes responsibility for
security, while not losing sight of the importance of the operation. Because
security is also about availability.
Another zoo group, which was also discussing of the
'fast, better, safer' theme, had written down: read the Security (b)log! That
is of course a great always-good action.
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.
- Arjen Lubach explains what ransomware is. [DUTCH]
- the recently discovered bugs in OpenSSL are not as bad as previously feared.
- TikTok staff in China and other non-European countries can access data of European users.
- Dropbox
has been hacked via phishing. [DUTCH]
- a
data breach can also simply be done on paper.
[DUTCH]
- the Russians allegedly hacked into the phone of the previous British Prime Minister.
- US government wants to take action against disinformation on social media.
- the Red Cross wants a digital emblem to protect the IT of the organization in war situations.
- Austria
has put a stop to a European Commission plan to monitor all European chat
messages. [DUTCH]
- this
company made a lot of money by applying dark
patterns. [DUTCH]
- rogue
PyPI packages steal your login details.
[DUTCH]
- the US government advises on multi-factor authentication that cannot be circumvented through phishing.
- Strava
's
privacy zone is not watertight. [DUTCH]
No comments:
Post a Comment