Security Maturity: Adolescent 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 Code Scanning Architect at GitHub at the time of publishing this blog post.
Recapping Security Maturity in relation to DevSecOps
With growing adoption of DevSecOps, security is starting to become part of the design and build process; the maturity required from both teams and their technologies in order to integrate seamlessly into this process has changed significantly from the days of “put a firewall in front of it and call it done”.
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:
Adolescent Technologies
Adolescent technologies have graduated from being popular to something worth spending time and money on in order to implement. But be warned: many companies selling adolescent technologies will offer extremely low pricing to acquire new “logos” for their next venture capital pitch (or acquisition), and if you’re not careful you will pay for it with your team’s time and attention; for how long is largely a measure of how quickly the technology matures, and the maturity of your team.
Capabilities
Adolescent technologies wouldn’t show some maturity if they didn’t provide a novel take on solving real problems that their customer’s experience. As such, you expect them to have capabilities that go beyond duplicating an existing solution - which we still see a lot of with Semantic/Static Code Analysis.
Even so, one thing I always look for in adolescent technologies is how extensible they are via their API. Being able to write configurations and distribute the solution via scripting is a strong indication of growing maturity when measuring a technology’s ability to reach enterprise scale. This also means that adolescent technologies need customers with the skills of at-least an adolescent team, if not team(s) with greater maturity.
Moreover, if an adolescent technology has found ways to be useful beyond their immediate problem/solution fit within the market, then it is definitely reaching the early stages of what I would consider a mature technology. The biggest thing keeping adolescent technologies from reaching maturity is the simplicity and elegance that mature technologies possess when solving problems at scale.
Implementation
When it comes to implementation, adolescent technologies may be challenging for immature teams to fully utilize. This is partly due to the novelty of adolescent technologies, which sometimes requires skill development on the customer side. The ease with which these skills can be developed or hired for is a leading indication of how mature a technology is.
Likewise, implementation may require collaboration with other stakeholders in order to deploy at scale - which is again something that immature teams struggle with. For adolescent or mature teams, coordination and collaboration to select and deploy the technology will largely ease implementation friction. And as I said in the “capabilities” section - having an API that can be scripted to make deployment repeatable and scaleable are what I’d consider “table stakes” for implementing adolescent technologies.
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
Among the characteristics that make adolescent (and mature) technologies stand-out from immature and geriatric technologies is the level of customization they offer. The flexibility to easily cover customer-specific use cases allows for adolescent technologies to be adopted by a larger audience. In this regard, the major aspect that differentiates between adolescent and mature technologies is how much customization is required, and how easy such customization can be implemented.
That being said, customization may require domain specific knowledge that customers need to learn in order to maximize the impact of their investment. As I stated earlier, the ease with which this knowledge can be acquired is a good indication of how mature the technology is. Often times, adolescent technology companies will offer professional services in order to augment this shortcoming.
Likewise, the presence of coherent documentation around customization - and open source examples of how to use the customization to resolve edge cases - are noteworthy in both adolescent and mature technologies.
Data
Consuming information that adolescent technologies produce can sometimes be challenging for immature and geriatric teams because such technologies often lack robust visualizations and reporting. To make up for this - like immature technologies - adolescent technologies make their data available via API and/or WebHooks in order for customers to utilize the information in their own Security Incident and Event Management (SIEM) or Business Intelligence (BI) platform(s).
The challenge for immature and geriatric teams is that setting up scripting and/or automation to consume the data produced by the technology can be difficult to build and maintain without the right skills on the team. This isn’t so much a shortcoming of adolescent technologies, as much as it is a reflection of the team(s) using the technology.
The good news is that - at least with adolescent technologies - there are generally some visualizations and reporting available for customers. This investment is a distinguishing point between immature and adolescent technologies, but often leaves customers wanting - thus falling back on APIs and/or WebHooks for additional data.
Success
Adolescent technologies measure success through the outcomes they produce for customers once they’ve overcome implementation challenges. The real value in the product is the impact it can have at scale, and the biggest thing distinguishing adolescent from mature technologies is how quickly and easily customers can pass through the implementation phase and start seeing a return on their investment.
Likewise, adolescent technologies start showing growth when they convert popularity into a community experience. The presence of blog posts from 3rd parties, tutorials from online streaming services, and forums (such as subreddits, Discord servers, or other dedicated communications channels) all represent a growing consensus around the technology’s value and impact at scale.
TL;DR / Summary
Adolescent technologies have graduated from being popular to being useful, and are thus worth spending time and money on. That being said, adolescent technologies should come with a warning: companies selling such products will usually offer bottom-of-the-barrel pricing to acquire new “logos” for their next venture capital round (or to increase their value in an acquisition). You will pay for this low price offer with both time and attention from your team, and how long you pay for it is largely dependent on how quickly the technology matures - as well as how mature your team is.
That being said, novel capabilities offered by adolescent technologies are usually worth experimenting with. If the technology has an API (or WebHooks) that allows for scripted deployment and data aggregation - and if you have an adolescent or mature team with the skills to use it - then you will likely find your investments having an impact on the problem you’re trying to solve.
Even with an available API or configuration for deployment, implementation of adolescent technologies tends to be a point of friction when trying to scale. Collaboration and communication between security teams and their stakeholders is often required to successfully make it past this phase, and immature teams will struggle here. Moreover, customization of the solution may require skill development within the security team in order to fully utilize the solution. The ease with which customers can hire, train, or pay for services to customize the technology - and the volume of customization required - is a good bellwether for a technology’s maturity.
When it comes to measuring return on investment, most adolescent technologies will offer at-least minimally useful visualizations and reporting around the data they generate. That being said, like immature technologies, to get the most out of the solution companies often need to ingest the full data set via API (or WebHooks) - which requires a certain set of skills that immature security teams often lack.
Finally, signs of increasing maturity around adolescent technologies will come in the form of a “community” growing around the technology, which will ease many of the implementation and customization challenges customers experience. Adolescent technologies are successful when they produce valuable outcomes at scale for their customers - which further grows this community. Again, the greatest friction point for adolescent technologies will be from implementation - but once a customer has moved past this challenge, they can expect to reap many rewards from their investment.
As always, thanks again for stopping by to read my pseudo-random musing 😊 While I work on the next blog post about Mature Teams and their Technologies, you can git checkout other (usually off-topic) content I’m reading over at Instapaper, or read my DevSecOps Essentials series to get started on your journey.
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!