1. 1 of 111 Cybersecurity Summit 2004 Some Thoughts on Network and Computer Security in an Academic Environment Bill Cheswick Lumeta Corp. ches@lumeta.com http://www.cheswick.com/ ches@lumeta.com

2. 2 of 111 Cybersecurity Summit 2004 Goals Some thoughts that might be relevant How do you secure things when you absolutely have to. (Intellink) Some (best?) practices I’ve seen or tried Suggest some research projects and directions that might help in the longer run Perhaps some keynote thoughts relevant for the panels

3. 3 of 111 Cybersecurity Summit 2004 This is possibly the hardest problem in computer security Academic environment means free and open access Security generally engineers lack the clout to enforce security policies Clients access the major resources from client hosts around the world Some assembly required

4. 72 slides4 of 112 Cybersecurity Summit 2004 What does it mean to win? Threat models

5. 5 of 111 Cybersecurity Summit 2004 What does it mean to win? Keeping the hacker out of critical systems? – What are your critical systems, anyway? Catching him/them? Nobody notices that everything is working? No mention on the front pages of major newspapers? No angry probing calls from your funding agency?

6. 6 of 111 Cybersecurity Summit 2004 Threat models at supercomputer centers Embarrass system administrators Establish base for attacking other sites? Maximize downtime Attacks on science: corruption of data or programs – Scientists used to share ideas, now they share programs – The dirty word nebula in the Virgo cluster Attack by a patient Luddite

7. 7 of 111 Cybersecurity Summit 2004 Case studies Me – Limited user base – Highly compliant users – Low admin/machine ratio Intellink

8. 8 of 111 Cybersecurity Summit 2004 This talk is mostly about *nix systems, except as noted Most big iron runs some *nix OS, proprietary or not Microsoft has their own problems…

9. 9 of 111 Cybersecurity Summit 2004 Microsoft’s Augean Stables: a task for Hercules 3000 oxen, 30 years, that’s roughly one oxen-day per line of code in Windows It’s been getting worse since Windows 95

10. 10 of 111 Cybersecurity Summit 2004 Network and Host security as I see it

11. 11 of 111 Cybersecurity Summit 2004 Traditional view of host software Kernel User programs

12. 12 of 111 Cybersecurity Summit 2004 This traditional view of host software is wrong Kernel User programs

13. 13 of 111 Cybersecurity Summit 2004 User-level programs use the kernel to interface with the outside world Kernel User programs

14. 14 of 111 Cybersecurity Summit 2004 Example: SYN packet attacks Kernel User programs Attacking packets are never seen at user level….

15. 15 of 111 Cybersecurity Summit 2004 Example: SYN packet attacks Kernel User programs Attacking packets are never seen at user level…. …although user mode enables the kernel listener.

16. 16 of 111 Cybersecurity Summit 2004 Direct attacks on the kernel are fairly rare Kernel User programs TCP/ IP

17. 17 of 111 Cybersecurity Summit 2004 Direct attacks on the kernel are fairly rare Though the software is complex and hard to test, it’s hard to do more than break the kernel Used mostly for DOS attacks Ping ‘o death Random IP options game (crashme) Kernel User programs TCP/ IP

18. 72 slides18 of 112 Cybersecurity Summit 2004 Some ways to break into a host: 1) subvert a privileged network daemon

19. 19 of 111 Cybersecurity Summit 2004 Subvert a privileged network daemon Kernel User programs TCP/ IP Network daemon

20. 72 slides20 of 112 Cybersecurity Summit 2004 Rate a computer’s network security? netstat –an | wc -l

21. 21 of 111 Cybersecurity Summit 2004 Windows ME Active Connections - Win ME Proto Local Address Foreign Address State TCP 127.0.0.1:1032 0.0.0.0:0 LISTENING TCP 223.223.223.10:139 0.0.0.0:0 LISTENING UDP 0.0.0.0:1025 *:* UDP 0.0.0.0:1026 *:* UDP 0.0.0.0:31337 *:* UDP 0.0.0.0:162 *:* UDP 223.223.223.10:137 *:* UDP 223.223.223.10:138 *:*

