Security Maturity: Geriatric Technologies
TL;DR / Summary at the end of the post. The information shared in this series is derived from my experience building the DevSecOps program at Thermo Fisher Scientific (a global Fortune 100 laboratory sciences company).
Full Disclosure up-front: I am employed as a Principal Security Specialist at GitHub at the time of publishing this blog post.
Recapping Security Maturity in relation to DevSecOps
With DevSecOps and Product Security gaining traction, security teams are quickly becoming essential during the design and build process. The maturity required from both teams and their technologies to integrate seamlessly with their colleague’s process(es) has changed significantly from the days of “put a firewall in front of it and call it done” - and it’s up to security teams to catch up.
As it stands today, Security Maturity - in terms of both teams and their technologies - can be measured across four stages based on the direction they’re heading in (forward ➡️ or backward ⬅️), and the outcomes they produce. I think of these four stages in terms of breadth and depth as follows:
Geriatric Technologies
Geriatric technologies are the darling products of years past: they are well known, designed to solve yesterday’s problems, appear in the “top right” segments of market analysis materials, and have probably been acquired by a hedge fund or holding company that draws as much revenue (with as little investment) as possible. You’ve probably experienced immature teams trying to force the implementation of these technologies at some point in your career.
Capabilities
Designed to solve yesterday’s problems, geriatric technologies perform decently well when addressing the challenges of slow moving companies beginning their DevSecOps journey. WIth geriatric technologies, the capabilities are generally “feature complete”, meaning they work as-is without room for change or improvement - and there are often several capabilities thrown together due to acquisition and conglomeration. Many geriatric technologies are touted for how easy it is for security teams to use (to the detriment of development teams).
One thing you can be sure of is that the capabilities offered by geriatric technologies are designed for yesterday’s model(s) of work. Stand-alone platforms with fancy dashboards, PDF reports, scheduled scans, agent installations, and resistance to integration are all hallmarks of geriatric technologies. These “features” inevitably make securing software at scale a painful process for both software development and security teams.
Ultimately the characteristic that makes these products “geriatric” is that they’ve abandoned the Unix principle of “doing one thing exceptionally well”. As a result, such technologies are often difficult to use at scale - and challenging to build automation and/or scripting around. Part of what pushes mature technologies into becoming geriatric technologies is a lack of investment in continuing to do what they’re great at - as well as failure to smooth out the wrinkles of integrating acquired technologies.
Don’t get me wrong - geriatric technologies were once the best in their field given when they were developed, and the challenges present at that time. A good example of this might be Binary Static Analysis, which was designed for a world where security teams didn’t have access to source code or the build process. These problems no longer exist in mature DevSecOps environments.
Implementation
Implementing geriatric technologies can be easy - if you’re working in an environment stuck in the year 2010. You’ll probably have to provide the geriatric technology with a username and password to access systems and information required for it to perform - because integrating directly into your source code management platform isn’t a feature such technologies were built to support. It’s almost as if they were built before a time where access tokens and API keys existed.
In all seriousness though, there are geriatric technologies today that need to copy over your company’s source code into their servers in order to perform scans - or require development teams to upload a compiled binary with debug flags enabled. Some even require an agent installation or IDE plugin in order to perform local scans before code is committed, which becomes virtually impossible to implement and validate usage at scale.
As stated earlier, geriatric technologies were developed at a time when technologies were substantially more fragmented and teams were generally silo’d. DevSecOps is about communication, coordination, and collaboration - which leads to less fragmentation and fewer silos. As a result, implementing geriatric technologies with modern software development practices is becoming an increasingly painful experience for adolescent and mature teams.
How to support this content: If you find this post useful, enjoyable, or influential (and have the coin to spare) - you can support the content I create via Patreon.️ Thank you to those who already support this blog! 😊 And now, back to that content you were enjoying! 🎉
Customization
Customization of geriatric technologies is practically non-existent, as the hedge funds and holding companies that often acquire these technologies are not invested in the research and development costs associated with making such capabilities available to customers. With geriatric technologies, you get what you paid for and nothing more. The only times you might get minor changes from the vendor are when a renewal is pending and customers make a lot of noise about problems with the product.
Data
Sometimes scraping data from geriatric technologies without visiting their web portal can feel like drawing blood from a stone. Even when you do navigate to the portal, you might be limited to CSV exports and PDF reports with “late stage” geriatric technologies. That being said, some geriatric technologies will offer API exports of data and integrations into selective tooling like Security Incident and Event Management platforms. Unfortunately this usually means the data remains silo’d away from software development teams who aren’t accessing the geriatric technology’s platform.
Most customers working with such technologies will find that they need to develop custom scripts and applications to both scrape and parse data from the platform in order to make the data useful. What this usually means for security teams is that they need to build and maintain custom reporting and dashboards in order to ingest and integrate all of their available security data. Developing and maintaining such things over extended periods of time will eventually become the problem of geriatric teams that often use the refrain “this is how it has always been done”.
Success
Success for geriatric technologies means holding onto as much Annual Recurring Revenue as possible while the hedge funds and holding companies bleed them dry 😅 All joking aside, success for geriatric technologies usually comes in the form of helping companies start their DevSecOps journey. The security team might be new or reorganized from traditional IT roles without experience in security. Geriatric technologies are a good first step when implementing security for such teams.
That being said, geriatric technologies will not help security organizations increase their maturity. Teams should quickly move on to adolescent or mature technologies as soon as they have the resources (talent, time, and money) to implement them. The impact at scale - i.e. the return on investment - that adolescent and mature technologies can have is absolutely worth it.
TL;DR / Summary
Geriatric technologies are the darling products of years gone by, and will help you solve yesterday’s problems if you’re with a company stuck in the year 2010 CE. With these technologies you’ll usually find stand-alone platforms with fancy dashboards, CSV exports, PDF reports, and a general resistance to integrating with adolescent or mature technologies. These “features” inevitably make securing software a painful process for both software development and security teams.
Likewise, when it comes to implementation, geriatric technologies behave like a product of the times they were developed. Sometimes you’ll need to establish a service account in order for the product to integrate, and in a handful of cases you’ll be able to use API keys or access tokens as an interface between the security technology and development platforms. Either way, the real challenge with geriatric technologies will come when trying to implement at scale.
As for customization, you’ll be lucky if you have the opportunity to customize beyond selecting which rules you scan for - or changing finding severities. Writing your own custom rules is out of the question for nearly all geriatric technologies today, and this limitation will significantly reduce how effective your team could be. Although I’m sure the vendor will happily charge you for proprietary rules they’ll develop on your behalf.
And when it comes time to review your findings, you can expect them to be locked into a proprietary platform with dashboards - or to come with limited APIs that make the process of exporting data challenging. But hey, at least you’ll have a CSV export and PDF report available to you in the platform, right? I should add that some geriatric technologies are coming around to the prospect of integrating outside of their silos, but such integrations hardly make up for the volume of false positives they produce - or the lack of custom rules.
Finally, what makes geriatric technologies successful is the annual recurring revenue they bring in for their hedge fund or holding company overlords 😜 All joking aside, such technologies could make for a good first step when starting a DevSecOps program - so long as teams recognize how limited geriatric technologies will be in terms of growing the company’s security maturity.
If you’re looking for a way to start your DevSecOps journey, you could do worse than choosing geriatric technologies as part of your initial investments. Just know that doing so will limit the security maturity that could have been achieved with adolescent or mature technologies - which are both easier to implement in modern DevSecOps environments, and generally produce more actionable findings.
As always, thanks again for stopping by to read my pseudo-random musing 😊 While I prepare my next blog post on preparing for the Offensive Security Certified Professional (OSCP) certification, you can git checkout other (usually off-topic) content I’m reading over at Instapaper - or read my series on the DevSecOps Essentials if you want to learn from my mistakes when starting your journey into DevSecOps.
Until next time, remember to git commit && stay classy!
Cheers,
Keith // securingdev
If you found this post useful or interesting, I invite you to support my content through Patreon 😊 and thanks once again to those who already support this content!