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.

Comments

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 for further ideas on what to include. I also maintain a listing of security sites I feel are worth while.

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

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.