22. 22 of 111 Cybersecurity Summit 2004 Windows 2000 Proto Local Address Foreign Address State TCP 0.0.0.0:135 0.0.0.0:0 LISTENING TCP 0.0.0.0:445 0.0.0.0:0 LISTENING TCP 0.0.0.0:1029 0.0.0.0:0 LISTENING TCP 0.0.0.0:1036 0.0.0.0:0 LISTENING TCP 0.0.0.0:1078 0.0.0.0:0 LISTENING TCP 0.0.0.0:1080 0.0.0.0:0 LISTENING TCP 0.0.0.0:1086 0.0.0.0:0 LISTENING TCP 0.0.0.0:6515 0.0.0.0:0 LISTENING TCP 127.0.0.1:139 0.0.0.0:0 LISTENING UDP 0.0.0.0:445 *:* UDP 0.0.0.0:1038 *:* UDP 0.0.0.0:6514 *:* UDP 0.0.0.0:6515 *:* UDP 127.0.0.1:1108 *:* UDP 223.223.223.96:500 *:* UDP 223.223.223.96:4500 *:*

23. 23 of 111 Cybersecurity Summit 2004 Windows XP: this laptop, pre- SP2 Proto Local Address Foreign Address State TCP ches-pc:epmap ches-pc:0 LISTENING TCP ches-pc:microsoft-ds ches-pc:0 LISTENING TCP ches-pc:1025 ches-pc:0 LISTENING TCP ches-pc:1036 ches-pc:0 LISTENING TCP ches-pc:3115 ches-pc:0 LISTENING TCP ches-pc:3118 ches-pc:0 LISTENING TCP ches-pc:3470 ches-pc:0 LISTENING TCP ches-pc:3477 ches-pc:0 LISTENING TCP ches-pc:5000 ches-pc:0 LISTENING TCP ches-pc:6515 ches-pc:0 LISTENING TCP ches-pc:netbios-ssn ches-pc:0 LISTENING TCP ches-pc:3001 ches-pc:0 LISTENING TCP ches-pc:3002 ches-pc:0 LISTENING TCP ches-pc:3003 ches-pc:0 LISTENING TCP ches-pc:5180 ches-pc:0 LISTENING UDP ches-pc:microsoft-ds *:* UDP ches-pc:isakmp *:* UDP ches-pc:1027 *:* UDP ches-pc:3008 *:* UDP ches-pc:3473 *:* UDP ches-pc:6514 *:* UDP ches-pc:6515 *:* UDP ches-pc:netbios-ns *:* UDP ches-pc:netbios-dgm *:* UDP ches-pc:1900 *:* UDP ches-pc:ntp *:* UDP ches-pc:1900 *:* UDP ches-pc:3471 *:*

24. 24 of 111 Cybersecurity Summit 2004

25. 25 of 111 Cybersecurity Summit 2004 It is easy to dump on Microsoft, but many others have made the same mistakes before

26. 26 of 111 Cybersecurity Summit 2004 ftp stream tcp nowait root /v/gate/ftpd telnet stream tcp nowait root /usr/etc/telnetd shell stream tcp nowait root /usr/etc/rshd login stream tcp nowait root /usr/etc/rlogind exec stream tcp nowait root /usr/etc/rexecd finger stream tcp nowait guest /usr/etc/fingerd bootp dgram udp wait root /usr/etc/bootp tftp dgram udp wait guest /usr/etc/tftpd ntalk dgram udp wait root /usr/etc/talkd tcpmux stream tcp nowait root internal echo stream tcp nowait root internal discard stream tcp nowait root internal chargen stream tcp nowait root internal daytime stream tcp nowait root internal time stream tcp nowait root internal echo dgram udp wait root internal discard dgram udp wait root internal chargen dgram udp wait root internal daytime dgram udp wait root internal time dgram udp wait root internal sgi-dgl stream tcp nowait root/rcv dgld uucp stream tcp nowait root /usr/lib/uucp/uucpd Default services SGI workstation: mid 1990s

