Some close friends and colleagues in cybersecurity encouraged me to write about ‘growing up’ in Information Technology (IT) and cybersecurity during the computer era before there were CISOs (Chief Information Security Officer). I’m sure there are other Baby Boomers out there, who have similar stories to tell and understand what it was like as technologies rapidly advanced and became business assets that needed managing (the “Rise of the CIO”) and, much later, securing those assets became a business risk management concern (the “Rise of the CISO”).
My point of view is from public sector experience; although, I have had much contact with my private sector counterparts. My public service started in high school as a volunteer swimming instructor and lifeguard, then working in a public library in a small southern California city. My professional civil service history covers over 36 years with the City of San Diego, California, including over 12 years in law enforcement as a sworn officer and almost 25 years in positions related to IT. My last 10 years were in IT management, retiring as the city-wide IT Operations & Security Manager.
The intent of this two-part article is to share how information security needs and functions existed before the roles were defined, as has been the case when new inventions cause shifts in business operations (i.e., the industrial revolution). What follows in this Part 1 is the first two decades of my cyber evolution, climbing the career ladder while ‘growing’ IT staff, and the requirement for open communication, cooperation, and collaboration between both IT operations and business operations. In Part 2, I will continue with my third decade, breaking out of the “IT box” into the strategic aspects of security for operational systems, industrial control systems, and underlying information assets. It is in the second article where I will discuss how the rising cybersecurity functions become identified as major roles created to manage newly defined areas of responsibility.
As I look back over the decades, a couple of sayings come to mind – “what goes around comes around” and “what’s new is old” (or vice versa, “what’s old is new”) – meaning that the underlying security needs in today’s environment really aren’t new, they’re just using different technologies (which will continue to change).
So with that, let’s get started – in my last two years in law enforcement, I got hooked on technology and developed some simple applications to issue and track certain permits and accident data. While I was not consciously aware of performing any security measures at that time, I realized not everyone should have access to the data being collected, so these simple applications did require a user ID and password. To keep this in a technology perspective, these were all mainframe-based, using ‘dumb terminals’ (some of you remember – the ones with black screens and green text). To be honest, the mainframe seemed mostly secure – you needed an ID and password just to login to the host system, then a different password for each application (usually assigned by the System Administrator) – long before the days of Active Directory® (AD) and Single-Sign-On (SSO).
After leaving law enforcement, I took an administrative position in a six-person division, which would, over the next several years, become a major department with over 1100 employees, plus hundreds of contractors. [A note of reference for those in the private sector – the city structure consists of departments (e.g., police, fire, library, water, etc.) which are comprised of several divisions. This is generally opposite of a private corporate structure where divisions are the larger business unit.] In my first six months, I was given the task for our first staffing growth to purchase and outfit 100 employees and contractors with new “personal computers” which had to be networked to a MicroVAX server. The mainframe team said, “these personal computers are just a fad, stick with the tried and true…” A few months later, while starting to configure the new PCs on an Ethernet network, the existing network team said, “why are you testing that Ethernet technology, you should stick with the standard token-ring technology…” We all know the outcome of those statements (can you say, Sony Betamax?). In that first growth spurt, our IT budget went from $150,000 in the first year, to $1 million in the third year and, needless to say, the designated security budget was zero. As the department continued to grow each year, I was able to justify hiring more IT staff, and, as a result, getting myself promoted to oversee the new staff. How did that happen?
While I was given mostly free reign in the area of new technologies, I had close working relationships with senior management and also the operations supervisors, engineers, scientists, facility & field maintenance supervisors, and administrative staff. I needed to understand their basic job functions and operational requirements in order to obtain the necessary technology to meet their needs. This is nothing new (today) for a customer-centric approach to IT services. At that time, executive management understood the need for new technology, without understanding the technology itself. They trusted that I didunderstand what was necessary to maintain and improve work efficiencies by implementing appropriate technologies. I had to earn that trust by demonstrating system capabilities (usually a live demo) and providing cost-benefit analyses in selecting a product for purchase. Keep in mind that, with government budget cycles, I was justifying the technologies and costs about 14 months before the budget would be approved. In those early years of having PCs, products mainly included desktop productivity tools for word processing, databases, and spreadsheets, well before there were any integrated “office” packages. Email was still based on the mainframe for several years.
As we added department staff, I was able to find several national surveys describing the recommended number of IT staff to adequately support a specific number of users for desktop support. I started with a ratio of 1-to-200 when I was the only IT person, then as we grew, I changed the ratio to 1-to-100, which was still nearly double the national average. At this time, I justified and added the first two new IT positions, and I became a lead IT Analyst. In the following year, the department would experience explosive growth and expand to nearly 600 employees at five sites. Of course with this growth I was able to justify four more IT staff, and have my position elevated to an IT Supervisor. This was achieved partially through the rapport with senior management, who were not focusing on the technology itself, they were relating to how the increased use of technology required skilled IT support technicians to maintain efficient business operations – a very novel concept at that time. I believe I helped influence this executive support with internal and external help desk call statistics I had collected. I used those collected metrics to provide an estimated cost impact of employees’ lost productivity due to system degradation and the average mean time to resolve, in relation to how many IT staff were available to provide critical support services. The projected reduction in costs were used to more than offset the cost of increased staffing, and I was able to justify the four new IT positions, while now managing an annual department IT budget of nearly $12 million.
One critical viewpoint I believe assisted me during this time, is my understanding that management, engineering, and operations needed to be fully “in the loop” when moving ahead with new technologies and their companion security measures, so I made sure to provide them with this visibility. However, it should be noted, that with these new technologies came increased responsibilities for my growing IT section. The IT staff had to meet increasing operational and performance requirements. They also had to ensure the security of its systems and permit public access to records when necessary. At the time, this was a daunting task; remember this is in the early stages of enterprise IT and there were no published functional frameworks on how to manage large, distributed networks. To get this far in building out the IT program and continuing its forward momentum, in retrospect, I now find that I was (unknowingly at that time) following most of the steps described by my good friend and colleague, Gary Hayslip, in his LinkedIn article, “So you want to be a CISO” (Jan. 17, 2015), and his five related, follow-up articles (Jan. – March 2015). I was actually executing the steps of a CIO and CISO before anyone knew what these positions were – it was definitely the wild, wild, west in IT back then.
So, now that I have given you some idea of the explosive growth in IT that we were experiencing, let’s discuss the security side of technology during this time period.
It was during this time, in the early-1990s, when we implemented our first Local Area Network (LAN) with 30+ PCs and one server. We had to design file structures to segregate different work groups and we had to manage user accounts and access rights. Since the city staff already had assigned user IDs, we had to create a naming convention for the contractors. Remember, at this time in the world of IT, there we no written policies or procedures related to IT management or security. The combined experience of myself, a network analyst, and a contractor’s system administrator, we proceeded to build our first network infrastructure. We defined user and group naming conventions, server directory structures & naming conventions for groups, user security groups, group access rights, system login requirements (including two-factor authentication, minimum password length, and password age/expiration – no ability to require or enforce password complexity), and system logging requirements (only for performance monitoring, not security). We also set up system administration tasks to be done on the server using its Unix-based VMS operating system, while the desktop PCs ran on MS-DOS with no client/desktop security software. It’s amazing, at that time, that we built this out with no industry guidelines and it actually worked!
Later, during another staffing expansion, which included multiple sites, the single MicroVax server was replaced with Novell NetWare servers at each location. This new network operating system provided several built-in security features, and also required IT staff to understand the platform and how to manage the five LANs across our new Wide Area Network (WAN). It was during this time of expansion that the first version of Windows was released; so, needless to say, the IT staff and I had to take new training classes, because again, technology changes proceeded to speed up and we had to support our users. I want to mention that at this time when Windows came onto the scene, we concurrently had a contingent of Macintosh systems, used for technical drawing and graphical rendering. It was at this point in my career, I started creating written internal procedures, documenting current practices for consistency across the IT staff, so expectations were set and system administration was standardized. I now had two staff dedicated to security and system management; still primarily concerned with internal security issues (i.e., someone gains access to another group’s files without proper authorization), and still no official designated security budget. In addition, we did create procedures for how and when a modem could be connected to a networked PC, including security precautions which would hopefully prevent unauthorized people from dialing-in and connecting to our computer or internal network. This was the birth of our cybersecurity efforts, on the cusp of the World Wide Web!
So it is here, as we are about to step into a new era of online computing, that I will defer the remainder of my article about how I have observed the progression of cybersecurity into today’s current cybersecurity paradigm. As I look back over the decades, a couple of sayings come to mind – “what goes around comes around” and “what’s new is old” (or vice versa, “what’s old is new”) – meaning that the underlying security needs in today’s environment really aren’t new, they’re just using different technologies (which will continue to change). Stay tuned for Part 2 of this article…
Blog written by Alan Watkins, Cybersecurity Consultant, Adjunct Professor for MS-CSIA Program, Member of InfraGard San Diego