Security and Object-Orientation

1. Security and Object-Orientation CSE301 Harry R. Erwin, PhD University of Sunderland School of Computing and Technology

2. Roadmap to the Briefing • Resources • Security Requirements • Object-Orientation and Security • Java Support for Security • Conclusions

3. Resources • http://java.sun.com/security/index.html • http://java.sun.com/j2se/1.4.1/docs/guide/security/ • B. Schneier, 2000, Secrets and Lies, Wiley, ISBN: 0-471-25311-1. A good survey of the current threat environment. • P. Neumann, 1995, Computer-Related Risks, Addison-Wesley, ISBN: 0-201-55805-X. A survey of risks encountered by computing professionals. • R. Anderson, 2001, Security Engineering, Wiley, ISBN: 0-471-38922-6. An excellent UK textbook. • Garfinkel and Spafford, Practical Unix and Internet Security, O'Reilly, ISBN: 1-56592-148-8. The classic book on computer security. • Norberg, 2001, Securing Windows NT/2000 Servers, O'Reilly, ISBN: 1-56592-768-0. A detailed Windows checklist. A UNIX checklist is provided at www.cert.org. • Zwicky, Cooper, and Chapman, 2000, Building Internet Firewalls, second edition, O'Reilly, ISBN: 1-56592-871-7. Another classic.

4. Sources • Karger and Schell, 2002, “Thirty Years Later: Lessons from the Multics Security Evaluation,” IBM Technical Report RC22534 • Bell and La Padula, 1976, http://csrc.nist.gov/publications/history/bell76.pdf, Contains significant history as well, 134 pages! • DoD Std 5200.28 (TCSEC), “The Orange Book”, http://csrc.nist.gov/publications/history/dod85.pdf • Trusted Network Interpretation, “The Red Book”, http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-011.html • ISO/IEC 15408:1999, the Common Criteria.

5. Security Defined • “Freedom from undesirable events”. (Neumann) • There are usually three elements to security (Qinetiq): • Confidentiality—protection of data from unauthorized access. • Integrity—protection of data from unauthorized modification. More generally, certain desirable conditions are maintained over time • Availability—making sure the system is usable by authorized users.

6. Early Work • The key paper is Bell and La Padula, 1976, which set out the requirements for a secure Honeywell Multics OS. • The major concern at the time was provable security—the systems being analyzed would be managing classified information. A lock and key approach was taken. • These systems would used by cooperative users in isolated mainframes. Usability and performance not major concerns. • It was shown that a security kernel satisfying a small number of axioms could be proven secure. • Led to the ‘Orange Book’ with Secure Multics the model. • Ancestor of the ‘Common Criteria’ (ISO/IEC 15408:1999).

7. Some (but not all) Recommended Mechanisms and Procedures • The TCSEC and the Common Criteria recommend the following: • Access Control • Object Reuse/Media Sanitizing • Identification and Authentication • Audit • Virus Protection • Configuration Management

8. Access Control • Based on what the user is authorized to do. • Discretionary access control is where the document owner controls who has access to it. This is designed for benign environments. • Mandatory access control defines a security level for documents and resources. A potential user or process has to have that level. • Commercial organizations may go further—time of day, location, task being performed. • Should be enforced by operating system kernel.

9. Object Reuse/Media Sanitizing • The random bits in memory or on the disk contain information. Most operating systems do not zero these bits when they reallocate resources. • A secure operating system zeros memory and other resources before allocating them (and often when the resources are released).

10. Identification and Authentication • Identifies someone to the system. • At least one of the following must be supplied: • Something known (user name and password) • Something owned (password token) • Some physical characteristic (fingerprint, retinal scan, voice scan) • Authentication is weak if only one is supplied. • Two are required for strong authentication.

11. Audit • Tracks who did what and when. • Done right, can stand up in court as evidence. • Usually must be turned on (selectively). • May result in large audit files. • Audit trails are extremely interesting to hackers—show what can and cannot be seen.