27. 27 of 111 Cybersecurity Summit 2004 More default services mountd/1 stream rpc/tcp wait/lc root rpc.mountd mountd/1 dgram rpc/udp wait/lc root rpc.mountd sgi_mountd/1 stream rpc/tcp wait/lc root rpc.mountd sgi_mountd/1 dgram rpc/udp wait/lc root rpc.mountd rstatd/1-3 dgram rpc/udp wait root rpc.rstatd walld/1 dgram rpc/udp wait root rpc.rwalld rusersd/1 dgram rpc/udp wait root rpc.rusersd rquotad/1 dgram rpc/udp wait root rpc.rquotad sprayd/1 dgram rpc/udp wait root rpc.sprayd bootparam/1 dgram rpc/udp wait root rpc.bootparamd sgi_videod/1 stream rpc/tcp wait root ?videod sgi_fam/1 stream rpc/tcp wait root ?fam sgi_snoopd/1 stream rpc/tcp wait root ?rpc.snoopd sgi_pcsd/1 dgram rpc/udp wait root ?cvpcsd sgi_pod/1 stream rpc/tcp wait root ?podd tcpmux/sgi_scanner stream tcp nowait root ?scan/net/scannerd tcpmux/sgi_printer stream tcp nowait root ?print/printerd webproxy stream tcp nowait root /usr/local/etc/webserv

28. 28 of 111 Cybersecurity Summit 2004 FreeBSD partition, this laptop (getting out of the game) Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address tcp4 0 0 *.22 tcp6 0 0 *.22

29. 29 of 111 Cybersecurity Summit 2004 “Best block is not be there” - Mr. Miyagi (Pat Morita) Karate Kid

30. 30 of 111 Cybersecurity Summit 2004 Secure network services for *nix Postfix Openssh – But if the call comes…

31. 31 of 111 Cybersecurity Summit 2004 Properties of these services The authors cared very much about security from the first moment of design The code has a low rate of “improvements,” which gives the code a chance to stabilize The security record for these is excellent, though not perfect Careful efforts by a few have benefited us all

32. 32 of 111 Cybersecurity Summit 2004 Some popular network services I don’t like NFS – Not Unix file system semantics – RPC implementation is complicated and dangerous Still sniffable – POP3 – SNMP – Instant messaging

33. 33 of 111 Cybersecurity Summit 2004 Research/project/funding suggestion Rewrite or audit the software we rely on the most – This has been done to some extent…see below – Libc, ASN.1 compiler, C compiler, kernel calls (“Setuid demystified”) Perhaps Knuth would write a new inetd…

34. 34 of 111 Cybersecurity Summit 2004 The Pretty Good Wall of China

35. 35 of 111 Cybersecurity Summit 2004 Perimeter defenses don’t work… If the perimeter is too big, or If you have to let the barbarians in

36. 36 of 111 Cybersecurity Summit 2004

37. 72 slides37 of 112 Cybersecurity Summit 2004 Some ways to break into a host: 2) subvert a user account and break into root or admin using setuid programs

38. 38 of 111 Cybersecurity Summit 2004 Subvert a user account and break into root or admin Kernel TCP/ IP User Setuid program

39. 39 of 111 Cybersecurity Summit 2004 “Unix is an administrative nightmare.” -- Dennis Ritchie

40. 40 of 111 Cybersecurity Summit 2004 “GUIs are not the answer to Unix’s administrative nightmare.” -- me

41. 72 slides41 of 112 Cybersecurity Summit 2004 Rate a Unix systems host security? find / -perm -4000 -user root -print | wc -l

42. 42 of 111 Cybersecurity Summit 2004 /bin/rcp /sbin/ping /sbin/ping6 /sbin/shutdown /usr/X11R6/bin/Xwrapper /usr/X11R6/bin/xterm /usr/X11R6/bin/Xwrapper-4 /usr/bin/keyinfo /usr/bin/keyinit /usr/bin/lock /usr/bin/crontab /usr/bin/opieinfo /usr/bin/opiepasswd /usr/bin/rlogin /usr/bin/quota /usr/bin/rsh /usr/bin/su /usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/bin/chpass /usr/bin/login /usr/bin/passwd /usr/bin/at /usr/bin/ypchsh /usr/bin/ypchfn /usr/bin/ypchpass /usr/bin/chsh /usr/bin/chfn /usr/bin/yppasswd /usr/bin/batch /usr/bin/atrm /usr/bin/atq /usr/local/bin/screen /usr/local/bin/sudo /usr/local/bin/lppasswd /usr/sbin/mrinfo /usr/sbin/mtrace /usr/sbin/ppp /usr/sbin/pppd /usr/sbin/sliplogin /usr/sbin/timedc /usr/sbin/traceroute /usr/sbin/traceroute6 44

