The Weekly Hotwash: May 8, 2020


Estimated Reading Time: 3 minutes

The Broken Hiring Process

Many of you read my prior rant on the hiring process in the tech industry. This week, an article in the NY Times was published not just criticizing the tech industry, but the entire hiring process. A well-respected Wharton organizational psychologist has studied over a century of job interview questions and techniques and has empirical evidence on precisely how bad the hiring process has derailed. He calls out the legacy of poor evaluation criteria which leads to passing on those who are actually a very good fit with great future potential.

I also found the ‘credentials vs motivation’ topic strongly persuasive. As I’m sure most of you have experienced at one point, there is a (very) long-standing debate in the InfoSec world of the value of certifications – our version of industry credentials. Does the fact that someone has five or six different ‘open book, pass the test’ certifications mean they are better suited to the role than someone whose taught themselves python or built and mastered their own pen-testing suite?

To me, the latter is far more of an ideal candidate, one who shows not just motivation, but the ability to figure out fairly complex topics for themselves. I have found over the years that this self-sufficiency is a far more valuable indicator than anyone who can pass an open-book test. This recent piece provides some insight into additional indicators to look for when trying to fill those challenging roles.

Finally, as with anything else, the old adage ‘you get what you pay for’ applies to the hiring process as well. Part of our challenge when it comes to hiring is balancing how fast the new hire can contribute vs the budgets we have. As I’ve said, experience matters, but having team members with varying degrees of experience is critical to the long-term planning of every security program. Yes, I absolutely need to have experienced leaders on my team to guide the individual efforts that make up the holistic program.

However, I also need the right balance of less experienced resources to make up the entire cadre of talent. As an example, I often look to my first-line SOC analysts as my future architects and engineers, using the experience they gain as part of that entry-level position to define and develop a career path where they are the future managers and leaders of my teams. Having this balance of experience and youth is truly a critical factor in long-term employee retention that cannot be overlooked. This piece from last week is a good read on the youth-vs-experience comparisons you should consider.

Secure software development

Recently, NIST formally released its Secure Software Development Framework (SSDF) which can be incorporated into any existing Software Development Lifecycles (SDLC). The goal of the NIST SSDF is to provide a common set of fundamental practices that should be incorporated into any software development practice in an effort to mitigate many of today’s threat vectors.

Integrating security into the AppDev process has always been a challenge, relying mostly on awareness efforts and training. However, with many of today’s modern tool suites, static code analysis can be built right into the coders Integrated Development Environment (IDE). That said, in most modern enterprises, there is not a single development platform or language, but many. While each language and IDE have their pros and cons, the wide variety of them through the development teams causes roadblocks for any standard Secure Development process effort. Just consider for a moment how different the development process is for a new mobile app compared to developing new screens or reports for that 15-year-old ERP system you have buried in your infrastructure. Not only is there no common vernacular between the two, but the development process is also completely different.

This brings us to one of the biggest benefits of the new NIST guidelines is the development of a standard maturity model across all development efforts. By implementing such standards, each development team can be measured independently to identify risk vectors that are specific to their projects and environments, rather than being asked questions – or worse, being forced to take training – that has no bearing on their specific processes and practices.

Vulnerability costs
Source: IBM

According to IBM, the cost to fix a security vulnerability after the code was put into production was $7,600 compared to $80 when found during the development lifecycle. Imagine how you can use those numbers when you’re asked the question… ‘Where’s the value add?’

The Chronicles of a CISO Weekly Hotwash is a recap of critical stories and news that occurred over the past week. The goal is to hopefully share some insight and perspective on how these stories may impact our industry, our careers, or our companies.

Copyright © 2002-2021 John Masserini. All rights reserved.

Leave a Reply

Your email address will not be published. Required fields are marked *