Jeffrey i schiller massachusetts institute of technology internet engineering task force
This presentation is the property of its rightful owner.
Sponsored Links
1 / 16

Security: Not an Afterthought! Or: Deployable Security PowerPoint PPT Presentation


  • 55 Views
  • Uploaded on
  • Presentation posted in: General

Jeffrey I. Schiller Massachusetts Institute of Technology Internet Engineering Task Force. Security: Not an Afterthought! Or: Deployable Security. Security History (Network). None (we are all friends) Early Internet users were researchers Personal Computing revolution had yet to start

Download Presentation

Security: Not an Afterthought! Or: Deployable Security

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Jeffrey i schiller massachusetts institute of technology internet engineering task force

Jeffrey I. Schiller

Massachusetts Institute of Technology

Internet Engineering Task Force

Security: Not an Afterthought!Or: Deployable Security


Security history network

Security History (Network)

  • None (we are all friends)

    • Early Internet users were researchers

    • Personal Computing revolution had yet to start

  • 1988: Uh Oh!

    • Internet Worm, first time Internet made television... in a bad way

  • Today

    • Security threats abound, but security technology is an add-on


Why did the internet succeed

Why did the Internet Succeed

  • Some say it is due to our “open” participatory process of standards setting

    • Yeah sure...

  • DEPLOYMENT WINS

  • The mix of academic excellence combined with Berkeley UNIX and Open Source led to a “deployable” solution

  • DEPLOYMENT WINS


Security is not deployed

Security is not Deployed

  • Internet is “edge” centric

    • Hard to add security in the middle

    • firewalls attempt to add security “quasi” edge

  • Security is Hard

    • It is a “negative deliverable”

      • You don’t know when you have it, only when you have lost it!

      • Not amenable to traditional testing paradigms

  • Users don’t ask for it so the market doesn’t demand it


Commercial security

Commercial Security

  • Much Security Work comes from the government/military sector

    • People use security technology because they are told to.

    • Cost is often not an object

  • In the “commercial” or consumer marketplace you have to sell technology

  • Security is a hard sell

  • Why?


Why a hard sell

Why a hard sell?

  • People assume they have it already.

  • People can not evaluate product claims

    • Remember: Good security is invisible!

  • People can judge features and price

  • So guess what wins!


What is deployable security

What is Deployable Security?

  • Security which people are willing to purchase

  • Security which people are willing to use

  • Security which is easy to use (corollary to above)

  • Security which is incrementally deployable

    • Don’t have to upgrade the whole Internet before any benefit is derived

      • This is one of the reasons why IPsec is marginalized

      • PKI has the same problem, and then some


Anti security

Anti-Security

  • Lawyers

    • Very prevalent in the PKI space

    • Want to set the rules

    • Add expense and FUD to PKI deployment

    • So we live with little security

  • The “Perfect” being the enemy of the good


An example lotus notes

An Example - Lotus Notes

  • Users registered by Administrators

    • But you always have to register people

  • Instead of a password, users are given a “userid” file

    • Either on floppy, or via insecure download

  • Each user has a public/private key pair

  • public key is stored in directory (name and address book)

  • Cryptographic Security used for login

  • Session level encryption via a checkbox

  • Built in Privacy Enhanced Mail (encrypted, signed mail)


Notes problems

Notes Problems

  • It is a closed proprietary system

  • It is a closed proprietary system

  • It is a closed proprietary system


Challenge of standards

Challenge of Standards

  • Everyone should have one!

  • In order to deploy a Lotus like E-mail solution we need a standard for

    • E-mail signatures and encryption

      • Have two now, both reasonable mature (S/MIME and PGP/MIME)

    • Need a way to get people’s keys

      • This is tricky, no standard approach yet

    • Need a way to issue keys to people

      • Oops. There is that PKI problem again


Hierarchy vs graphs of trust

Hierarchy vs. Graphs of Trust

  • S/MIME and PKI in general want a hierarchy

    • Works well within an organization, where a natural hierarchy exists

    • Doesn’t work well between organizations... so who is the root!

    • Doesn’t require end-user sophistication

  • PGP’s Web of Trust

    • Works well without infrastructure

      • The “Internet” way

      • But requires end-user clue

        • Which often isn’t there


Authentication challenges

Authentication Challenges

  • There is username/password

  • And then there is everything else

    • SecurID

    • Smart Card

    • ATM Card

    • Biometrics

      • The “password” you cannot change...

      • There are also “safety” hazards...


The way forward

The Way Forward?

  • We need a PKI based on cross certification

    • Sure, some folks say it won’t scale, but they also said that .COM would break with more then 100,000 domains...

  • We need a good directory for storing public key credentials

    • Maybe LDAP, but need to get rid of stupid clients

      • They can overload a server in any reasonably large deployment

  • We need a “can do” deployment attitude

    • Get the Lawyers out of it...


The way forward1

The Way Forward?

  • We need better languages to write software

    • “C” is inherently insecure, responsible for most “buffer overruns”

    • Java is much better, but currently viewed as a niche language

      • I pray that in the attempt to get better performance, the security features are not lost!


  • Login