As a manager in cybersecurity, how can I help my junior team members move away from rote learning?

This is a question for the ages and has been asked, many times in different Iterations

The short answer is:

"With time and experience"

Now for the longer answer:

What you are asking for, I can recall examples going all the way back to Roman Graffitti, in Latin. Whereby one generation looks at the newest generation and goes 'Why don't they get it?!?'. This cycle repeats, ad infinitum, ad nauseum.

So, in one sense I am saying "You are being too harsh".

But that is more a philosophical answer, than a practical one.

For the Practical answer - I would suggest setting them challenges that require thinking outside the box.

I will use an example - I have kids and every Saturday, we tidy they house. I am now at the point where I will simply tell them whether it is tidy or not (up to my, admittedly low, standards) - My Eldest gets frustrated because they want me to tell them what needs doing - but I simply reply that there are things they have missed and they need to figure it out.

I am, in essence, training them to think outside the box. We have moved from "Put your clean clothes away" - which will result in the clean clothes put away, but wrappers, mess, dirty clothes etc. still present to "Tidy this room" and letting them work out all the required sub-jobs that are required for a room to be considered 'Tidy'

So, I would suggest assigning them some training tasks - ones where you have a number of known exploits, but perhaps not in the manner they are used to - and then letting them struggle to figure it out (thus learning the meta-idea of thinking creatively).

I find Bloom's Taxonomy helpful to talk about the different kinds of "understanding":

(image courtesy of Wikipedia Commons)

I like this taxonomy because it highlights that different levels of understanding are required for different activities. For instance, if a student is only ever asked to "recall facts and basic concepts", they can do that without understanding, and while some students may seek out a deeper understanding of their own, without a clear signal that a deeper understanding is valuable, the more efficiency-focused students will not ...

Similarly, if your recruiting process only asks people to remember things, it won't test their ability to understand or apply. If it is important for your juniors to be able to understand or apply, the job interview should have tested these skills.

To elevate the understanding of your juniors to a higher level, you must therefore ask them to engage in higher activities:

• To get them to "understand", ask them to explain the concept of an Insecure Direct Object Reference in their own words. What is a "reference"? What is an "object reference"? What makes the reference "insecure"? What does it mean for the reference to be "direct" and why does this matter?

  Then I'd follow up with some classification tasks: Does the following code use object references? Where? Are they direct? Are they secure?

• To get them to "apply", the key step is using information in new circumstances. For instance, if your initial examples were multi-part forms, ask whether Insecure Direct Object References could also occur with JSON, SOAP, or URLs. What would vulnerable code look like?

(btw, similar questions can also be used to assess a candidate's level of understanding in a job interview)

And once they can solve these tasks, they should be in the mindset of actually applying rather than merely regurgitating a definition, and understand IDOR as a concept to be applied rather than a definition to be regurgitated.

How do I improve my [junior] team members intuitive understanding in this regard?

As with any and all juniors I dare to say, with some time, coaching and feedback as you seem to be doing.

The know-how and the outside-of-the-box (outside-of-the-book in this case hehe) come with experience and practice. You seem to be doing well in assuming a "teaching" attitude with juniors, so they not just do what the job/task requires, but encourage them to think beyond and learn from each task and project they work on.

As you all may know, I have a Software Dev background, but another DarkCygnus fact is that he also teaches to CS student at a local university :)

In recent years, I have felt a very noticeable change in the learning process and attitude of students (aka, future juniors). I mostly attribute it to the post-Covid impact on remote education, remote working and the advent of GenAI in recent year/months (I wonder if they use the University's Library anymore...).

This I feel also translates to juniors now days, specifically to the way they learn and build up experience. I also feel that critical thinking and self-learning are facing some challenges due to the points listed above, so we have to adapt to it to ensure students/juniors develop critical thinking and pattern recognition and not just "spit" textbook answers (or GenAI answers...).

Perhaps you may also want to have some sort of track of their progress, so you can objectively compare how their "intuitive understanding" is growing.

You can also think of it has being a HR (Human Resources) problem.

(which also means you can call in HR to help, if you have that in your organisation)

Is the team mix correct?

To consider whether you have the right mix of people, and whether those junior people have the skills you need.

Does the team have enough time to train/coach the junior people and do the day to day work? Are there too many juniors compared to experienced people? Are the juniors helping each other?

In the past, I've found it very hard to explain to my management that training/coaching/checking new people might take up 20-30% of my working day. And that adding 3 junior people will result in a drop in output for 2 to 3 years until they become middle people. (I've always worked in very small teams)

Are the juniors you have the right kind of people?

