2

I teach at an academic institute. We have decided to add a mandatory course: Introduction to Cyber Security.

We know that most of our graduates won't stay in academia, but will go to work in the industrial sector. Nevertheless, we believe that at least basic knowledge in information security is a must today.

The course's goal is not to make the students information security professionals, but rather to teach then the basics and expose them to this field.

Generally, we have two goals for this course:

  1. Expose the students to the world of information security, and give them (again, most of them will go to the industry) useful tools and knowledge. The tools and knowledge should also be useful for graduates who do not work in the field of information security.

  2. Encourage students to take also the advanced courses in this field.

Considering these goals, I have two questions for you, as we now have discussions about the content of the course.

  1. Which subjects do you believe should be included in such a course? What are the most important concepts? Which topics are the most relevant for graduates that will work in the industry, but not in the field of information security? For example, topics like "Secure Coding" seem very relevant to every programmer, but this topic is less interesting in my opinion. Another topic that I considered is password management.

  2. We have a special debate about SSL. I believe it is a must in such a course. Even if we choose not to teach about the specific algorithms, it is a must to know how this protocol works: What is a certificate, how to use it, which problems SSL solves, etc. Everyone uses this protocol, and I encountered many cases where knowledge of SSL was crucial. However, I was surprised to see that I have some opposition about this topic (SSL). I would like to hear your opinion--do you think SSL should be one of the topics?

Any other ideas and remarks are welcomed.

Additional details:

My course contains 13 meetings (units) of three (academic) hours each. Units that I believe should be in the course, some of them following your great answers:

  • Introduction + CIA triad
  • Thinking like a hacker
  • OSINT
  • Scans (and relevant tools).
  • Firewall, IDS, IPS
  • Public and Private key shortly and SSL
  • Denial of Service
  • Network level - mainly DNS
  • Application level - two units with basic examples: SQL injection and maybe XSS (as second attack).
  • passwords management
  • Secure-Coding - with attention to mobile (and common mistakes).
schroeder
  • 123,438
  • 55
  • 284
  • 319
Gari BN
  • 485
  • 1
  • 6
  • 14
  • I recommend you move 'think like a hacker' to part of the pen testing section. In my experience, it's most useful there, and not very useful to people who are learning development and quality engineering – atk Dec 29 '13 at 08:29
  • 3
    Oh, and you should consider threat modeling as a major topic area to cover – atk Dec 29 '13 at 08:30
  • I believe that the part of 'think like a hacker' is just a cool thing that will motivate the students. It's about breaking systems generally (not necessarily computer systems). And about threat modeling and risk management - I believe this is very heavy topic. – Gari BN Dec 29 '13 at 08:33
  • Threat Modeling is indeed a heavy topic, but if you can give a light and easy walk through, I would definitely recommend that you add it. I taught a group of developers to do attack surface analysis and threat modeling in about 2 hours (with relative success), so it should be doable, if you can fit it in – Karthik Rangarajan Dec 29 '13 at 08:38
  • "think like a hacker", in my experience, turns out to demotivate most people about security. The phrase mystifies security instead of clarifies. Imagine if you were told to think like a ballerina, or a parade director, or like a televangelist - what the heck would it mean? Does it put you in the frame of mind that the underlying idea is achievable or does it seem a convoluted way to explain something? – atk Dec 29 '13 at 08:45
  • @atk What you say makes sense, except, in my experience, "think like a hacker" is easier to relate to, especially if put in a different way, such as "assume you are the evil guy" or "how would you break into this building." Most people can relate to that, IMO, and it makes them excited that they can put on that hat. – Karthik Rangarajan Dec 29 '13 at 10:48
  • @atk "Think like a hacker" isn't meant to mystify security and it doesn't. To present the idea to students you ask them to look for problems around them in the real world where they might be able to get something for free. In most situations they've probably thought of them already –  Dec 31 '13 at 02:51
  • @Rell3oT: I am fully aware of the intent. I happen to work for a company with more than 10,000 developers and quality engineers, and hold responsibility for teaching them how to build secure software. I have experience working with many of these professionals, and 'think like a hacker' always makes things worse, not better, in my experience. Your experience may be different. That doesn't change mine. – atk Dec 31 '13 at 03:55
  • @atk Well the audience of this course is not paid engineers. These are people who, at best, will want to study computer science later. I agree, ``Thinking like a hacker'' is not appropriate for people who are technical already. Source: My university pays me to hang out with high schoolers and make them think computers are cool. –  Dec 31 '13 at 04:11
  • @Rell3oT, where do you see that about the audience of this course? I only see that it is an academic institute, which could be grade school, high school, college, night school, or something entirely different. Regarding high schoolers: yes, they will have a different response than professionals. – atk Dec 31 '13 at 04:39