43. 72 slides43 of 112 Cybersecurity Summit 2004 Remove the ones I never use You should never be vulnerable to the weaknesses of a feature you do not use. -- Microsoft security goal

44. 44 of 111 Cybersecurity Summit 2004 /bin/rcp /sbin/ping /sbin/ping6 /sbin/shutdown /usr/X11R6/bin/Xwrapper /usr/X11R6/bin/xterm /usr/X11R6/bin/Xwrapper-4 /usr/bin/keyinfo /usr/bin/keyinit /usr/bin/lock /usr/bin/crontab /usr/bin/opieinfo /usr/bin/opiepasswd /usr/bin/rlogin /usr/bin/quota /usr/bin/rsh /usr/bin/su /usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/bin/chpass /usr/bin/login /usr/bin/passwd /usr/bin/at /usr/bin/ypchsh /usr/bin/ypchfn /usr/bin/ypchpass /usr/bin/chsh /usr/bin/chfn /usr/bin/yppasswd /usr/bin/batch /usr/bin/atrm /usr/bin/atq /usr/local/bin/screen /usr/local/bin/sudo /usr/local/bin/lppasswd /usr/sbin/mrinfo /usr/sbin/mtrace /usr/sbin/ppp /usr/sbin/pppd /usr/sbin/sliplogin /usr/sbin/timedc /usr/sbin/traceroute /usr/sbin/traceroute6

45. 45 of 111 Cybersecurity Summit 2004 /sbin/ping /sbin/ping6 /usr/X11R6/bin/xterm /usr/X11R6/bin/Xwrapper-4 /usr/bin/crontab /usr/bin/su /usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/bin/login /usr/bin/passwd /usr/bin/at /usr/bin/chsh /usr/bin/atrm /usr/bin/atq /usr/local/bin/sudo /usr/sbin/traceroute /usr/sbin/traceroute6

46. 72 slides46 of 112 Cybersecurity Summit 2004 Some should not need root, or shouldn’t be setuid Least privilege

47. 47 of 111 Cybersecurity Summit 2004 /sbin/ping /sbin/ping6 /usr/X11R6/bin/xterm /usr/X11R6/bin/Xwrapper-4 /usr/bin/crontab /usr/bin/su /usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/bin/login /usr/bin/passwd /usr/bin/at /usr/bin/chsh /usr/bin/atrm /usr/bin/atq /usr/local/bin/sudo /usr/sbin/traceroute /usr/sbin/traceroute6

48. 48 of 111 Cybersecurity Summit 2004 /usr/X11R6/bin/Xwrapper-4 /usr/bin/su /usr/bin/passwd /usr/bin/chsh /usr/local/bin/sudo

49. 49 of 111 Cybersecurity Summit 2004 Research/project/funding suggestion Re-engineer these programs to lower their privilege requirements – (you’ve been complaining about this in Microsoft software!) (and justifiably so) Extra funding for reducing the size of the programs Must be done on many *nix distributions, not just your favorite one

50. 50 of 111 Cybersecurity Summit 2004 AIX 4.2 & 242 & a staggering number \\ BSD/OS 3.0 & 78\\ FreeBSD 4.3 & 42 & someone's guard machine\\ FreeBSD 4.3 & 47 & 2 appear to be third-party\\ FreeBSD 4.5 & 43 & see text for closer analysis \\ HPUX A.09.07 & 227 & about half may be special for this host \\ Linux (Mandrake 8.1) & 39 & 3 appear to be third-party \\ Linux (Red Hat 2.4.2-2) & 39 & 2 third-party programs \\ Linux (Red Hat 2.4.7-10) & 31 & 2 third-party programs\\ Linux (Red Hat 5.0) & 59\\ Linux (Red Hat 6.0) & 38 & 2--4 third-party \\ Linux 2.0.36 & 26 & approved distribution for one university \\ Linux 2.2.16-3 & 47 \\ Linux 7.2 & 42\\ NCR Intel 4.0v3.0 & 113 & 34 may be special to this host \\ NetBSD 1.6 & 35 \\ SGI Irix 5.3 & 83 \\ SGI Irix 5.3 & 102 \\ Sinux 5.42c1002 & 60 & 2 third-party programs\\ Sun Solaris 5.4 & 52 & 6 third-party programs\\ Sun Solaris 5.6 & 74 & 11 third-party programs\\ Sun Solaris 5.8 & 70 & 6 third-party programs\\ Sun Solaris 5.8 & 82 & 6 third-party programs\\ Tru64 4.0r878 & 72 & \\ Setuid-root

