Whose Security Is It, Anyway? Security Expectations for Webmasters

1. Whose Security Is It, Anyway? Security Expectations for Webmasters Bo Pitsker, Communications Analyst Lawrence Livermore National Laboratory December 4, 2002

2. Disclaimer This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. This work was performed under the auspices of the U.S. Department of Energy by the University of California, Lawrence Livermore National Laboratory under Contract No.W-7405-Eng-48.

3. Our agenda today is straightforward • • Brief background • • Dividing up the security space • Application security • Web application architectures • Securing your web site • Summary • Q & A

4. “To provide a world-class research and development environment that enables the scientific and technological missions at LLNL without sacrificing its intellectual property or compromising sensitive information” What is our security perspective?

5. The security infrastructure will strive to make legitimate access to information as transparent as possible, yet become "opaque" to hostile actions. How will we do this?

6. You already know that DOE and the Federal government have mandated numerous security policies You are not a security professional You are a webmaster, or are responsible for a web site You are moderately technical, or are faking it Assumptions of this presentation

7. LLNL developer, desktop publishing, analyst during the 1980s Worked in all aspects of industry in the 1990s Deployed 1000s of nodes into trade shows Managed system operations worldwide for Pilot Network Services Highly secure web sites Internet access protection VPNs and remote access Secure data centers Caution: I am not a security expert What’s my background?

8. There’s a huge variation the volume of attacks by industry Entertainment Financial services Government and higher education The perpetrators range from 14-year old boys to highly skilled professionals Overall computer security compromises are more frequently inside jobs, but web sites are usually attacked from the outside Some basic facts about web security

9. Defacements – altering the appearance or what is presented to the browser Web content alteration – may not be obvious Site hijacking – using the site systems for other purposes, such as launching DDOS attacks, for which the site will be blamed Denial/Distributed Denial of Service attacks – cripples the site to make it unavailable to users Attack types are varied, but fall into a few basic categories

10. Browsers Servers Protocols Operating systems Applications Why web security is hard – there’s too many moving parts!

11. Only three layers matter: Network Operating system Application Web servers and web sites are applications! However: the dividing line between operating systems and applications is fuzzy The OSI network model can be adapted for a security threat model

13. Design networks to enhance security Use many subnets; each one should be dedicated to a single function Used dedicated VLANs Screen out unwanted protocols, networks and users Routers can help with aggressive ACLs Firewalls can help with stateful inspection Proxy servers can help with application-level filtering Network security is the first line of defense

14. Perform AAA at the network layer Employ intrusion detection systems (IDS) Turn your network management system into an IDS by watching for the wrong traffic on the wrong subnets FTP on the web subnet = wrong! HTTP on the mail subnet = wrong! SQLnet traffic on the web subnet = wrong! Telnet anywhere = wrong! Network security is the first line of defense (cont.)

16. Use stripped down kernels with minimal functionality Apply OS patches religiously Disable all services and ports not needed by the applications on that system Use only secure means of access, and cripple the rest Disable telnet, FTP, RAS etc. Use SSH, SFTP, SCP instead Operating system security is designed to “lockdown” servers (and workstations)

17. Far less standardization Little or no shared experience Diversity of protocols, UIs, and APIs Many applications trust the OS too much Assume local (system) users are validated by OS Assume system routines aren’t vulnerable Application developers have little or no exposure to security issues Lack treat analysis and risk assessment May or may not understand AAA requirements Frequently rely on unproven algorithms or code samples Application security is the “soft underbelly” of computer security – why?

18. The level of web site sophistication varies Static HTML display on single server Basic CGI scripts and scripting languages Multiple services on same system; e.g. Apache and PHP Two-tier architectures; Apache web server with MySQL database Three or n-tier architecture; e.g. web server-application server-database server Let’s review web site application architectures

19. Client side – usually Java applet or ActiveX control Server side – server-side includes, Java, Javascript, ASP pages, etc. Distributed applications – frequently relies on middleware such as CORBA, DCOM, RMI etc. Where do web applications live?

20. Open to the entire Internet; e.g “public” servers Can’t screen users Resides on Green (i.e. DMZ) network Has maximum vulnerability Open to controlled user from Internet Can screen users via AAA Also resides on Green network Network security may reduce some risks Web sites can be characterized by the degree of exposure to the Internet