3 Answers3

6

I've been involved with this type of situation for the past several years. Here's what I teach and focus on.

For each topic. Lecture and technical details must be accompanied by either some kind of demo or some kind of hands on exercise. If the demo isn't flashy then it should be an exercise. This stuff is dense. I start every year with 30+ students in the club and end the year with much less. It can hard hard to keep interest. There's no reason for this to be boring when it is such an exciting topic.

Topics

  • CIA Triad. Basic concepts such as Authentication, Authorization, tokens, non-repudiation, privacy, security, vocabulary. Talk about the type of problem security is. Is it a technical problem...or a people problem? See what students think.
  • Thinking like a hacker. Ask them about vulnerabilities in the lunchline they go to or encounter in the bus systems or every day. Ask them to redesign their dining hall so students are unable to get cheaper lunches or whatever they come up with. It's honestly always really fun and gets them really interested in the things to come.
  • Physical Security. You don't have to spend a long time on this one in my opinion. Just make sure they know that if you have access to a computer, it is pretty much your computer.
  • Exposure to cryptography. This is a tough one to teach without diving in deep but you should show that basic building block technologies build secure protocols and understand the problems crypto doesn't solve. Usually I talk about the difference between public and private keys, I talk about establishing a shared key, and honestly just expose them to it. It really requires its own course but you can still talk about it.
  • Securing a computer. Passwords, Services, figure out what's running. What users exist, etc. Logging and Event viewing. I also talk about the tradeoffs with some security decisions you make. Log too much, you'll never look at them. Make the lockout policy too strict, you end up with a lot of angry users.
  • Malware. Talk about different types, show differences and real examples. Show them basic characteristics of malware and do super basic things to see what the malware is doing in a analysis environment. Capture network traffic it creates, ports it opens, things it install. Talk about the motivations of the attacker. This is also a good time to talk about the laws of your country (and the laws of your network admins) regarding hacking.
  • Web Security. XSS with real phishing emails, CSRF with real vulnerabilities, stored XSS with a real attack. This kind of stuff is EASY to demo to a roomful of students. It's really easy to whip up a toy web-app and show something. This year I wrote a vulnerable toy twitter and had the students use it. Next I tricked them into going to a different site I owned and I tweeted using their session. They were so amazed it was hilarious.
  • Basic steps a hacker MIGHT go through. Looking for targets, scanning for vulnerabilities, attacking the vulnerabilities, maintaining access. This is, surprisingly a difficult section to keep interest up on. Students are really amazed but lose attention quickly when they are sitting there with a meterpreter shell thinking "This is less exciting than I thought"
  • Buffer overflows and exploits. Toy C programs that behave badly and Metasploit are great for this

Have fun with it. It is such a huge amount of material that whatever you choose to do, as long as it is hands on, will be a lot of fun.

  • Great ideas! Mainly the "Thinking like a hacker"! In this basic course, I won't teach buffer overflow in the course as this attack is hard for students (I see in the advanced course). – Gari BN Dec 29 '13 at 07:49
  • @GariBN If you still want to cover it you can at least tell them about it and maybe show it. Tell them it is the building block of many exploits and let it brew in their minds. If not...that works too. Have fun =] –  Dec 29 '13 at 16:02
2

Every class introduce them to a new par of infosec: webapp( xss,SQL injection, csrf), bufferoverflows, physical security,...

And give them a task after every class. For instance make a challenge to attack an xss vector, SQL injection, bufferoverflows,...

When talking crypto first of all explain them that implementing this themselves is not good for production usage. Then let them implement the crypto themselves in a familiar language to LEARN. not for usAge! (Emphasize this )

To be honest you can touch ssl and force them self study using a decent course manual like "networking a top down approach". Confidentiality, integrity and availability are the infosec trinity and ssl is a good example. So I would personally include 1 class on it explaining the general concepts.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
2

When I took my first information security course, what made me interested in the field was some of the hard problems that were used to provide security (like public key crypto, hashing functions, etc.) However, I soon realized that while that knowledge is great (and probably a prerequisite) to understand a lot of security, it doesn't translate to direct skill in the industry.

