Problem Solving - Lessons From Teaching Cybersecurity: Week 4

Image

As I had mentioned previously, this year, I’m going back to school. Not to take classes, but to teach a course at my alma mater, Fanshawe College. I did this about a decade ago and thought it was interesting, so I was excited to give it another go. Additionally, after a friend mentioned that their kid wanted to learn Python, I developed an Intro to Python aimed at high school students that I’m teaching weekly. I thought that this would be good fodder for the State of Security. So, whenever I have something interesting to discuss, expect to find it here. When I taught a decade ago, one of my biggest surprises was how much students wanted to be spoon fed information. One of my greatest joys when I got into computers in the late 90s is still one of my favourite things – learning something new. I love being presented a challenge and digging into it. When I developed the courses I wrote 10+ years ago, they were filled with challenges. The students were given a problem and enough information to point them in the right direction, but they didn’t know how to actually solve the problem. They wanted to learn by having everything handed to them, instead of figuring it out by themselves. This time around, I developed the college course the same way… I expect students to research and problem solve in order to complete my labs. With my high school course, however, I spoon feed them everything, they learn from making mistakes in typing out the code and watching how the code works. I think that this makes sense as I have very different expectations between high school and college students. I was surprised, however, to learn from my college students that they had courses where that was exactly what they were expected to do… take code and type it out. Given this, I thought that this week, we could talk about a couple of times recently that I had the opportunity to really do some research and the surprises I had in working with my students. This should provide some insight into what I feel are reasonable investments in problem solving and demonstrate how one could expect to be challenged in cybersecurity. If someone were to read these stories and feel like they’d hate their life with all of these, they probably aren’t interested in a career in cybersecurity.

Bad Neighbor

One of the big ones for me was the release of CVE-2020-16898 (Bad Neighbor) on Microsoft’s Patch Tuesday. I had not worked with ICMP6 packets before and I was really excited to dig in and write some Python to send packets. I didn’t end up reproducing the issue on Tuesday night, there were higher priority items, but I did spend some time familiarizing myself with the code path to get a better understanding of the problem. A colleague and I spent several hours discussing based on the limited information available and it was a fun research task. While I didn’t get to a conclusion, I still had a great learning experience and added a new skill to my toolbox, which is really the most important thing personally.

Do You Have the Time?

I wanted to wrap up my high school course (which was still in development) because a few of my college students were struggling, so I offered to spend some time with them on Saturday. We were using the high school Python course, which meant that I needed to finish it and I hadn’t finished the socket programming aspects of the material. I thought long and hard about what I wanted to teach. Most of my network programming has involved DNS, SSH, or HTTP and I wanted a simple UDP option (I figured DNS pointers may be too difficult for high school students to parse). I realized that I had not read the NTP RFC and decided that I would tackle NTP. I spent Friday night reading the RFC and creating a simple coding challenge to query the current time from an NTP server using just the Python socket module. It was one of the best Friday nights I’ve had in a while, it was just a lot of fun.

WMI and Me

For my last example, I want to talk about a small video I recorded for my students on Saturday morning. I talked about understanding requirements and the expected outcomes of your code and how important a pen and paper can be in problem solving. Personally, I draw out every piece of code I want to write. I make sure that I understand the requirements of the code, the expectations I (or others) may have on the program, and what my output is going to look like. So, I wrote up a quick piece of code using the Python WMI module. While writing the code, I realized that my wmi_object was using properties to access the various pieces of data returned from a WQL query and I was curious about where those properties were stored. I ended up using the dir() function a lot as I dug into various methods of the wmi_object and saw values change from None to containing data as I moved through my code. How it works and why it works that way doesn’t matter… but at 8AM on a Saturday, it was a great way to enjoy a cup of coffee.

Problem Solving and Cybersecurity