Like part of the job is being really interested in the job, and to read and learn. To expand their knowledge.

Cyber security is constantly moving, and so practitioners have to keep up to date.

If you read code, then you also need to be reading the programming language documentation - some of those functions don't behave exactly as you think.

They need to be reading Krebs, LWN (if you have linux systems), ars ...

Not work stuff

Do these people have their own websites? Own email? Can you pay for free VMs for people?

Do they have raspberry pis on the desk in front them? Have they tried getting root on the office phone system?

Do Advent of Code as a group competition.

Can you get them to clone your door entry tags?

Do this in work time.

(I'm think of a time we had a vague reported security problem with an IOT product, and one of my staff rooted the device, got a shell, examined the code and found the problem)

Is the job specified correctly ?

From hiring through to promotion. Is learning part of the job? Is being creative part of the job?

That it is fine to come in as a junior, but you can't still be a junior after a year.

And also explain the job prospects for the future. Explain to people that there is way more future as they move on. Set goals, and explain how their pay will improve when they reach the goals.

Makesure the pay and vacation match the job. Make staff take a paid week (or 2) off each year, see who you miss and who you don't.

• To think about threats that haven't ever been discovered yet.
• To reason about best practice across the business and find ways to educate the developers
• To understand compromises
• To learn to be creative
• Take responsiblity for their actions
  • accept the will mess up sometimes, and support them when they mess up.
• To not be scared about the unknown
• and to work with the boss, understand the problems the boss has and help
  • does the boss need help with ideas or just executing his plan

A related example - many "code schools" dish out people who spent 6 weeks learning python/javascript + similar tools. But these people just work the keyboard. They aren't trained to solve business problems. They look amazing at coding, but somebody has to tell them what to do all the time. Great in a huge team, tricky in a small team (less than 4)

and Finally

If you have team members who are a net drain on the team, even after (say) 6 months in service, then they are not performing. They are redundant. Once you have explored all the reasons for not performing, then you need to uninstall them. Which can be done nicely, politely, legally, and with 2 or 3 months of severance pay.

(sometimes they have done nothing wrong, and you have done nothing wrong, but it's not working)

If you don't, then you are just moving the problem on several years.

Smaller teams are usually easier to manage. And expect the rest of the team to improve.

also

Don't hire boring people. Hire people with something about them. A mix. Consider older people, people who need part time because of family. People who got promoted to management but realised they are doing things people rather than people management people.

You might have some nightmare staff who are amazing. They can do amazing work, but can't manage to find socks to wear, backup their code or fill in a timesheet. Keep them, but get a team PA.

You might just need some older people on the team to quietly keep an eye on things.

The other answers are both good, and I suspect they're right that there's no easy way to go straight from the "rote" mindset (as you describe it) to better understanding - time and experience are the best way to get there. That said, I'd like to share my perspective.

Formal education encourages students to adopt a mindset of "what will I be expected to know?" It took me a long time in my own career to lose that habit, and instead ask, "what is it possible for me to find out?"

I don't mean that in any inspirational or rhetorical sense, I mean it as literally as possible. Very often, the only way to progress on technical problems is to gain information whether or not there's any expected pathway or canonical approach for you to use to find it out. Academia gives you puzzles that someone designed with an intended approach and solution, while in the industry, the puzzles just arise in and of themselves. In security, it's even more pronounced: someone may be intending for you not to solve a problem, so it's even more important to be able to do it.

Here's a puzzle from The Guardian. When it was originally published, it was with a claim that over 80% of people tended to get the wrong answer. Even armed with this knowledge, over 72% of the readers who answered were still incorrect.

Jack is looking at Anne, but Anne is looking at George. Jack is married, but George is not. Is a married person looking at an unmarried person?

A: Yes

B: No

C: Cannot be determined

The answer is:

A: Yes.

Most people reason: "a married person is looking at an unknown person, an unknown person is looking at an unmarried person, not enough info, QED" and pick C. This is the "what will I be expected to know?" mindset - you apply your list of discrete, enumerated techniques you're allowed to use, come up short, and decide it can't be solved.

With the "what is it possible to find out" mindset, you might think about it a little more. You might think about the two exhaustive possibilities - that Anne is married, or she is not. If she is married, then Married -> Married -> Unmarried, so the answer is yes. If she is unmarried, then Married -> Unmarried -> Unmarried, so the answer is yes. Either way, the answer is yes!

Suggestions

I don't know how much these will help in your particular case, but I think it would have helped me if someone had explicitly used these framings when I was a junior dev.

1. Encourage honest and partial answers. In education, when you don't know the answer to a test question, confidently guessing has a higher chance of reward than open, qualified confusion. In industry, this is exactly backwards - getting as far as you can from first principles and then saying "I don't know, but it seems like Z based on X, although if so then it's weird that Y" is massively better than just saying "it's Z!" or "it's A!" and hoping you're right. Make it clear that when you ask the juniors these things, it's not a pop quiz - it's a discussion.
2. Remind them to think like an attacker. Since you work in security, you're no doubt more familiar with this principle than I am, but it still bears repeating when working with junior engineers. It's all fine and good to know the canonical lists of best practices, but what matters is the behavior they prevent. When they see Vulnerability X from the pentest, make sure their next thought is what they would do with that vulnerability if they were a bad actor. If you start imagining yourself inserting records into the database, it's a lot easier to understand that you're looking at SQL injection.
3. Encourage ownership. This may be more of a broad strategy than an individual tactic, but in general, your goal should be for your junior engineers to gradually move away from thinking of themselves as executing the steps of their role, and towards thinking of themselves as fulfilling the ultimate goal of their role - even if that means going out of bounds of what they were asked verbatim to do.

Assign them tasks where they need to apply this skill.

Performing a task where you have to produce something (that your boss will review) can feel very different from completing a task and then having your boss interrogate you about some theoretical aspect of it. The incentives are very different. If you get asked hard questions during the interrogation then it is briefly uncomfortable and there is very little you can do about the immediate discomfort. If you have a tricky assignment then you have an extended period of discomfort with lots of opportunity to do something about it. Team members who are struggling will have plenty of time to ask their boss, google it, or whatever.

Personally, I think it also shifts responsibility more clearly onto your team members. Instead of feeling like "my boss keeps asking irrelevant theory questions" it becomes "I need to do X as part of my job role".

Once they've applied the skill a few times they will have acquired it.

I have a team of 10: 5 juniors AppSec engineers, 3 mid-level engineers and 2 lead / senior level engineers

Other answers have concentrated on suggestions for making your juniors better. However, I want to make an observation about your team: you have too many juniors for the number of seniors. Two juniors, five mid-level, and three senior would be a better mix. Or even three juniors, five mid-level, and two seniors, but that would require you to act as a senior, which may conflict with your other responsibilities.

With five juniors, that means that each senior has to mentor two juniors and you have to mentor the fifth. As a result, your juniors are spending a lot of time without supervision, and I suspect that the three of you supervising feel like you're spending too much time doing it.

It's conceivable that you might be able to promote some of your mid-level to senior and mentor them to act as mentors. However, a better solution would have been to avoid the problem in the first place. You should not have hired more juniors than you have seniors. Perhaps three juniors to two seniors if you were trying to promote a mid-level to senior (so that you'd have three seniors).

I would suggest rethinking your task division. If you can only give your juniors rote tasks, then encourage your mid-level and seniors to give them the rote portion of their tasks. Encourage your mid-level engineers to pair with the juniors, giving them tasks that seem rote. Meet regularly with your mid-level engineers so that you can mentor them in how to mentor juniors. That would often be a better use of your time than directly mentoring juniors.

It's also conceivable that you're simply hiring the wrong people. Maybe these are people who never will have more than a rote understanding.

As already noted, it may be that you have to let some of your juniors go. If you let one junior go and bring in one senior, you will have a better mix. Or let two juniors go, bring in one senior, and you will have balance (and may balance the budget too, if a senior costs as much as two juniors).

Hiring three seniors would also fix your balance but may not be in your budget.

You'd prefer to promote your juniors to mid-level, but that would be easier if they were getting sufficient supervision. I'd suggest picking the one who seems farthest along and concentrating on that one. If you can promote one to mid-level, you'll be in a better position to avoid letting people go or at least minimize the number.

You might also look to see if you have a class of rote tasks and a junior who's especially good at them. Assign the entire class to that person and have them proceed without supervision. That's essentially acting as a mid-level. That would improve your mix. If you can promote one junior to a regular mid-level, one to a rote mid-level, and one mid-level to senior, your mix would be balanced without hiring or firing.

What has worked for me in the past is having sessions where everyone provides practical knowledge.

You can decide on themes, or topics, and ask everyone to present something - then you get the chance to teach them real-world examples of incidents, and they get the chance to teach you whatever they find interesting in their world...

and it becomes a bonding opportunity as well as a teaching moment.

You need to make clear to them that their job is not to find vulnerabilities that can be found in the textbook and have a name, but to find vulnerabilities and threats against your software.

That’s because their hacker counterparts are paid to find vulnerabilities that are not in the textbook. So if you fix every problem from your textbook you are still deeply vulnerable against any new attacks.