jeffrey i schiller massachusetts institute of technology internet engineering task force
Download
Skip this Video
Download Presentation
Security: Not an Afterthought! Or: Deployable Security

Loading in 2 Seconds...

play fullscreen
1 / 16

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


  • 83 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Security: Not an Afterthought! Or: Deployable Security' - wauna


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!
ad