51. 72 slides51 of 112 Cybersecurity Summit 2004 Some ways to break into a host: 3) Fool a user (system administrator?) into executing your code while privileged

52. 52 of 111 Cybersecurity Summit 2004 Modified versions of ssh client in user’s /bin directory Why was this ever executed. Did the bad guys change the PATH data Stuff like this can be checked regularly with an updated version of something like COPS. User’s are going to get this wrong (i.e. not notice it), and we are going to have to live with it

53. 72 slides53 of 112 Cybersecurity Summit 2004 If the bad guys get a user account on your Unix system, they can root the machine. Game over.

54. 72 slides54 of 112 Cybersecurity Summit 2004 Network security Engineering secure systems from insecure parts? Some assembly required

55. 55 of 111 Cybersecurity Summit 2004 Secure computing requirements Secure client Secure communications Secure server User Client host (in Molvania)

56. 56 of 111 Cybersecurity Summit 2004 Secure client You don’t have that You probably can’t have that It would be expensive and inconvenient if you do have it

57. 57 of 111 Cybersecurity Summit 2004 Secure communications Got it! We won the crypto wars In June 2003, NSA said that a properly implemented and vetted version of AES is suitable for Type 1 cryptography! Ssh is not perfect, but it is holding up pretty well

58. 58 of 111 Cybersecurity Summit 2004 Research/project/funding suggestion Formal methods for protocol design and verification This has been on some lists for a long time It is hard

59. 59 of 111 Cybersecurity Summit 2004 Secure servers That’s your job Potentially doable You must mistrust all clients, even with strong authentication!

60. 60 of 111 Cybersecurity Summit 2004 Review of security checkpoints User Client host (in Molvania)

61. 61 of 111 Cybersecurity Summit 2004 Review of security checkpoints User Client host (in Molvania) Front end

62. 62 of 111 Cybersecurity Summit 2004 Review of security checkpoints User Client host (in Molvania) Front end Big Iron

63. 63 of 111 Cybersecurity Summit 2004 Review of security checkpoints User Client host (in Molvania) Front end Big Iron File server/ File backup

64. 64 of 111 Cybersecurity Summit 2004 Review of security checkpoints User Client host (in Molvania) Front end Big Iron File server/ File backup Hacker

65. 65 of 111 Cybersecurity Summit 2004 Review of security checkpoints User Client host (in Molvania) Front end Big Iron File server/ File backup Hacker

66. 66 of 111 Cybersecurity Summit 2004 Review of security checkpoints User Client host (in Molvania) Front end Big Iron File server/ File backup Hacker

67. 67 of 111 Cybersecurity Summit 2004 Review of security checkpoints User Client host (in Molvania) Front end Big Iron File server/ File backup Hacker

68. 72 slides68 of 112 Cybersecurity Summit 2004 It is poor engineering to rely on the security savvy of the user base

69. 69 of 111 Cybersecurity Summit 2004

70. 70 of 111 Cybersecurity Summit 2004 Users are not going to pick passwords that are resistant to dictionary attacks. Period. Either don’t let them pick passwords – Inconvenient for the users – Not a panacea (see below) Or don’t give the bad guys a chance to run dictionary attacks---get out of the game – That means passwords are validated on the server, not the client – Ssh agent keys get this wrong – Bank ATM cards get this right

71. 71 of 111 Cybersecurity Summit 2004 Don’t let users pick passwords Machine can choose them. Then they get written down and/or forgotten. Not good, though post-it passwords don’t involve the usual threat models. Bad idea. – Password aging is a bad idea. Good passwords are hard to think up and remember Use multifactor authentication, i.e. hardware tokens or one-time passwords

72. 72 of 111 Cybersecurity Summit 2004 Hardware tokens It would be nice if the server end is open source The business model has never been one for global adoption Challenge/response form factor is the safest, but not accepted

73. 73 of 111 Cybersecurity Summit 2004 OTPs are not a cure-all perfect I installed these at Bell Labs in the early 1990s “We never had an undetected break-in” – me “Yes, you did.” – Steve Branigan

