A Network Security Class?

eap asks: "Some friends of mine and I are creating a Network Security course to take this summer. We have discussed the idea, but so far haven't decided what the class should entail. We were thinking of running exploits against several OS's, and then trying to plug the holes. Could anyone recommend a 'syllabus' for how such a class might go?" This is a good idea, but they need to flesh out that syllabus a bit more. Running exploits and plugging the holes is one thing, but that's not all there is to securing your LAN, is there? For one thing, it leaves out -internal- network security..not all threats to a network exist on the outside.

internal hardware configuration

[Anonymous Coward]

make a point to discuss hardware configuration on the router/switch etc. level... far too often these things are left undone. many switches (some if not all cisco catalyst models) allow for individual port programming to do things like lock down mac addresses to prevent unauthorized nodes from physically connecting to your network (joe anonymous in accounting bringing in a laptop to sniff moronic user's plaintext telnet passwords)

just a thought

Monitor

[Cadre]

The course might also cover topics on how to detect unauthorized activity on the network, and maybe even social engineering that maybe be used to preempt attacks.

Theory vs. Practice

[Lawless]

In studying security, it may bebennificial to the administrator to move past the practices that are current at the time and examine the underlying theory that the practices are based upon. For example, to determine what Network Intrustion system would be best suited for a particular enviorment it is usefull to have some understanding of the various types of NIDS systems. I offer the following reading list as a suggestion of items which may fit within the scope of the course:

Secure Computers and Networks, by Fisch and White
One of the better introductions to security analysis and design I have seen. The book is written to be a textbook for a security class. Of particular note is the chapter on Risk Assessment. It does a good job at demystifying this nebulous subject and offers some simple metrics by which one can assess their current risk.

Security in Computing, by Charles Pfleeger.
Another good textbook introducing security. I would suggest skipping chapter 2 for last, the encryption sections would have fit the end of the book better. There is an updated version out as of April, my reading was of the 1996 version. Dr. Pfleeger presents the various security models used in host, database, and network security in a clear manner. Of intrest to network administrators and sysadmins would be his discussion of covert channels.

Intrusion Detection, Macmillian Technology Serise
This one presents a through introduction into the topic of Intrusion Detection systems (both host and network). The histroy part is a bit dry, IMHO, but if you are going to be tasked with deploying or selecting a Network IDS system, this book will allow you to go beyond the glossy paper and understand what that IDS system will really mean for you -- both good and bad.

Network Intrusion Detection: An Analyst's Handbook by Stephen Northcutt.
Topics covered by Northcutt include recognizing attacks, weaknessess, and responding to incidents both as and after they occur. No matter how good your security, they will occur.

Information Warfare: Principals and Opperations by Edwand Waltz.
Not a network security book, but the new buzz word is Informaiton Warfare. While Dr. Denning has written extensively on this subject, Dr. Waltz takes the military perspective on this topic. and covers the entire spectrum of information warfare in a lively manner. Increasingly our systems and networks will be targeted not by teenagers, but by orginized groups. This book will help you seperate the information on IW from the hype.

Hole range of areas to cover

[Bryan Andersen]

A quick list off the top of my head:

• Types of vulnerabilities.
• Types of firewalls, what they can and can't do for you.
• Router configuration for secure networking, and being a good net citizen.
• Network penetration methods and how to counter them.
• Network traffic monitoring.
• Secure server setup for different types of servers. Some are naturally more secure than others.
• Secure and insecure protocols.
• Procedures and policies.
• (plus many, many more)...

I would take a look over at Security Focus [securityfocus.com] for further ideas on what to include. I also maintain a listing of security sites [visi.com] I feel are worth while.

Security Course Offerings and Resources

[_hAZE_]

There was a recent post on regarding security courses. The poster was kind enough to reply back to the list with a list of responses to his question. I've included some of that list below.. my hands hurt from typing all day, so I don't feel like typing out the rest. Maybe I will tomorrow..

http://www.isc2.org/ [isc2.org]
http://www.brainbench.com/ [brainbench.com]
http://www.robertgraham.com/ [robertgraham.com]
http://www.r00tabega.com/ [r00tabega.com]
http://www.sans.org/ [sans.org]
http://www.csc.com/ [csc.com]
http://www.ey.com [ey.com]
http://www.securityfocus.com/ [securityfocus.com]
http://astalavista.box.sk/ [astalavista.box.sk]
http://neworder.box.sk/ [neworder.box.sk]
http://blacksun.box.sk/tutorials.html [blacksun.box.sk]
http://www.prosofttraining.com/ [prosofttraining.com]

Don Head
Linux Mentor

Topics

[rjamestaylor]

Some necessary topics for any network security class:

1. Weakest Link

   The weakest part of the system's security determines the effective security of the system. One hole left unattendeded thwarts all other holes being stopped. The Titanic was perfectly safe from any threat except the one that sank it.

2. Multiple points of failure

   The addition of components to a system tend to degrade security rather than increasing security. This may seem silly, for doesn't adding a firewall make a system more secure? Yes, and no. The firewall now must be setup and maintained properly, or it becomes another staging ground for security attack if it is compromised. If you've had to deal with network

   reliability this point makes perfect sense.

3. Know the Enemy

   It goes without saying that the best defense is a good (knowledge of the) offense. Study the CERT warnings, study the hacker sites, get the SATANic-type tools (just don't get caught using them against someone elses system). It's continuing education: know the exploits and secure your own system from them.

4. Know the Enemy Within

   The truth is most attacks occur from within an organization, or by the ones with some legitimate access to the system. This makes sense, because the most interested parties in protected elements within a system are probably already on the inside (e.g. only a Slashdotter would really want Malda's password...). This goes for disgruntled and/or bored workers within a company. They may be searching for secrets or willing to satbotage. It goes without saying that employees who are fired have their accounts shutdown (and root passwords changed, just in case!) simultaneously to thier firing.

These are all commonsense and obvious, but need to be stressed all the more. Security is not merely a technical problem. Planning, proceedures, and psychology are weapons in this warfare -- on both sides, no doubt

Re:Security Course Offerings and Resources

[_hAZE_]

Oops, forgot something in that first sentence..

"There was a recent post on [e-mail] regarding security courses."

Don Head
Linux Mentor

Points to Consider

[brank]

The most important thing to remember about security is that if you don't keep up to date about threats, you won't know what can happen and how to prevent it. It is important for such a class to cover sources of information, and how to evaluate and act upon information.

It is also important to remember that new versions of software fix old holes and create new ones, and that admins should look out for fixes and new dangers when installing software.

rootprompt.org has a lot of security stuff. I find two serials paticularly interesting [rootprompt.org]Watching and Waiting, [rootprompt.org] about what happens when a system gets cracked, and Know your Enemy, [rootprompt.org] about how a typical cracker works.

Sorry about That

[brank]

For some reason, /. split my end link tag in the textbox and did wierd things (wasn't my fault! honest!). The Watching and Waiting link is here [rootprompt.org].

MIT Class

[LRandomfactor]

There's an MIT class, Network and Computer Security [mit.edu], that has all its problem sets online... a good thing to make you think about some basic theory would be to go through them, write up a page on each, like the students do, and compare to the answers the TAs and prof came up with.

This may not be what you're looking for; I find the questions interesting, and plan on taking the class sometime in the next couple years.

Practical Security

[rjh]

I am an InfoSec professional IRL; however, I'm not a college prof and I've never taught a class beginning to end.

1. COVER FAILED PROTOCOLS.

The field is littered with broken protocols and algorithms. Some of them are broken because they're stupid (so study why so many people thought they were smart). Some are broken because they got overtaken by technology (so cover how the protocol left itself vulnerable to technology [1]). Some are broken because the assumptions underlying the protocol are incorrect [2]. Some are... etc. Study the failed ones closely, and learn why so many people thought for so long that they were good.

2. STUDY PRACTICAL AND THEORETICAL DIFFERENCES.

IPsec is a very good protocol in theory; in practice, it's painfully mediocre. IPsec works well as a lesson for how "the best-laid plans of mice and men gang aft agley"; somewhere inside of it there's a beautiful, small protocol screaming to get out, but it gets bogged down in elephantine bulk.

Theoreticians tend to create complex protocols which are damnably difficult to implement well (but when they are, they tend to be nice). Those who take a more practical approach create simple algorithms which can be implemented well, but don't address subtleties.

For examples, see [3] and [4].

3. STUDY THE MISTAKES PEOPLE KEEP ON MAKING.

There are very few really new protocols; people just keep on re-inventing old ones. They also make the same mistakes over and over again. We've known ever since WW2 that poor passwords lead to compromised ciphers. We've known that re-using one-time pads make it trivial to cryptanalyze data. Yet, certain nameless day-trading firms limit user passwords to six alphanumerics, case-insensitive--that's a weak password. Yet, we sometimes see KAK ciphers (OFB ciphers) being used with a repeated IV--that's the same as repeating a one-time pad.

Programming errors are even more common than protocol errors, and can be just as damning [5].

[1] DSA, for instance, originally used a 512-bit modulus. This was way too short for long-term security, and they had to revise it to 1,024 bits almost immediately. It is likely that in the not-too-distant-future, DSA will have to be changed yet again.

[2] Atjai-Dwork and Cramer-Shoup are good examples here.

[3] Kerberos is an example of a theoretically sound protocol which is difficult to implement well in practice. Check the modifications which have been done to Kerberos--for instance, why PCBC mode was used for crypto and why it was changed to CBC mode.

[4] Schneier has some good examples of digital-cash and digital-voting schemes which are practical, but fail to address subtleties.

[5] Check out PGP's latest exploit.