Kennie on security - Part 1 (my background)

This post is the first in a series about security. You might ask why I care about this topic and why block about it now? Well, I have my reasons and on the top of my head they look like this:

1. My first full time job was in IT security, so my professional mind has always been influenced by this.
2. Microsoft is currently doing a huge investment in security with a programme called Secure Future Initiative (SFI).
3. Next month in October 2024, I'm doing a session on security at the NA Summit conference. Blogging helps me organize my thoughts on that.

?

In this post, I will tell you about my background in security and how my first job formed me professionally in this area.

?

Neupart and Munkedal/VIGILANTe (2000 until 2002)

It was a cold winter in 2000, and I was finishing up my master thesis in mathematics on a topic as esoteric as “Spin geometry and the positive mass theorem in general relativity” (sounds cool, right?) At that point I knew that I was not going to pursue an academic career in mathematics and that I wanted to try to get a job within IT instead. DotCom was still booming, and the Danish startup Neupart and Munkedal were looking for a database developer. I must have been good at the interview or maybe it was just hard to find talent back then, because I got the job… ?? Anyway, I defended my thesis the last Friday in February and started on the job the following Monday. ?

Neupart and Munkedal started as a security consultancy company where security experts would perform security penetration testing for customers and as part of the service, provide the customer with a written report with the results. Before I joined, the company got investments from a VC and the idea was to try and automate part of what the consultants were doing with a tool that would scan the customers IP addresses for open ports, identify what services was behind the ports, and then check for known vulnerabilities (this was years before tools like Metasploit or Kali). The tool would then gather all this information and format it into a report.

My role was in the development team for the tool, and for us to understand the domain, we were sometimes attending the security consultant team meetings. My reason for wanting to work in IT security was that I found it fascinating to work with hacking. From the outside hacking seemed glorious, exciting, and exotic, but being close to these white hat hackers, I quickly learned that hacking is mostly about knowing/learning very technical details on protocols, operating systems, programming languages, buffer overflows, and in general trying to understand systems in way they were not supposed to be used.

Another thing I learned being among security professionals was the level of access they or able to gain in customer systems. To me this was both fascinating and frightening. We were the good guys, but I also imagined that the same skills in the hand of an adversary could be really devastating for the victim organization. And so, I learned very early on in my career that when it comes to security you need to be cautious to the brink of paranoid when designing security for systems. And I think that this paranoid thinking has followed me the rest of my 20 plus years in the industry.

?

IT university of Copenhagen (mid 2000s)

My next job was as a developer of business processes and their supporting IT systems (think ERP for a University) at the IT university of Copenhagen (ITU). When developing systems with personal data, it was extremely important that student information was only available to administrators and themselves, and not to other students or outsiders. And of course, we needed to ensure that (too) clever IT students could not mess with their grades…

In the early years of the 2000s the OWASP project was born (read more here OWASP - Wikipedia), and I remember reading about their top ten lists of a web vulnerabilities in 2003/2004. In my team at ITU, we used that checklist as a guideline for things to fix in our system and to harden the system against all the common types of vulnerabilities. The idea of having a security checklist, or security guideline made it possible for us as a small team of non-security experts to be able to harden our system against outside threats. Checklists and guidelines are your friends (more about this later).

It was also during my years at ITU that I learned about the gold standard: Authentication, Authorization, and Auditing (it took me 10+ years to learn why they are called the gold standard… Do you know why?).

Authentication and authorization was “easy” - this was just a matter of having users use good password policies, and having a role-based system for access. Auditing back then in our system was mainly about logging privileged actions to a log file. I did experience one or two times where I actually needed to search in a huge log file for information, so I also know now that for auditing, logging is one thing, but being able to retrieve information is also important.

?

Miracle (late 2000s)

My third job was with Miracle, working as a consultant within databases. This was also my first job as a consultant and I started right when the financial crisis hit Europe in late 2008. Not the easiest way to start a consultancy career with no clients knowing your skills and no portfolio of existing clients... ?? Struggling to get enough work that could be invoiced to customers, I thought about prior experience that I could use and bring to the company. And it struck me that even though security is a key part to a database system (the gold standard), we really didn't have a lot of focus on this topic. So, I organised a full day of sessions on security related to database professionals, where we ?invited guest speakers with expertise from operating systems, network, core database skills such as authentication and authorization. After lunch, we moved up the stack to security in applications, discussing OWASP. And then ended the day with a session on social engineering (call the help desk to get some persons password.) The day was a huge success and we filled the office with customers who were interested in this topic.

My experiences from that event and from Miracle in general, told me that you need to build/think security into every layer in your technology stack (the onion model). Also that having people with cross-stack security knowledge and mindset is not common. And then that no matter how much you harden the stack, this is not enough. Learning about social engineering, that even the best engineered security system can be bypassed by an adversary getting “help from a friendly person.”

As a sidenote, from this event and until I finished my consultancy career in 2016, I tried to train my social engineering skills in a fairly innocent way: if I had a meeting with a new customer at their site, I would always try to bypass the reception and go straight to the meeting room without someone walking me there. Sometimes I succeeded, most times a clever (and security-trained) receptionist would not allow me (I would always praise them for this behaviour).

?

Microsoft (the last 8 years)

Jumping a few years ahead, I joined Microsoft in 2016. Coming from outside the Dynamics NAV product team and not being an expert in ERP systems or the Dynamics NAV platform, just like in Miracle, I wanted to bring something useful to the table while I learned about my new role. Again, I could leverage my experience in security, as Microsoft back then were focusing a lot on their security mindset called “assume breach". This is the idea that no matter how much you harden a system (the onion model), assume breach thinking is trying to challenge that this is not enough. When assuming breach, you simply assume that hackers are already somewhere in your system, and therefore the hardening needed is also about making sure that they cannot pivot further, that whatever secrets they steal are useless, and so on. So in the platform team, we did a tabletop exercise where we modelled threats assuming breach. And then hardened our server accordingly.

For many years, software development teams within Microsoft have also used a method called “threat modelling”, and learning about this method also resonated well with my days at ITU, where having a methodology or a recipe can help non-security experts like me developing more secure software.

In later posts, I will dive much more into our Secure Future Initiative (SFI) programme and how you can use it to harden your (ERP) installations and development practices.

?

Signup to the newsletter (and/or spread the word)

That's it for now. Thanks for reading along. If you made it down here to the end, security has more or less been a focus area for me in my entire career. Anyway, enough rambling. In the next posts I will dive more into concrete areas of security that I hope you as Business Central / ERP professionals will find useful in your daily work.

Do comment on things that resonated with you when reading the article. Next post will be about how I almost got spear-phished today and something on security awareness.

If you are present at the Summit NA 2024 conference this October in San Antonio, TX, then you can hear the full story in one of my sessions there.

Stay tuned and secure until next post…

PS. If you liked the newsletter and think that others might benefit from it as well, please send them the signup link here:

https://www.dhirubhai.net/newsletters/6981923051273658368