12. Virus Protection • Viruses (and other malware) are the most serious vulnerability of modern computer systems. Already identified in the Multics Security Evaluation (1974). They are usually malicious. • Many websites now upload commercial ‘malware’ when you visit them. • Virus protection depends on: • Careful procedures for dealing with untrusted programs and data. • Programs to detect the ‘signatures’ of viruses that manage to penetrate the installation procedures.

13. Configuration Management (CM) It is difficult to secure a system whose configuration is not defined and managed. • User software and hardware modifications to workstations may occur. • Security may not be enabled. • Security may not be managed and configured. • Threats may not be addressed in a timely fashion.

14. Internet Insecurity • These mechanisms were suitable for isolated, un-networked computers running in a benign environment. The internet is another story. • For distributed environments, the Bell-LaPadula model of security fails. “We can tell when a security violation occurs, but we cannot prevent it from occurring” (Marshall Abrams). • This resulted in the withdrawal of the Red Book. • Neither Windows nor UNIX were originally designed for secure operation. Upgraded to C2/TCSEC. Both are currently CM nightmares, especially Windows.

15. 21 Oct 2002 Internet Information Services MDAC—remote data services MS SQL NETBIOS Anonymous logon Weak LAN manager authentication Weak passwords Internet explorer (many) Remote registry access Windows scripting host Current Top 20 Vulnerabilities – Windows(www.sans.org) • 21 Oct 2004 • W1 Web Servers & Services • W2 Workstation Service • W3 Windows Remote Access Services • W4 Microsoft SQL Server (MSSQL) • W5 Windows Authentication • W6 Web Browsers • W7 File-Sharing Applications • W8 LSAS Exposures • W9 Mail Client • W10 Instant Messaging

16. Current Top 20 Vulnerabilities – UNIX(www.sans.org) • 21 Oct 2004 • U1 BIND Domain Name System • U2 Web Server • U3 Authentication • U4 Version Control Systems • U5 Mail Transport Service • U6 Simple Network Management Protocol (SNMP) • U7 Open Secure Sockets Layer (SSL) • U8 Misconfiguration of Enterprise Services NIS/NFS • U9 Databases • U10 Kernel 21 Oct 2002 • RPC • Apache • SSH (use SSH2) • SNMP • FTP • R-services • LPD • Sendmail • Bind • Weak passwords

17. Network Security Strategies (Zwicky, 2000) • Least privilege—processes and users should have only the privileges they need for their job • Defense in depth—multiple security layers • Choke point—limit access to your system • Weakest link—attacks will seek vulnerabilities • Fail-safe stance—deny access if the system fails • Universal participation—everybody buys in • Diversity of defense—multiple mechanisms • Simplicity—only the simple can be made secure • Security through obscurity—is valid (but weak)

18. Network Security Mechanisms • Firewalls • Intrusion Detection Systems • Encryption

19. Firewalls • Control access to protected assets. • Workstation firewalls are the minimum. • Bridge/router/switch firewalls should: • Control access to TCP/IP ports selectively. • Track outgoing as well as incoming packets. • Monitor packet contents if possible. • SOAP “bypasses corporate firewalls.” (Microsoft)

20. Intrusion Detection • Must be based on documented policies for use of the system. Uses expertise. • Can detect evidence of • Break-ins • Remote exploitation • Application-level exploitation • Generates log files of great interest to hackers. • Does not detect one-time events • Active research area—anyone for a PhD? See me and Malcolm Farrow.

21. Cryptography • Can support virtual private networks (VPNs) and closed user groups (CUGs) where information is sent using encrypted tunneling. Usually peer-to-peer. • May support strong authentication. • ssh, sftp, ssl, Kerberos, PGP, etc. • Functional infrastructure required may be extensive. Distribution of keys is extremely manpower-intensive and expensive. PKI allows the distribution of keys ‘in-band’ (over the network). YMMV.

