Since I am an American citizen now, I have to think about what kind of work I am going to do during retirement. Lately, I have been musing about moving back to Holland for a year and working for the government. Back in the days, I miraculously escaped military service, so I feel that I still owe my people a year of service…
As part of my preparation for that eventuality, I regularly join a webinar called “Werken voor Nederland” (meaning: Working for the Netherlands), where various branches of the government recruit for roles in their information technology departments. These webinars are facilitated by an associate of mine, so even if I am not particularly interested in the roles advertised, I still join. Also, I have nothing better to do on Monday morning at 6am Pacific Time.
By the way, I love the English word “associate”, as it can literally mean anything, ranging from “we were blood brothers in the same prison block for years” to “I just met them in the parking lot and we connected on LinkedIn.”
Of specialist interest to me are roles in the Dutch government’s cybersecurity activities, seeing as my most recent work experience is in infrastructure security at OpenAI. However, after participating in a few of these webinars, I am very doubtful that I would qualify for a role there, because apparently, security is no longer a technical endeavor.
One of my other reasons for joining these webinars is to write semi-snarky responses in the webinar’s chat channel, like: “.NET is not a programming language” (in reply to a thread in which someone asked which programming languages were used by a particular department and where someone answered: “Java and .NET”.
I have dabbled in security all my life. In my first role, as an MVS Systems Programmer at a large bank, my focus areas were system performance and security. Among other things, part of my responsibility was the system’s security configuration and the implementation of associated software, like IBM’s Resource Access Control Facility (a.k.a. RACF).
Obviously, this was at a time before security had been invented and things were still kinda loose. For instance, we had added a supervisor call to the system that would flip the APF-bit of the calling task. I know this does not sound very problematic, but believe me, it is. IBM’s manuals have this to say about the “Authorized Program Facility” (APF):
“An authorized program can do virtually anything that it wants. It is essentially an extension of the operating system. It can put itself into supervisor state or a system key. It can modify system control blocks. It can execute privileged instructions (while in supervisor state). It can turn off logging to cover its tracks. Clearly, this authorization must be given out sparingly and monitored carefully.”
Our main security control for this supervisor call was obscurity.
I later worked for another bank that had created a similar supervisor call, but in their implementation they checked if the caller came from a protected program space called the Link Pack Area (LPA). To convince them this was not very secure, I wrote an exploit that would call into the LPA using some well-chosen register values to call the SVC to set the APF-bit and then return control to my exploit.
Over time, I kept up my security skills, though to be honest, mostly to hack into customer systems, so that I could bypass incompetent system administrators and cumbersome local procedures. At yet another bank, I had convinced everyone to give me a “read-only” userid so that I could help debug system problems. One setuid shell script later I was root everywhere, a power I used to the benefit of my project to fix bugs in the production setup without having to go through another round of change management, where absolute nincompoops fretted about the impact of creating a new directory (true story).
Later, the bank outsourced their IT operation to a major international IT service provider. When that provider’s people came to our offices to get to know us, I introduced myself as follows: “My name is Jos Visser and I run black ops for Danny” (the SVP in charge of our area). Everybody laughed heartily. One month later, their account manager came to see our tech lead and asked: “When Jos said that was running black ops for Danny, he wasn’t joking, was he?” Nope, he was not… 🙂
When I joined Big Tech, I stopped paying much attention to security because they have professional security outfits that expertly took care of everything, plus their security setup and measures were smart, so there was no need for me to circumvent them in order to get my job done. At the same time, the Internet became pervasive, and with that, the attack surface grew to an almost immeasurable size. Additionally, the threat actor community multiplied like rabbits.
One thing that sadly did not grow was our technical competence.
In the early 2000s, a friend of mine had a web site developed for her new business (a porn site, if you must know), and when asked to “check it out”, it literally took me two minutes to find a SQL injection in the login screen. Our entire industry is still not doing much better. For a number of reasons I am going to leave undiscussed for the moment, we are developing security bugs at a never before seen rate.
Fortunately, this is top of mind for a lot of people and an entire industry has sprung up to help address this problem. Unfortunately, this industry is mostly not helping to solve this problem at the root, but are instead focusing on perceptions. There is almost no support for the process of developing secure software, but there is a jungle of software and services to help manage the problem of running insecure software. Making a probably bad analogy: It is like we are living in a world where every car we get into can spontaneously combust and we have a car industry that focuses on selling fire extinguishers, smoke detectors, and burn salves. Plus, when we buy the car, we sign away any liability for the vendor.
This sorry state of affairs is driving a feeling that security is impossible to solve and this brought forth an industry that is addressing that feeling.
At a conference last year I ran into an associate that I hadn’t seen for a while but who I know to be deeply technical and a hacker of formidable skill. When I asked them what they were doing these days, they answered that they were consulting with a bunch of city governments on implementing ISO/IEC 27001, a global standard for Information Security Management Systems. Right there I knew for certain that we were all up shit creek, without a paddle.
Organizations that are faced with a seemingly intractable problem of course want to know that they are doing the right thing and have not forgotten something crucial. This calls for a checklist and when there are enough customers for a checklist, a checklist industry will fill the gap. This is what is happening in security. Organizations have no choice but to run software that they know to be buggy and since they can by and large not buy better software, they find their comfort in formal systems that certify that they have done all the other things right. “Yes, we just got hacked, but we have an ISO/IEC 27001 certificate, so there is nothing we could have done better.”
The search for checklist compliance has led to the entry of many deeply non-technical people into the field. This is not a new phenomenon; at one of the banks I talked about before, I had helpfully made a list of all their websites together with the expiration dates of the SSL certificates used on these sites (an anecdote I have written about more extensively here). In response, their security department started an investigation to figure out where I had obtained this information, convinced as they were that I had hacked into some internal systems. Really folks, if any people in your security team do not even understand the most rudimentary aspects of public key encryption and SSL, your customers’ data is not in great hands.
I saw this on full display at editions of the aforementioned webinars “Working for the Netherlands” that were focused on finding people for security related roles. The number one question there was if you needed to be “technical” for any of these roles. Whenever this question popped up, the speakers tripped over themselves to explain that “No, you don’t need to be technical”, often augmented with the comforting statement that they themselves had majored in ancient Germanic runes or something like that during college and now they were a cyber security threat specialist for the government, so hey, who needs to understand anything about computers at all when working in crucial cyber security roles?
Instead of selling technical solutions that address the root of the problem, most companies in the cyber security space are selling you a feeling and many people working in the field feel that you don’t have to understand computers at all when working in security. But, to say it with my American home town’s signature band: Security is more than a feeling.