74. 74 of 111 Cybersecurity Summit 2004 Review of security checkpoints User Client host (in Molvania) Front end Big Iron File server/ File backup Hacker

75. 72 slides75 of 112 Cybersecurity Summit 2004 Case Study My little home network

76. 76 of 111 Cybersecurity Summit 2004 User base Me My family – (family members are like employees, from a security standpoint)

77. 77 of 111 Cybersecurity Summit 2004 Goals Easy experimentation on the Internet – No firewall for secure clients and servers Support for family computing – Shared file system – 140GB of family photos – Digital house support Experimentation with strong host security – Is it too hard to trade off convenience for security? Skinny-dipping on the Internet Protect family databases

78. 78 of 111 Cybersecurity Summit 2004 Threats Loss of data Loss of Saturdays Loss of face

79. 79 of 111 Cybersecurity Summit 2004 Tools Very few network services Moderately-well understood OS (FreeBSD) Unsafe network services in chroot jails – Belt and suspenders End-to-end encryption, always – No kiosks for reading mail… – WAP and sniffed Ethernets not a problem Two factor authentication

80. 80 of 111 Cybersecurity Summit 2004 More tools Network and host monitors for alien packets and changes to important files Lots of disk space (>1TB at home) – Onsite and offsite backups with rsync over ssh

81. 81 of 111 Cybersecurity Summit 2004 My home network User Client host (in Molvania) Family web server Shared files File backup

82. 82 of 111 Cybersecurity Summit 2004 Access rules Ssh only for non-web access Other services tunneled through ssh – With Unix or MSFT client Backup hosts unreachable from the outside, and from the server host I win if the backed up machines remain unhacked, and the file contents remain intact

83. 83 of 111 Cybersecurity Summit 2004 Results Almost ten-year old experiment – No viruses, no break-ins – Was a mail relay for a few weeks Working quite well Daughter away at school has to follow same rules for home access – My email service for her was substandard Still need a good POP3S service for me Treo Cooperative user population makes all the difference

84. 72 slides84 of 112 Cybersecurity Summit 2004 Case Study Intellink

85. 85 of 111 Cybersecurity Summit 2004 Caveat I have no current clearance I have received no briefings on Intellink

86. 86 of 111 Cybersecurity Summit 2004 Intellink Described in James Banford’s Body of Secrets Imagine a distribution system for top secret information using search engines and Internet technology Given the known security “successes” of the Internet, how the hell would you implement such a thing with a reasonable expectation of security?!!

87. 87 of 111 Cybersecurity Summit 2004 Some of my list Sealed client hardware – Client required to access the secrets – On-board crypto, that zeroizes when the box is opened, or movement or light is detected inside the box – No software updates or changes available in the field – Virtual machines for different levels of classification. Linux implementation? Probably external hardware crypto as well

88. 88 of 111 Cybersecurity Summit 2004 Client software Pick a browser, and spend a lot of money… – Ripping out unneeded features – Vetting the SSL implementation – Vetting the C compiler and libraries used

89. 89 of 111 Cybersecurity Summit 2004 Server hosts Every server is registered Only registered servers allowed Network is scanned constantly for alien hosts and servers

90. 90 of 111 Cybersecurity Summit 2004 Very strong user authentication Also, PKI and protected databases of who is authorized for what – Database is distributed among the servers, no central repository Revocation lists, tight policies with employment office to kill dead accounts

91. 91 of 111 Cybersecurity Summit 2004 Access only from within the intranet Perimeter security, tightly patrolled Firewalls (“guards”) to other networks, intensely engineered and constantly watched Intranet is wired with packet sniffers, IDS, etc. – Every anomaly is chased down – There is enough funding to do that If a virus appears, there is enough instrumentation to find out where it came from, and how far it got

92. 92 of 111 Cybersecurity Summit 2004 Policy support A big mallet to use on non-compliant users – Spooks are generally little better than normal users Mallet (which exists, for classified data) includes: – Official reprimand – Disconnection from the network – Dismissal – Criminal charges Accountability story at the NSA web site

93. 93 of 111 Cybersecurity Summit 2004 I’ve talked to some spooks Obviously, this is an incomplete list Not all safeguards are implemented as well as I might hope These guesses, and others, are pretty close to the mark – They’ve spent hundreds of thousands of dollars vetting software….Hmmm

