1 / 16

Security: Not an Afterthought! Or: Deployable Security

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

wauna
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Jeffrey I. Schiller Massachusetts Institute of Technology Internet Engineering Task Force Security: Not an Afterthought!Or: Deployable Security

  2. 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

  3. 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

  4. 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

  5. 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?

  6. 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!

  7. 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

  8. 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

  9. 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)

  10. Notes Problems • It is a closed proprietary system • It is a closed proprietary system • It is a closed proprietary system

  11. 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

  12. 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

  13. 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...

  14. 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...

  15. 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!

More Related