22. Security Today: Lessons Learned • Security has to be monolithic; distributed security is demonstrably insecure. • Security has to be designed in by experts from the beginning; security can’t be imposed after the fact. • Security has to be simple and easy to use correctly. • Security should not be bypassable. • Multiple mechanisms are good. • Defense in depth is good.

23. Object Orientation and Security • Security must be designed into the infrastructure: it should not be variably implemented or bypassed by individual programmers. • Security should be ‘final’; i.e., non-polymorphic. In C++, this can be done (carefully) using template policies. • In a networked environment, security depends on careful configuration management. • Enforcement of least privilege should be built into the system.

24. Java Approach to Security • These considerations led the developers of Java to embrace a ‘sandbox’ model—distrust all input data and code, particularly code. • This ensures that malware cannot gain access to system resources. Similar to a chroot jail. • Also applies to the file system in the form of a Java Protected Domain (JPD). • Tools: • Class loader • Byte-code verifier • Security Manager

25. Java Security Goals These revolve around access control: • Only correct classes are loaded • Classes are correctly formatted • Untrusted classes are restricted from executing dangerous instructions • Untrusted classes cannot access protected system resources (Other security goals are not precluded.)

26. A Few Comments • The JPD and the restrictions on untrusted classes can be used to enforce least privilege, especially with Java 1.2. • Input data must still be validated. • Java applet and program access is only to a JVM, serving as a choke point. But Java security is only an element of a defense in depth. If running under Windows or UNIX, the usual vulnerabilities exist. • Java provides multiple security mechanisms. One problem with using them is US export restrictions. • Configuration management is still necessary.

27. The Sandbox • Untrusted applications are restricted to a sandbox. • Damage can be done in the sandbox, but will not affect other applications, system resources, and files. • Restrictions can be placed—note the can—to limit what untrusted applications are allowed to do. • Java security functionality is designed to form a kernel that the application cannot break into.

28. The Class Loader • Applets (and other classes) are invoked by loading them with the Class Loader. • This fetches the code and enforces the namespace it runs in. • Applets cannot replace system-level components of the JVM. • Applets are restricted in the methods they can call.

29. The Byte-Code Verifier • Treats the code of untrusted applications as malware. • Verifies the language specification. • Detects and blocks bypassing of Java security. • Protects against stack overflow and underflow. • Protects against illegal data conversions and attempts to access private data. • This is all done prior to the code being allowed to execute.

30. The Security Manager • Performs run-time verification of methods that do file I/O, network accesses, or attempt to create a new Class Loader. • Maintains the borders of the sandbox. • Maintains thread integrity. • Controls access to Java packages. • With Java 1.2, you no longer need to subclass the SecurityManager to enforce specialized policies.

31. JavaSecurity API • Supports: • Digital signatures • Message digests • Key management • Access control lists • In Java 1.2, policies and permissions have been introduced to allow more fine-grain control.

32. Applications and Applets • Java applications with Java 1.2 are no longer fully trusted. The SecurityManager can be invoked at JVM start using the system’s default security policy, and the default policy can also be augmented. • Applets remain untrusted. By default, • Cannot access files • Stand-alone applet windows are labeled • Cannot access the network. • “Signed applets” can be trusted. These are delivered in JAR format and are digitally signed.

33. Cryptography • Subject to US export controls • The Java Cryptography Extension (JCE) gives you advanced cryptography.

34. End-User Security in Java • Personal policy files can be written using policytool and executed using the -D option. The user has to install a SecurityManager, also using the -D option. • Default security policies are satisfactory. These are available in .java.policy in the user’s home directory. • Multiple permissions are available. • This is a good deal stronger than Windows or UNIX.

35. Conclusions • You should now have a better understanding of security. • You should understand why security is too important to leave to the individual programmer. • You should understand why security should be part of the environment that object-oriented programs run in. • You should understand what general tools Java gives you to deal with security.