94. 94 of 111 Cybersecurity Summit 2004 Linux SE Mods came from the NSA Quickly implemented in public Linux systems This is a nice model, could we have more, please?

95. 95 of 111 Cybersecurity Summit 2004 Research/project/funding suggestion See if some of the vetted software can be declassified and distributed Win-win funding situation for the public and the spooks Open source means you can trust the NSA!

96. 72 slides96 of 112 Cybersecurity Summit 2004 How I Would Fix This* * Given some money and a lot of clout

97. 97 of 111 Cybersecurity Summit 2004 Secure servers and big iron, and Only allow connections from special client hardware Yes, I know this is probably not going to fly, but it is the only solution that would greatly improve the situation

98. 98 of 111 Cybersecurity Summit 2004 A custom client computer is required Turnkey system No shell prompts, no root access, no network services USB key fob with PIN to login – Requires reinsertion now and then if terminal is idle Tamper-resistant key/chip zeroizes if case is opened – Contact || light || motion detected

99. 99 of 111 Cybersecurity Summit 2004 More on the client It only accesses the remote supercomputer cluster All access is over the network, and encrypted…ssh is good enough Can read data off a CDROM. Data only, no programs or patches installable This is a pain, and a little expensive: they won’t like this

100. 100 of 111 Cybersecurity Summit 2004 The network Has end-to-end encryption. Ssh with public key, plus some sort of authentication when first logging on that requires the fob.

101. 101 of 111 Cybersecurity Summit 2004 The server Since keeping users out of root is hard, each user gets his own virtual machine on the server He can run batch or interactive stuff. The server may be a front end to clusters or other hardware

102. 102 of 111 Cybersecurity Summit 2004 Other mitigations Static kernel defeats loadable hacking modules – You do recompile your kernel from sources anyway, don’t you? B1 systems – A further major administrative nightmare – But it could help a lot

103. 103 of 111 Cybersecurity Summit 2004 Research/project/funding suggestion How can we chroot user-level programs? I don’t trust my browser, and would like to jail it Chroot doesn’t hack it There have been a number of papers on the topic, back over 10 years None are widely implements Browser plus jailing config file

104. 104 of 111 Cybersecurity Summit 2004 Summary: we ought to win these battles We control the playing field DOS is the worse they can do, in theory We can replicate our successes We can converge on a secure-enough environment

105. 105 of 111 Cybersecurity Summit 2004 Some successes Linux SE – Helpful feedback from NSA – I’d like to see a lot more of this Programs written by security fanatics – Postfix (mail transport) – Openssh (secure terminal sessions and file transport)

106. 106 of 111 Cybersecurity Summit 2004 A few projects Secure Debian OpenBSD and others NSF Cyber Trust looks promising Variety of other research operating systems

107. 107 of 111 Cybersecurity Summit 2004 This is openssh One of the successes of the last decade Not quite perfect, but much better than the alternatives – No excuse to run telnet or ftp (except anonymous) any more Yes, you can afford the overhead for crypto, even when moving terabytes – Thanks to Moore’s law, you are unlikely to notice it

108. 108 of 111 Cybersecurity Summit 2004 Software scales Linus can write a kernel Don Knuth can write a kernel Profit is not necessarily an obstacle to engineering the software we need LinuxSE

109. 109 of 111 Cybersecurity Summit 2004 Executive Summary - I Internet security is still quite hard, and we are not very good at it Internet security is hardest when we are supporting a large number of users – If we can’t control their security, they become the source of attacks Security is hardest in an open environment We don’t have hard answers, just mitigations Attacks like these will happen again

110. 110 of 111 Cybersecurity Summit 2004 Executive Summary - II We’ve actually gotten noticeably better at Internet security in the past decade – Strong encryption is easy and can be ubiquitous – Robust clients are increasingly possible – Much server software is stronger now – Microsoft is trying to clean up their act None of this is easy to explain to non- technical funders who read about it on the front page of the newspaper

111. 72 slides111 of 112 Cybersecurity Summit 2004 Conclusion The problem of secure computing in an open environment with many users is unsolved, and it appears to be quite hard. The best we can hope for is gradual mitigation, converging on a safer world.

112. 72 slides112 of 112 Cybersecurity Summit 2004 You will not see the end of this process, nor are you allowed to desist from it