I have now been playing on the pentesting platform hackthebox for more than a year. I have been in IT security / infosec for a very long time, but I was very late to the offensive party. It still amazes me why that is. Some random thoughts!
I was not really aware of the exact terminology regarding blue and red teams etc. The Public Key Infrastructures I have built are maintained by the 'networking' or 'server' or 'Active Directory' teams, so I had always considered 'security' to be one aspect of the work the architects and network administrators have to do. Maybe I do not even count as 'infosec' - I am just the administrator of all things certificate-related.
I often sided rather with the people who had to maintain the 'security infrastructures' on a daily basis, rather than with consultants (internal or external ones) who tell those administrators how to secure the infrastructure. People keeping infrastructure a the bottom layers of the network afloat are hardly noticed - until something breaks. I had my share of WHO IS RESPONSIBLE THAT THIS WAS NOT WORKING FOR [a time span very very small compared to the time the system was running well despite lots of changes].
In the book Advanced Penetration Testing a seasoned expert states:
All that is needed for an attacker to gain entry to the most secure environments is for one person to have one lapse in judgment one time. I keep driving this point home because it really is the point. As a penetration tester, I have the easy job. An attacker is always at an advantage. I would hate to have the responsibility of keeping a network safe from attack; I'd never sleep.
I think as a security consultant - red or blue, consultant as opposed to sysadmin / 'devops' - it is hard to fully acknowledge all the conflicting requirements and constraints you have to meet when you need to keep things running. I suspect I also helped implementing dumb and insecure things at times, because they were the best trade-off at that time.
Often I found myself pondering on 'opposites', as red versus blue, consulting versus doing, projects versus operations. Should I lecture and comment rather and implement and do? Is commenting and consulting just fence-sitting without skin in the game? I finally decided for more involvement in keeping things running. Actually, I once became a consultant because I feel so terribly responsible for systems and infrastructures also as an external consultant (usually without a long-term formal contract) who is touching that infrastructure once every few months. But every time I was officially responsible for systems it was hardly bearable and moved me nearly over the edge into burnout - I better erect that 'external consulting barrier' to keep me somewhat detached.
I also don' t want to say that offensive roles are 'easier' - far from this! I do not have real-live experience with pentesting, but I imagine it as consulting on steroids: Travelling a lot, chaotic deadlines, all the non-glorious aspects of consulting in general, politics,... Exactly the aspects that made me abandon the nomadic consulting life-style, by the way.
Following infosec experts on Twitter I notice that there is an old debate popping up from time to time: Should 'infosec' be an entry level role, so should you e.g. go straight into security after college, or should you have an experience in other IT and software roles before - as a programmer, system architect, or network administrator? Given my own path I should be in the latter camp, I guess. But on the other hand, again given my own path, I can imagine that you can absolutely become a security expert with dedication and without having spent grueling years, say, fixing clients' my-Outlook-does-not-work issues.
I changed my careers a few times, but I can as well present these transitions as a gradual, logical evolution. I had been a newcomer often, and I people were asking me: How long have you been doing this? It was meant as a compliment, and I avoided to reply with the truth, like: a few months only. When clients considered me a 'PKI guru' I often said that I firmly believe that a student with enough dedication can become that exact type of guru in a year, too.
My blog was originally called Theory and Practice of Trying to Combine Just Anything. I had things like 'Physics and IT' in mind, or 'I had also considered to study philosophy and want to be some sort of renaissance person'. Maybe this is how I have approached security, too: I wanted / want to combine all kinds of experiences. It has been my choice, my path, not necessarily the expression of some career advice that would apply to anybody. Playing at hackthebox always shows me how much I do not know - about IT technologies and pentesting methods and tools. Only very rarely, I can contribute something original, based on something I really know something about - like in the case of my PKI / smartcard hack.
I feel very much that I am dilettante - in a positive sense of what the word actually means.
... on a pentesting platform. that became my main 'social network'!
It feels like the natural progression from my walking down the stack: In the last year I re-lived my history of a physicist in IT or an IT security specialist trained as a physicist. I investigated the security of embedded systems and sniffed network traffic - mostly related to monitoring and control of physical devices for 'generating' or storing energy.
I wanted to fill in gaps of knowledge, I turned to classic introductions to computer science, and I caught up on C/C++ and Python. But trying to hack systems is still another kind of skill: I had been a 'defender' for many years, explaining to others how to secure their systems, but I lacked the skills of an attacker.
After I had dabbled in forensics of unknown files and in using automated testing tools with modest success, I decided I want to learn this craft thoroughly. Or was it? Maybe I just want to play and see how far I can get. It was a surprise that I was actually able to hack the entry challenge for that pentesting platform. Fast-forward: I had hacked more than 80% of the active boxes.
My experiences there are both very humbling and very gratifying. Sometimes I struggle with even getting an exploit tool to run as I lack some basic knowledge of compile switches. But sometimes I discover I can leverage some things I didn't even realize consciously or ancient things buried deep in my memory. Who knew that ASP and VBScript would ever be useful again? And my preferences of Python and C++ (for non-destructive purposes) feels eerie now - I could not have picked the languages for my exploit tools better! My adventures with learning SQL Server a few years ago also come in handy, and what I considered my most unprofessional hacks turned out to be most useful: Stringing together 'applications' from scripts and compiles code in different languages, burying one into the other, not being afraid of loads of different quotes embracing each other. As a side effect, I am also more daring when it comes to my non-malicious code now: I have no problems any more to state publicly that I write an application in C# that adds VBA macros to Excel and executes them!
My immersion in this addictive platform also told me something about my learning preferences ... again. I had known it but it was not that explicit: I want to learn from solving problems. That was my intuitive answer once, when colleague had asked how I make myself familiar with new technologies, a freshly released operating system at that time. I replied that I try to solve one specific problem on that new system (involving X.509 certificates then) - and then expand my knowledge from there. I have pontificated about my love of reading textbooks and immersing myself in abstract theory, and this is not a contradiction: Hadn't I ploughed through the later chapters of Structure and Interpretation of Computer Programs - the ingenious explanation how compilers and assembly works - I might not enjoy my attempts to create buffer overflows that much. Which is a topic I need much much more reading and playing with, by the way.
I know am saying the same things again and again and again - here, on my blog, and on social media. It seems my websites have run their course for the time being - I am not actively trying to search for new content to create, and I feel like writing articles that flow naturally, rather than writing semi-scholarly papers with code and data. So I am leaving this article here, on the site that nobody reads, as a hidden away note maybe.
Recently I've changed my story at some social profiles again - to this:
Specializing in: Control systems, software development for measurement data analysis, IT security, troubleshooting and reverse engineering systems with physical (hydraulic) and software (control) components.
I am running a small engineering consultancy together with my husband. We are both physicists, and we focus on designing, programming, and troubleshooting control systems for heating / solar systems, especially heat pump systems with a combination of uncommon heat sources and custom control. For more than 10 years I have implemented, reviewed, and troubleshooted public key infrastructures, and I still do this for some long-term clients.
In contrast to this blog, this site here is more of an extended profile / About Me page. It is my hand-crafted whoami machine.
I think about my exploration of layers of software. tl;dr: I am gradually moving down / back to the lower levels of software, the ones closer to hardware, electronics, control, field bus systems etc.
I've started out learning about micro-controllers in electronics class as a physics student. Then I programmed sensors and actuators for measuring the low-temperature electrical properties of superconductors as a staff scientist at the university (in Turbo Pascal). Yet I jumped up to the top of the software stack and switched to Microsoft scripting languages: VBA, VBScript, ASP when I went 'from research to IT'. Even the first version of my numerical simulation for our heat pump system was an Excel spreadsheet, then a VBA application using spreadsheets.
It seems I needed to trade 'IT' again officially for 'renewable energies' to be motivated to move down the stack again. When I was a non-traditional 'post-graduate' student in in energy engineering I was always been the 'Excel programmer' in group projects. Buth then I went down rabbit holes: Learning SQL Server and Transact-SQL for analyzing our measurement data. Re-writing the simulation software, now based on Visual Basic .NET, for the first time using a true object-oriented design. To get ready for this, I had re-written this website from scratch in .NET before. My so-called Data Kraken uses a combination of Powershell and SQL scripts today.
I finally learned to utilize all my processors in my simulation, and I fixed lots of performance issues. I read Joel on Software cover to cover to re-live the period I 'was in IT' and to catch up on fundamentals. He pointed me to Structure and Interpretation of Computer Programs which I consider the single best ever lecture / course I've ever 'attended'. It is both so deep and philosophical, and at the same time so useful: My simulations became faster by a large factor.
And all the time, I did reverse engineering and debugging. I think I have done this ever since, but always at the level I understood software at the time. Of all the tasks I had as an IT Security / Public Key Infrastructure consultant, troubleshooting weird issues with X.509 certificates was maybe the best one: Digging deep into network traces, reading up on RFCs. Every time I was theoretically only a user of software and services, I ended up debugging in detail - like using Wireshark to track down a weird compatibility issue between my e-mail client and a mail server, when just trying to sign my invocies via a digital signature solution using SMTP.
Then I finally learned C and C++, and I read about Assembly and the art of reverse engineering and malware analysis - to really appreciate the final chapters of SICP, about the self-referential wonders of compilers and interpreters.
Trying to visualize the stack and what happens to the registers, I picked up a very old book - the one I used decades ago in my electronics class - and I jumped into the chapter about micro-controllers. And then it hit me: Those fundamentals, they have not changed much. Yes, different processors have different instruction sets and you might have 8bit, 16bit, or 32bit. But the explanation about the stack, and how to return from a function - this has always been an eternal truth since that electronics book and SICP had been released.
All falls into place: Understanding C is really the pre-requisite for understanding field bus communications, and that is what control units use. Debugging skills are essential when dealing with abandoned engineering software from the stone age.
So I finally found the most logical connection between physics and IT, the place to be as a physicist in IT or in engineering or whatever.
Onword to Python!
I will try to explore my relationship with IT / software / computers / computer science / software engineering or whatever the best term is to describe it. I am in a mode of looking back with content, and making small changes, learning a bit more.
As often, thinking in 'opposites' comes most natural to me:
Self-study versus formal education. The IT and software industry is young and - I believe - had originally been populated by people without a formal training in computer science as this did not yet exist as an academic discipline. The community was open to outsiders with no formal training or unrelated experience. As a former colleague with a psychology background put it: In the old times, anybody who knew how to hold a computer mouse correctly, was suddenly considered an expert.
I absorbed the hacker ethics of demonstrating your skills rather than showing off papers, and I am grateful about the surprisingly easy start I had in the late 1990s. I just put up a sign in a sense, saying Will Do Computers, and people put trust in me.
I am not 'against' formal education though. Today I enjoy catching up on computer science basics by reading classics like Structure and Interpretation of Computer Programs.
Breaking versus building things. I have been accountable for 'systems' for a long time, and I have built stuff that lasted for longer than I expected. Sometimes I feel like a COBOL programmer in the year of 2000.
But I believe what interested me most is always to find out how stuff works - which also involves breaking things. Debugging. Reverse Engineering. Troubleshooting. All this had always been useful when building things, especially when building on top of or interfacing with existing things - often semi-abandoned blackboxes. This reverse engineering mentality is what provided the connection between physics and IT for me in the first place.
It was neither the mathematical underpinnings of physics and computer science, or my alleged training in programming - I had one class Programming for physicists, using FORTRAN. It was the way an experimental physicist watches and debugs a system 'of nature', like: the growth of thin films in a vacuum chamber, from a plasma cloud generated by evaporating a ceramic target bombarded with laser pulses. Which parameter to change to find out what is the root cause or what triggers a system to change its state? How to minimize the steps to trace out the parameter space most efficiently?
Good-enough approach versus perfectionism. 80/20 or maybe 99/1. You never know or need to know anything. I remember the first time I troubleshooted a client's computer problem. I solved it. Despite knowing any details of what was going on. I am sort of embarrassed by my ignorance and proud at the same time when I look back.
In moment like this I felt the contrast between the hands-on / good-enough approach and the perfectionism I applied in my pervious (academic) life. I remember the endless cycles of refinement of academic papers. Prefixing a sentence with Tentatively, we assume,... just to be sure and not too pretentious though I was working in a narrow niche as a specialist.
But then - as a computer consultant - I simply focused on solving a client's problem in a pragmatic way. I had to think on my feet, and find the most efficient way to rule out potential root causes - using whatever approach worked best: Digging deep into a system, clever googling, or asking a colleague in the community (The latter is only an option if you are able to give back someday).
Top-down, bottom-up, or starting somewhere in the middle. I was not a typical computer nerd as a student. I had no computer in high school except a programmable calculator - where you could see one line of a BASIC program at a time. I remember I had fun with implementating of the Simplex algorithm on that device.
However, I was rather a user of systems, until I inherited (parts of) an experimental setup for measuring electrical properties of samples cooled down by liquid nitrogen and helium. I had to append the existing patchwork of software by learning Turbo Pascal on the job.
Later, I moved to the top level of the ladder of abstraction by using *shock, horror* Visual Basic for Applications, ASP, and VBScript. In am only moving down to lower levels now, finally learning C++, getting closer to assembler and thus touching the interface between hardware and software. Which is perhaps where a one should be, as a physicist.
Green-field or renovation (refactoring). I hardly ever had the chance to or wanted to develop something really from scratch. Constraints and tough limiting requirements come with an allure of their own. This applies to anything - from software to building and construction.
So I enjoy systems' archaeology, including things I have originally created myself, but not touched in a while. Again the love for debugging complements the desire to build something.
From a professionals' point of view, this is a great and useful urge to have: Usually not many people enjoy fiddling with the old stuff, painstakingly researching and migrating it. It's the opposite of having a chance to implement the last shiny tool you learned about in school or in your inhouse presentation (if you work for a software vendor).
In awe of the philosophy of fundamentals versus mundane implementation. I blogged about it recently: Joel Spolsky recommended, tongue-in-cheek, to mention that Structure and Interpretation of Computer Programs brought you to tears - when applying for a job as a software developer.
But indeed: I have hardly attended a class or read a textbook that was at the same time so profoundly and philosophically compelling but also so useful for any programming job I was involved in right now.
Perhaps half of older internet writing reflects my craving for theses philosophical depths versus the hard truth of pragmatism that is required in a real job. At the university I had been offered to work on a project for optimizing something about fluid dynamics related to the manufacturing of plastic window frames. The Horror, after I had read Gödel, Escher, Bach and wanted to decode the universe and solve the most critical problems of humanity via science and technology.
I smile at that now, with hindsight. I found, in a very unspectacular way, that you get passionate about what you are good at and what you know in depth, not the other way round. I was able to possibly reconnect with some of my loftier aspirations, like I could say I Work In Renewable Energy. However, truth is that I simply enjoy the engineering and debugging challenge, and every mundane piece of code refverberates fundamental truths as the ones described in Gödel, Escher, Bach or Structure and Interpretation.
Since 2012 I have published PKI status updates here, trying to answer the question 'Do you still do PKI?' (or IT). I have re-edited them often, and my responses were erratic - I was in a Schrödinger-cat-like superposition state of different professional identities.
Now and then I still get these questions. Can I answer it finally? I am still in a superposition state - I don't expect the wave-function to break down any time soon. I enjoy this state! But my answer to IT-related requests is most often no.
So yes, I am still 'working with IT' and 'with IT security' professionally. Not necessarily 'in IT'.
I am supporting a few long-term clients with their Windows PKI deployments and related X.509 certificate issues (after having done that for more than 10 years exclusively). Those clients that aren't scared off by my other activities, and clients I had always worked with informally and cordially. But I don't have any strong ties with specific PKI software vendors anymore, and I don't know about latest bugs and issues. So I don't present myself as a Windows PKI consultant to prospects, and I decline especially requests by IT security partner companies who are looking for a consultant to pitch or staff their projects. I am also not interested in replying to Request for Proposals for PKI or identity management and 'offering a solution', competing with other consultants and especially with other companies that have full time stuff doing business development (I hardly did this in my PKI-only time). I am not developing software anymore that might turn into an 'enterprise solution'.
Today I am working 'with IT' more than 'in IT' in the sense that I returned where I came from, as an applied physicist who was initially drawn into IT, armed only with experience in programming software for controlling experimental setups and analyzing my data: I call myself the 'theoretical department' of our small engineering consultancy - I am developing software for handling Big Monitoring Data. I am also tinkering with measurement technology, like connecting a Raspberry Pi to a heat pump's internal CAN bus.
Security is important of course: I have fun with awkward certificates on embedded devices, I sniff and reverse engineer protocols, and I could say I am working with the things in the Internet of Things. But I am not doing large-scale device PKIs or advising the IT departments of major engineering companies: My clients are geeky home owners, and we (the two of us) are planning and implementing our special heat pump system for them. An important part of such projects is monitoring and control.
So every time I feel that somebody is searching for 'a PKI consultant' I am the wrong person. But if somebody stumbles upon my CV or hears my story at full length - and absolutely wants to hire me just because of the combination of this - I might say yes.
But it is no good rationalizing too much: Finally it is a matter of gut feeling; I am spoilt or damaged by our engineering business. Our heat pump clients typically find our blog first - which has been mistaken for a private fun blog by friends. Prospects are either 'deflected' by the blog (and we never hear from them), or they contact us because of the blog's weird style. Having the same sense of humor is the single best pre-requisite for a great collaboration. So whenever I get any other project request, not mediated by a weird website, I try to apply the same reasoning. Years ago I a colleague I had not met before greeted me in the formal kick-off meeting, in front of all others, with: You are the Subversive Element, aren't you? (Alluding to my Alter Ego on subversiv.at). That's about the spirit I am looking for.
radices is roots in Latin. And accidentally there is a pun, perhaps as hackneyed as roots of all evil. As a security consultant I built lots of Root CAs, the top anchor in the hierarchies that are called Public Key Infrastructures.
radices.net shall now be dedicated to what online gurus and internet philosophers call curating today. Which means I just dump links to stuff I am interested in to add some basic structure of headers. radices was a German science pseudo-blog but it also was an experiment in organizing content - so I have come full circle.
About my PKI activities
I had been a PKI consultant since 2002, mainly working with European enterprise customers on designing and implementing their PKIs run inhouse. Now I am supporting some long-term existing clients with their PKI / X.509 issues but I don't take on new clients.
As a former Microsoft employee I have focused mainly on the Microsoft PKI, versions Windows 2000 / 2003 / 2008 / R2 / 2012 R2 - but I also had some exposure to various other PKI-enabled applications and devices. The fun part of PKI projects is in debugging weird issues that exotic or allegedly 'industry-grade' applications have with validating certificate paths, using keys etc.
- I try to keep track of links, books, papers etc. I found useful and add them to this list. This is not intended to be the perfectly structured, 'educational' collection. I rather pick and add what I stumbled upon while working on PKI issues or discussing with other security freaks.
- I started logging PKI issues here. The idea is to described them most concisely, in TXT format.
- Struck by vanity I made the collection of my modest own contributions a page in its own right. I am also trying to keep track of my postings to security forums in order to use those as my knowledge base.
I am originally a physicist (completed PhD in 1995), worked in R&D and switched to IT security. In 2013 I have completed another master's degree called Sustainable Energy Systems and did a master thesis on smart metering and security (LinkeIn profile). Now I am consulting engineer working with heat pumps that use a special heat source. Yes, I know - it is weirder to combine that with PKI.
The security of the smart grid and internet of things [add more buzz words here] provide options to re-use my security know-how in the context of my new field. Such heat pumps may use control units connected to 'the internet' and all kinds of certificate-/PKI-enabled stuff might be involved here.
For five years I have given a yearly lecture in a master's degree program, then called Advanced Security Engineering at FH Joanneum. Here is the last version of the slides.