From what I've been seeing in my (relatively short) time in the industry, it is moving towards a world where everyone needs to be aware of security. There used to be a time when there were a bunch of "those security nerds" and then everyone else who didn't worry about security. With the explosion of web applications, and how easy it is to set them up, to me, the most important thing, especially for people who are going into the software world, is to learn application security.

That said, for an introductory course, I would start with the very basic of things:

  1. The need for security (essentially the CIA triad, and communicating privately in a public world. I would even recommend certain chapters from this great network security book, even though it's a tad expensive). I would follow this up with an exercise where they have a set of problems where they need to figure out which of the CIA triad is necessary. (For example, you're you're posting public messages on a forum for everyone to read. Which of the three pillars of security does this need? - problems like this, more creative, obviously)
  2. The basics of cryptography - a brief history of it, symmetric crypto, asymmetric crypto, hashing, MAC, etc. Again, the book above is an excellent resource.
  3. Include a few papers as recommended reading - Smashing the stack for fun and profit, a really old paper on some of the famous internet worms, and a few others that I will add in once I remember them. This can be optional, though I learned a whole bunch of things from some of these papers. As a follow up to this, perhaps have an assignment where they do a basic buffer overflow exploit (this seems to be a good example for Linux, and this seems to be a good one for Windows).
  4. While a prerequisite maybe networking knowledge, it wouldn't hurt to go into the basics of Network Security. My own knowledge here isn't up to mark, but things I remember learning about are IPSEC, vulnerabilities in DNS and DNSSEC, Firewalls, IDS/IPS, how SSL works, etc. This could be followed up with an exercise in setting up a Firewall with a specific set of rules, or setting up Snort to alert on a set of rules, etc.
  5. Web application security - going through the OWASP Top 10 is great. I would focus on secure coding principles if your target audience is primarily engineers; even otherwise, focus on why application security is important. There are plenty of examples out there, Adobe being one of the latest to join the group of "oh shit we did that wrong". This I would say would be where you would go into more detail than the previous topics. A follow up exercise here could be setting up Mutillidae or WebGoat and walking through the OWASP Top 10. Perhaps even make the students write applications, and then make each of them test another team's application (this can be particularly effective for teaching secure coding and dynamic testing)
  6. Mobile Application Security: Yes, this is important. All the vulnerabilities that we thought went away from webapps, we are now seeing in mobile apps. OWASP Mobile Security Project made a decent attempt at covering some of the vulnerabilities, I would suggest building something off of that. An exercise for this could be something similar to what you did above.
  7. Physical Security: A lot of people would say this should be at the top, and I might even agree. All the network and application security in the world is useless if you aren't securing things physically. There's a lot of resources and talks available on the Internet (this talk is a really good thing to start off of).
  8. Social Engineering - both from an offensive side and a defensive side. There's a lot of resources for this one as well, and I am going to shamelessly include my own answer here as a resource.
  9. Open Source Intelligence (OSINT) - yes, this is becoming more and more important these days. The things that people leave on the Internet inadvertently increases everyday. Shane's talk at Derbycon 2013 is an awesome resource.
  10. The basics of Offensive Security Tools - things like Metasploit, nmap (though this isn't really just for offensive security), Nessus/Nexpose, Burp, all the other related tools. Perhaps set up a lab where they can practice using these tools (again, Metasploitable, Webgoat, Damn Vulnerable Webapp, etc. are great resources).
  11. Wrap it all up - perhaps create a CTF-like challenge where they get to use all the skills they learned. It doesn't have to be super extensive or very hard, just something where they get to apply what they learned in some way, so that it doesn't leak out of their head.

If the topics above are too many for the duration of the class, I would even suggest asking the class for what they want to learn, and pruning based on that. Quality over quantity and all that.

I've covered everything that I would have liked to learn from my introductory security course. I would emphasize that you build this course with a focus on practical skills - things they can use going right out of the class. That is one of the biggest things that I've heard people complain about from introductory security courses, so building one with the aim of practical knowledge would be very useful.

Community
  • 1
Karthik Rangarajan
  • 840
  • 6
  • 18
  • My course was 3 hours a week for about 11 weeks, with a midterm and an exam. So I would say he actual classes were about 30 hours, a the most? Perhaps a little less than that even. – Karthik Rangarajan Dec 29 '13 at 08:23