Can you program in COBOL?
Do you have any idea how many lines of COBOL code you have in production? What about Fortran?
Any clue how they impact your security program?
Considered cutting edge half a century ago, these languages are essential to systems in production, but no longer actively taught. That prompted BusinessWeek to ask “Who’ll keep your 50-year old software running?”
A topic of discussion in the last DtR Security Newscast, stories like this are designed to capture attention (and page views). The hidden benefit of these articles is the opportunity to explore the premise through a security lens. A signal to consider the impact of actions, decisions, and events.
High priority? No. Important to consider? Yes.
Success in security requires awareness of multiple issues (proper awareness - it doesn’t necessitate understanding) with the ability to bring them up at the right time, with the right people. That also means considering internal changes or pending shifts that impact security.
The improving economy suggests the potential for key staff to leave, prompting at least a quick review of our preparedness if that happens (are you prepared?). Now we have another aspect to consider: an aging workforce with legacy knowledge and experience.
When it comes to systems built in languages developed before some of us were born, what is the impact as our workforce ages? According to the BusinessWeek article, the bulk of folks with that skill set are in their 50s and eying retirement -- setting the stage for our next crisis.
I don’t see it that way.
I suspect a good number of the people we rely on to maintain these systems are 10-15 years from retirement. I also know a lot of my colleagues quietly admit to knowing at least COBOL (but are probably updating LinkedIn right now). COBOL is far from obscure. If the market demand (and salary) rises, crisis is likely a generation off.
Yet we need to ask some questions and consider changes today.
Aging coders mean reconsidering assumptions, priorities
Seems like only yesterday we finished a long goodbye to the Windows XP operating system (mostly) with the important security lesson that we need to do better at questioning assumptions when building new systems.
The real reminder in the article is that we have systems running COBOL and Fortran (among others). Especially when it comes to incorporating better methods of prevention - detection - and response.
- How do those systems factor into our security programs?
- Are these systems identified? Are they prioritized?
- Do we need (and have) special skill sets to handle them?
While we can consider the answers to these questions within the security team, the key is expanding the conversation to the business leaders and executives that depend on these systems. That helps us gain an understanding of priority -- and ultimately helps us find the funding to make changes (meantime - do these 3 things to get the security budget you want).
Expand the conversation with these questions
These are the sorts of conversations we need to initiate within our organizations and throughout the security industry. The opportunity for us to learn comes with our focus on listening. Instead of telling people the problem, frame the situation and then ask them what they think the challenges are, if any. Use articles like these to start conversations and questions like these to get the responses started:
- What systems are we depending on that rely on legacy languages, operating systems, and technology?
- How are coding requirements and support addressed in your requirements and contracts?
- What plans, if any, are there to migrate and upgrade these systems? How can security help?
- Does an aging workforce and legacy technology push us toward cloud-based solutions?
- Do we need to consider an emphasis on functionality and the adoption of open standards and techniques that allow us easier pathways to migration in the future?
As we tackle this as an industry, what other questions would you ask? If you’ve already tackled challenges like this, what lessons can you share? Leave a comment, take it to twitter (@catalyst), LinkedIn, or drop me a message and let me know.