I am a 20+ year veteran of the Defense Intelligence Community specializing in systems architecture, systems engineering, systems integration, and solutions prototyping. At my core, I am more tech than business, but my experience and seniority routinely have me in strategy sessions with business leaders and mission planners as a trusted adviser. I have an inherent drive to understand every element of a mission thread, from the “Commander’s Intent” through the Roles & Responsibilities, timelines, risks & migrations, and on through the systems and technologies supporting the effort.
This “mission focus” over “skill focus” has taken me on an atypical career path, better viewed as a random walk. Here’s one view of that walk:
before_the_internet @ army.mil
Trained in the Army as an Arabic linguist / SIGINT specialist and dropped into a tactical MI battalion in the 101st Airborne, my first job in the industry was cultivating familiarity with a wide variety of radio gear that we would hump, drive, or fly to enemy territory to determine who they were, where they were, and what they were up to. Occasionally, we might also use that gear to interfere. The training, I felt, seemed a bit light — particularly with RF propagation, modulation types, and so forth — and led to poor decisions about what to carry and how to operate, all with tactical repercussions. To fix myself first, I went off and earned my Amateur Radio then-Advanced Class license (currently an Extra Class). My unit benefited as I passed on the knowledge and our success rates improved. Before long, the battalion commander was scolding the company commanders to find that guy in the barracks who reels up those antenna wires and tent pegs into his window before PT formation and to get him down to the parade field to see if he could get those long range digital HF rigs chatting with the other divisions. (He did.)
mathematician @ nsa.gov
After the military, I found myself in the university quickly becoming a mathematician, putting all of that Army, Arabic, and radio stuff behind me. I had always had an aptitude for math and computers, learning BASIC programming and calculus around the 6th grade, moving on to PASCAL, 8088 Assembly Language, and some FORTRAN soon after. In the university, though, I gravitated toward topology and the other pure math topics, with a knack for comprehending and explaining very complex systems and spaces. (In truth, my arithmetic was poor, but my abstract theorems were spot on!) One winter there, I saw a flyer on the bulletin board for “The Director’s Summer Program” for undergraduate mathematicians. That summer, I found myself sitting inside the National Security Agency, taking intensive courses and solving problems with quite an elite, young crew. While others there had shinier pedigrees and would undoubtedly go far in their specialties, I had maybe just enough talent to keep up, but also the computer skills, the language skills, the radio skills, and the understanding of how those things came together. I just didn’t know beforehand that I’d be sitting in the place where all of those skills came together.
WVU (Morgantown)
I was invited to come back the next summer, and then I was invited to stay. I spent three years in the Applied Math Program, a Ph.D.-level “internship” of sorts, rotating though the cohort’s math, signals, and some computer classes, as well as tours of duty in different offices where Agency mathematicians might someday work. Again unlike the others, I went off book and toured in precisely one office where there had been no previous mathematicians, and I spread my work tours helping threads that involved everyone from the engineers pulling the RF out of the environment, the signals folks turning them into “1”s and “0”s, the crypies working to turn the cipher into plain text, the analysts in the field and at home to help make sense of what we were reading, and in the “boardrooms” reporting our results and championing our efforts. When we had enough notoriety, we were able to augment our staff and transition our shoestring tactical research effort into a hardened effort supported by operations. That work culminated in my earning a billet as a Member of the Technical Staff in the Math Research Group. That was where I was sitting on 9/11…
engineer @ contractor.com
The next year I made the difficult choice to turn from federal employee to contractor. We needed the money and that pay increase was significant. I gave up a lot, but found myself in the midst of work that only contractors could really do. I learned the programmatics of contracting (the business side) while directing the technical research efforts of a telecommunications lab, asking how these various integrated systems might be vulnerable and how they might be creatively exploited by an adversary. That work involved grand designs and concepts of operation at the highest levels, systems and software reverse engineering at the lowest levels, and selling and directing software developers and systems engineers to build their own respective moving parts so I could bring them together in time.
From here, I had the opportunity to form a consultancy and subcontract to a major prime team effort, which held both a major waterfall-ish effort for back-end systems and an agile development handling front-end systems integration and initial data handling. In keeping with my nature and experience with both front-end and back-end systems, my role was to move between all the efforts and help where I could, providing daily after-hours feedback to the Program Manager, Chief Engineer, and the Chief Software Engineer. I would raise observed programmatic risks, propose alternatives, calculate expected costs and losses, and champion the remediations through the Architectural Review Board (ARB), the Engineering Review Board (ERB), and the Risk Advisory Board (RAB). As this program was drawing down, I was held back to help develop a strategy of how the different components produced might be leveraged by the prime for future R&D and contract efforts.
Two subsequent efforts leveraged technical skills, mission knowledge, and trusted adviser skills in leading high profile technology evaluations and efforts to rapidly assess untrusted systems and to safely incorporate them into critical mission workflows, balancing mission needs against security constraints.
In the culmination of all mission threads and my work in this particular industry, I had the honor to serve in a position of special trust as a Systems Engineer & Technical Advisor (SETA) in a Program Management Office bridging strategic and tactical organizations. As a SETA, I was a contracted trusted adviser leveraging technical and mission knowledge to evaluate strategies, to help in creating solicitations and in evaluating proposals, to “call bullshit” where warranted, and to assist the office in vendor negotiations.
nobody @ startover.com
After this, though, it was enough. Circumstances at home were pulling me to be close by, working from my home office whenever possible. My next opportunities were practically starting over, but they filled in a particular deficit: Suddenly, I was deploying and configuring firewalls, routers, switches, wifi systems, and so forth. Those devices that were originally just sources of my “1”s and “0”s were suddenly in my charge. In short order I was architecting and building out a secure network to allow for multi-client site / multi-user / multi-privilege access, monitoring, alerting, command & control of services, security scanning, and everything else under the sun. I have everything from a redundant virtualized core servers (Xen XCP-NG and occasionally ESXi) to connected AWS cloud servers and even on to a few deployed Raspberry Pi boxes, some with connected circuits and sensors. Here, I developed a particular respect for Operations & Maintenance that I lacked as an R&D fellow. I took that new respect (or pain) and worked quite diligently to automate various recurring systems administration and security tasks on my calendar.
joe @ evolution.org
Over time, this base network has evolved, serving most interestingly as a deployment prototyping lab for clients. Here we can simulate the client’s environment and stand up various services for testing and demonstration, allowing for a more rapid deployment into their own networks. During the work, we’re known to use lab email, lab VoIP telephony, git servers, in-house wikis, and other means for collaboration, all accessible to the client. At times, the lab has had up to four kerberos realms, 3 VPNs, 10+ VLANs and separated networks, and secondary client-controlled, soft firewall-routers operating in support of different investigations. At times, the lab has even been configured for security monitoring in support of malware investigations.
Recently I find myself involved with infrastructure identity management strategies, technologies, and deployments, including deployments of stand-alone kerberos, LDAP, RADIUS suites, FreeIPA and related services, and even a major migration of a major system underpinned by Microsoft AD-LDS services to one using Okta as a third-party identity provider. For that later case, my skills with standing up servers, LDAP, SQL, and scripting in bash, python, and perl, made quick work of defining a migration strategy and performing data analysis, scrubbing, transformation, and testing. For the former, special training in the various authentication protocols and underlying cryptography, plus knowledge of the underlying operating systems and networks, went a long way to helping clients understand the nuances of PKI certificate use and life cycle, kerberos use and deployment, LDAP configuration, PAM and sssd involvement on Linux servers, RADIUS flow and decisions, and more recently SAML and OpenID-Connect (incl. OAuth) flows. In particular, to develop a deeper understanding of those web-flows, I am experimenting more with node.js express and python flask, creating RESTful network services with endpoint protection, using keycloak realms, some separate and some attached to an underlying FreeIPA IdM. Additionally, I’ve recently migrated a few Apache-based webapps from LDAPS-protected endpoints to use of OpenID-Connect instead for a nice, single sign-on experience.
Finally, my long experience across business functions as a trusted adviser combined with experience in software development, network infrastructure, special technical training, and even the long years of working in secured environments, has all led to increased tasking as a security consultant with particular emphasis on security program reviews, systems architecture reviews, risk assessment, and remediation planning. Additionally, though it is not a favorite activity, I occasionally do support the specific tasks of network and application penetration testing — though always with an IV&V mindset.
joe @ tcmlabs.com
it’s funny: On any given day working through technical puzzles for myself or others, I can be personally stymied by what I don’t know and by what I think should be trivial. It’s at times like those when I like to pause, revisit all of the above–and some of the accomplishments that I can never share–and then remind myself that I am handling issues where people gave up asking Google some time ago.
