3

I work as the team lead on the IT Security team where I work. I have close to 8 years of experience in cybersecurity.

Recently a junior engineer joined my team. He changed IT domains from development to cybersecurity, having previously worked as a developer for 3 years. He has worked with some tools that are also widely used in security field such SonarQube or Nessus, but only in his previous role as a developer.

The engineers on my team are responsible for conducting penetration testing of applications, company network, firewalls etc. As planning before pen testing is extremely important, today I was reviewing with him the OSI model and its 7 layers , and exploring the various attack methods that a bad actor could use at each layer.

Abstract concepts such network port to port communication streams, hashing input and output representation , and encryption keys intricacies seem to be very difficult for him to grasp. I drew pictures which helped only to a limited extent. The new team member still had some confusion even I explained these concepts using alternative phrasing.

For someone new to an IT domain, how could I explain abstract concepts in my work domain so to be easier to understand for a newcomer?

4
  • 1
    Send him links to some tutorial websites so that he can learn the basic concepts by himself before any meetings. This way he can prepare well for the meetings. BTW, who hired him ? The person who hired him should have known that he does not have basic knowledge of the security IT domain. Thus, either he should have not been hired or he should have been given some time to catch up with the domain knowledge on the job. Sep 14 '21 at 6:01
  • 3
    You said he had 3 yaers experience as a developer... what is his education? What did he do before those 3 years? I would expect those concepts to maybe be a bit rusty, but definetely known to anybody with a solid background in CS.
    – nvoigt
    Sep 14 '21 at 6:33
  • 1
    @nvoigt, Bachelors from a legitimate university in the USA. Educational background was honestly presented during background screening prior to hire. He did an internship at another place prior to joining and his major in uni was EE.
    – Anthony
    Sep 14 '21 at 14:14
  • 1
    @Anthony BS in EE and newbie with no understanding of networking wanting to be in cybersecurity? Well, there's your problem! The poor guy has a lot to learn. Do guide him to some self-learning portals. If he was my colleague, I'd also seriously ask him to get a certification like CCNA - learningnetwork.cisco.com/s/ccna-exam-topics - so that he not only learns but also increases his potential value as an employee by getting certified. (BTW, Kudos to you for taking the time and interest to train him. Not everyone is so patient).
    – sfxedit
    Sep 14 '21 at 22:28
11

I've trained quite a few people during my career in new domains and technologies and the approach I eventually settled with was the following:

  • start by creating a learning plan. A journey if you wish. Don't just give them some concepts to learn, or explain some notions, give them a roadmap that shows what the progression should be and why that progression is important. There is not just learning topics, or tools, or whatever it is, it's also very important how all of those fit together. Start with this first.
  • then allocate time for the training. As already mentioned in the comments, whomever hired them hired them (hopefully) because they knew they could do the job and can learn whatever else they didn't know. But for them to learn, they need to be allocated the necessary time. Figure out how much time is needed or you have available for this training. You need to provide "the space" for them to learn, you can't just pour information in their head (which is somehow the approach you are describing in your question). Pushing information to them instead of them pulling it for themselves will just get them overwhelmed, confused, and stressed and will not provide the results you are expecting.
  • also think about how much time you will need to figure out if they are making progress or if they never will. Hiring someone because you think they can do the job and then the person actually doing said job are two different things. Obviously, any new employee will not hit the ground running and expecting them to do so is ridiculous. But at some point they need to pick up speed. Some never do, no matter how much time or help is given to them. So be mindful of this and watch their progression. At some point you might have to give up. Figure out what will be the criteria on which you decide to continue with the training, and when it's time to give up.
  • together with the training plan, maybe give them some resources where they might learn about each of the topics. Be careful though, in my experience people will resume themselves to those resources and not look up more information when they don't really grasp a subject. Sometimes you might give them a book that talks about some topic and they think they need to read the entire book from cover to cover, spending a disproportionate amount of time on only one topic. I always gave people just introductory material and said that it's a starting point and they should figure it out for themselves. You basically want to teach them how to fish, not give them the fish.
  • remain at their disposal to answer questions or explain stuff. Make sure there is always a communication channel open between them and you. Even if you are in meetings or busy doing something else, there must be a place for them to go and leave a question or ask for help. A group chat, email, or a forum or wiki when it's not face2face. These can then also help you train other juniors if needed (the forum for example, or the wiki).
  • do periodic checkups. You make yourself available to answer questions and offer help, but some people might insist on figuring everything out for themselves. That is a good approach, but at some point they go overboard with it instead of asking for help. By checking up on them periodically you avoid them getting stuck for too long. Decide on how much time you are willing to allow them to be stuck (not too short, not too long).
  • when they ask for help or you check up on them, ask what they learned and have them explain it to you. Look for gaps in their knowledge and either explain more or give them pointers to help them fill the gaps. Your should try to act more like a coach at this point rather than a trainer, in the sense that you should try to ask them appropriate questions that make them figure things out by themselves or find solutions on their own instead of just telling them how it's done. There needs to be a balance here also, obviously. At some point tell them if you see they can't figure it out.
  • then repeat the previous three points until the training period is over and they have either learned most of the things you considered they need to know, or you give up because things aren't going well (which hopefully won't happen if your company did a proper job in the first place in hiring them for the position).