So, why did you just read 500 words on what I did last week? It wasn’t because I wanted to brag about what I learned… well that’s not the only reason. Instead, it’s because everything you do in cybersecurity involves problem solving. If you do not like a challenge; if you do not want to solve problems with giant unknowns, then cybersecurity is probably not the career for you. I don’t think that we make this clear as an industry. There’s a lot of problem solving at every step of your career and if you aren’t interested in problem solving, then you probably won’t enjoy yourself. Instead of spoon feeding cybersecurity students, it is important that we push them and challenge them. When we hire new graduates, it is important that we throw them into the fire rather than coddling them. People can learn problem solving, but if it isn’t something they were expecting or want to learn, they need to know that early on.

Problem Solving and the Weeds

This doesn’t change a problem I discussed previously… don’t get stuck in the weeds. You need to know when you are beat on a problem and really this could be considered a continuation of that discussion. How long does it take to identify that you are stuck in the weeds? It’s something that you learn over time. I will use an example from the classroom though. I had a student turn in a lab and mention to me that it took them 11 hours to figure it out. They stuck at it and worked through the problems. Did I expect students to spend that much time on this lab? No, I figured it would be 4-6 hours of work, but they completed the task and that is awesome. That’s someone that would make a good employee in my opinion. Alternatively, I had a student submit a lab with a comment that they tried for two hours and couldn’t finish it. To me, that’s indicative of someone who doesn’t like problem solving or gets frustrated easily and maybe doesn’t realize where the courses they are taking will lead them. That wasn’t getting stuck in the weeds, that was giving up on a challenge. Luckily, problem solving is something that can be learned, it just takes time and requires that you learn to deal with your frustration and redirect it into a positive result.

Unsolicited Advice

Perhaps, if you are still reading, this advice is solicited, but I wanted to share my thoughts with everyone on this type of problem.

Professors

Please! Please! Please make sure you are challenging your students. If you are spoon feeding them material and not challenging them, you are not helping them. If you are not making them solve problems and think outside the box, you are setting them back in their career. I know that it isn’t fun to deal with complaining students or their parents and it is awful for post-secondary institutions to lose money from lower enrollment in later semesters, but as an educator, you should have one goal… to prepare your student for life after school. If they can’t solve problems and think critically, you have failed.

Students

Don’t complain when something is “too hard.” There’s no one to complain to when you get a job. Leverage the internet, then your peers, and then your professor. When things blow up in the real world, you don’t go running to your boss every time, you work with your colleagues to figure it out. Get used to that now when you have a place where your failures have less impact. You should be challenged and if you aren’t being challenged, question your professors, your program coordinator, and your dean. Ask them why they aren’t fully preparing you for the real world.

Employers

When you interview, ask problem solving questions. See how they approach the problem and how they react when they can’t solve it. If they do solve it, ask a harder question. If they lack problem solving skills, provide that feedback, explain where they need to grow. If you hire someone, let them stumble in the early days on the job. Don’t hand them the answers, let them develop their troubleshooting skills, even if it takes two weeks to complete a one week task. As long as there’s no deadlines and there’s not a huge impact to letting the project slip, give them some extra time, but also identify when they start spinning their tired and get stuck in the weeds, that’s when you should step in and help… but not before. At the end of the day, critical thinking and problem solving are key in many professions, but they are critical in cybersecurity. Make sure that you are prepared to struggle, that you are ready for the difficult road ahead, and that you understand the pressure you will face. Not everything will come easy, but honestly the hardest things are often the best. I had so much fun learning the NTP RFC and digging into the underlying functionality of the Python WMI module. That was really fulfilling work. If you aren’t finding yourself fulfilled and excited by the prospect of a new challenge, think twice about the career you are looking to enter.

More Reading

Helping Inspire the Next Generation of Cybersecurity Professionals Back to School - Lessons From Teaching Cybersecurity: Week 1 Developing Confidence - Lessons From Teaching Cybersecurity: Week 2 Asking Questions - Lessons From Teaching Cybersecurity: Week 3