The following summarizes two recent talks in the Security Seminar Series co-sponsored by NJITES.

NJITES URL: http://guinness.cs.stevens-tech.edu/~dduggan/Public/ITES/index.html
Seminar Series: http://www.cs.stevens-tech.edu/Lab/SecureSystems_Lab/Seminars.html


Critical Infrastructure Protection from Cyber Attack
Talk by Ed Amaroso, AT&T 10/2/01

Ed Amaroso gave an entertaining overview of his view of the methods that (usually) work and methods that don't work in cyber security.  Ed's list of methods that usually work include:

  1. Trusted networking base architecture (e.g. firewalls, enclaves)
  2. Intrusion detection alarm stream profiling (e.g. honey pots, polyinstantation, fooling the cyber attacker with pseudo-networks a la www.honeypot.org)
  3. Well-defined rapid incident response processes
  4. Integration of security into the software lifecycle (Ed advocates that security concerns be taught from Day One in educating future software developers)
Ed's list of methods that don't work include:
  1. Complex visualization
  2. Reliance on vendor security protections (e.g. patches for security holes from certain Large Software Vendors)
  3. Monolithic cross-organizational security policy
A general theme of Ed's talk was that we need to distinguish protection-in-the-small from protection-in-the-large.  With the former, the issue is the need to understand the details of what is going on from logs, monitors, etc.  With the latter, the issue is trying to figure out what is going on from the overall picture, figuring out where to focus one's attention etc.

Another general theme is that security needs to be interwoven with everything, not something that is taught in an isolated course or, in software development, only considered late in the development lifecycle.
 

Authenticity by Typing for Security Protocols
Talk by Alan Jeffrey, DePaul University, 10/5/01
Joint work with Andrew Gordon, Microsoft Research

What is authenticity?  This is an issue that has bedevilled security protocols and reasoning about their correctness.  In the security community, Woo and Lam have proposed correspondence assertions as a notion for capturing authenticity, and this is generally used in reasoning about authentication protocols (Needham and Schroeder, etc).  Essentially correspondence assertions provide a guarantee of freshness in information that is exchanged during an authentication protocol.

Reasoning about security protocols is still very hard and it is difficult to find methods that scale.  Gordon and Jeffrey propose a Java-like programming language specifically for writing security protocols, whose type system incorporates the notion of correspondence assertions.  Someone writing a protocol in this language specifies the authenticity properties by annotating the code with correspondence assertions.  They must then provide the types for keys, nonces and messages of the protocol.  Once they have done this, and provided the program type-checks okay, then the protocol is guaranteed to be correct.  Since protocol-checking is reduced to type-checking, this offers great promise for an approach to verifying security protocols that scales up.  Their work is so far targeted to symmetric key systems, and they are now working on extending it to asymmetric key systems.