21. Open to the Internet but not accessible from the Internet No external users per se Internal users always initiate connections to the Internet Resides on Yellow (i.e. restricted) network Still has some vulnerabilities UDP services hard to protect Spyware, trojans, or malware can lead to compromises of systems Web sites can be characterized by the degree of exposure to the Internet (cont.)

22. Authentication Determines who the user is Numerous security levels, from simple cookie setting to two-factor authentication with “hard tokens” May require assertion of “role”, not just identity Authorization Defines the resources a particular authenticated user may access May define privileges for each user/resource combination May include role-based privilege sets Should enforce the “principle of least privilege” Defense against users: the triple play -AAA

23. Accounting Logs resource usage Management logs Security logs Billing records; e.g. chargebacks Record retention requirements LLNL retains web log files a minimum of 60 days for security purposes Numerous logging mechanisms exist, but require specialized analysis tools or scripts to interpret Transaction-based systems may use a TP monitor Defense against users: the triple play –AAA (cont.)

24. Getting started Design and architecture Securing the web server processes Evaluating off the shelf software Check external sources for possible compromises of your applications Developing reasonably secure in-house applications Securing your web site

25. Perform a threat analysis and risk assessment Who could be interested in your site? What’s the value of the information on your site? What harm could occur if someone gets root on one of your systems? What legal liabilities or obligations apply to you? Ensure network security is in place for all networks supporting your web site Ensure OS security is in place for all systems supporting your web site Getting started

26. Ensure that your web server is on an isolated subnet Break up site components on separate systems and networks See if you can “push” data from a secure server to the public server (e.g. using rdist) If data can’t/shouldn’t be pushed, then put each system on a different subnet Each system should accept only restricted network connection types, and possibly, restricted networks Move functionality deeper into network Design and architectural considerations

27. Run web server and related process under a unique UID – not root If superuser privileges needed, e.g. to bind ports, initialize with one program, then execute the remainder without privileges Limit server process directory/file access Turn on logging, and rotate logs off server every day Tune system resource usage to withstand DOS attacks; e.g. max threads, TCP timeout parameters, etc. Secure the web server processes

28. Ensure you obtained the application from a trusted source – trojan software is appearing more frequently Look at privileges required by application – just like system processes, should not run as a daemon, require access to entire file system, etc. Ensure that any administrative interface is on a different port than the ordinary user Evaluate off the shelf software

29. Check that appropriate protection is given to non-public information Logins should be protected with SSL/TLS Stored information should be encrypted Stored information should be kept deeper in the network behind additional firewalls AAA should be available, at least as an option Check various sources for known vulnerabilities Your CISSO or security professsional Public organizations: CERT, CIAC, FIRST Private organizations: Bugtraq, SANS Institute Patch, patch, patch! Do not fall behind on patch levels Evaluate off the shelf software (cont.)

30. By all means consider open source if commercial applications aren’t the best choice Incorporate your threat analysis and remediation into your specs Scrutinize carefully external scripts, libraries, plug-ins or CGIs Developing reasonable secure in-house applications

31. Where does user input come from? URL parameter strings HTML forms (GETs and POSTs) Browser-stored information (e.g. cookies) Database queries Environmental variables set by other processes accessible to a user Reject anything not expected Ensure that you are receiving a string Accept only those characters needed by a specific field (positive input filtering) Accept specific field formats only Truncate input to a reasonable maximum length Thou shalt filter thy inputs aggressively!

32. Specify which character set is being used; e.g. ISO-8859-1 Consider how browsers might interpret HTML special characters Consider encoding dynamic output elements (e.g. using numeric entry values) Filter your output, much like you filter input Filter cookie values to ensure malicious values haven’t been set Follow CERT recommendations for mitigating output vulnerabilities

33. Section 508 ADA requirements Privacy restrictions and notifications Privacy policies of various agencies Cookie restrictions Session cookies require warning to users Persistent cookies can’t be used without permission from DOE HIPPA (covers patient data and medical records) Federal Privacy Act of 1974 Check your sites for consistency with DOE and other Federal government mandates

34. The security responsibilities of the webmaster include: Ensuring that security is considered early and often Ensuring that network and operating system environments are sufficiently secure Ensuring that the design and implementation of the web site follows security “best practices” Ensuring that continued monitoring and reviews are performed If this seems overwhelming, get professional help! Contrary to popular opinion, public sites can be made secure; it’s just a matter of hard work Summary (and you thought we’d never get there!)

35. Q & A