1
  • +1 I would only add this: depending on the type of person you're facing, a regular training or a book might have very different results. Buying your employee a simple book and letting him self-train 1, 2 hours a day might be very effective or totally pointless. Ask them if they're into books, then select a good entry-to-intermediate level book for them if they are.
    – Mahboi
    Sep 14 '21 at 16:54
4

Assign some training videos/courses

Linkedin Learning and Pluralsight offer a wide variety of instructor-led videos and courses that teach exactly those fundamentals while providing hands-on experience. They usually have labs and assignments where he can work on examples.

Networking Basics: This course covers:

  • The OSI Model
  • TCP and UDP
  • Intro to Binary and Hexadecimal
  • Intro to IP Addressing
  • Subnetting
  • Ethernet and Switching

Penetration Testing with Kali Linux Assign him a course where he'll conduct a penetration test of his own so he'll gain the experience.

  • Information gathering
  • External Pen-Testing
  • Website Penetration Testing
  • Internal Network Penetration Testing
  • Network sniffing
  • social engineering
  • brute force attack testing

Introduction to Firewalls

  • Network Address Translation (NAT)
  • DMZ
  • Non-TCP protocols
  • Next-gen firewalls

Cryptography Principles for IT Professionals and Developers

  • Hashing
  • Symmetric Encryption
  • Block Ciphers
  • Asymmetric Encryption
  • Public Key Infrastructure
  • Certificates
1

You are not a professor

First of all, I doubt that your company wants you to spend so much time teaching someone basic concepts of cybersecurity. You have your job as a team leader and occasional mentoring is fine, but that cannot go over few hours a week at most. Otherwise, you would be jeopardizing your primary job.

Second, looks like your "apprentice" is not a sharpest tool in a shed. There are several telltale signs, but most concerning is his switch from development to IT security. Or in other words, looks like he failed as a developer, and now tries to be security engineer. It is unclear who hired this guy (were you involved at all ? ) but he seems to be a bad pick. Of course, lot would depend on local hiring market and reputation of your company, but it looks like you got yourself a reject.

Anyway, question is what you could do now ? Above anything else, prepare a list of most basic theoretical concepts he must learn on his own. If company allows it he could study at work, if not he must do it in his own free time. This does not need to be some long list or profound knowledge, but he must understand the basics. Again, you are not his teacher and this is not an university, so he has to do it by himself. Then, take some time to show him some basic tasks he could do. He could first watch you do it, and then try on his own. If it does not bother you, you could let him watch you do some more complex tasks in a hope he will grasp something. To repeat, do not teach him the theory, focus your limited mentoring time on practice.

What to do if he fails ? You must understand that his failure is not your failure. You are not university professor, teaching is not your job. You simply got a bad fit for a position. Get rid of him as fast as you could, it would be in your and eventually even in his best interest.

8
  • 2
    Why would a switch from dev to security be in and of itself a bad sign?
    – jcm
    Sep 14 '21 at 12:20
  • I interviewed him and he reports directly to me. His development portfolio appeared well done. It's his IT skills outside of coding, such as planning / architectures seem poor
    – Anthony
    Sep 14 '21 at 14:17
  • I agree with the rest of your post, but I don't think switching to security after getting some dev experience means the failed. Seems like a legit specialization to me. First get any job and some experience, then find out what you want to do and specialize.
    – nvoigt
    Sep 14 '21 at 14:22
  • @jcm Because after 3 years he would not be a junior developer, he could expect pay raise, more interesting projects etc... But apparently he cannot grasp basic concepts like hashing, which frankly any developer with some knowledge should know. It all sounds fishy, and my hunch about this is that we have failed developer who wants to switch careers.
    – rs.29
    Sep 14 '21 at 18:31
  • @Anthony Well, you know the guy better than I, so you could have asked him why sudden switch in career. And development is not just coding, he should have at least basic concepts about architecture of IT systems (both software and hardware) . What is most worrying is his inability to grasps these basic concepts even after you explained to him.
    – rs.29
    Sep 14 '21 at 18:36
0

I've done something similar, but for myself.

Starting from the basics ( OSI layers ) is important and more important is to take a look to owasp top 10 to understand common problems.

I'm not an expert on pen testing, but I've understood in a month or less basics and able to work on this topic, review code and try to resolve this kind of problems before production.

Also sonar is a nice guidance to narrow down problems, understand CVE description problems/solutions.

I'm working in analyze current problems from different prospectives:

  • internally from source code with sonar
  • infrastructure (and docker) hardening
  • working on security tools ( like qualys ) and work on fixing reported problems

Also take a look on internal security problems and how they were fixed in the past is useful

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .