Presentation on theme: "Whose Security Is It, Anyway? Security Expectations for Webmasters Bo Pitsker, Communications Analyst Lawrence Livermore National Laboratory December 4,"— Presentation transcript:
Whose Security Is It, Anyway? Security Expectations for Webmasters Bo Pitsker, Communications Analyst Lawrence Livermore National Laboratory December 4, 2002
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.
Our agenda today is straightforward Brief background Dividing up the security space Application security Web application architectures Securing your web site Summary Q & A
What is our security perspective? “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”
How will we do this? The security infrastructure will strive to make legitimate access to information as transparent as possible, yet become "opaque" to hostile actions.
Assumptions of this presentation 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
What’s my background? 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
Some basic facts about web security 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
Attack types are varied, but fall into a few basic categories 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
Why web security is hard – there’s too many moving parts! Browsers Servers Protocols Operating systems Applications
The OSI network model can be adapted for a security threat model 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
Network security is the first line of defense 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 (cont.) 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!
Operating system security is designed to “lockdown” servers (and workstations) 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
Application security is the “soft underbelly” of computer security – why? 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
Let’s review web site application architectures 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
Web sites can be characterized by the degree of exposure to the Internet 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 (cont.) 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
Defense against users: the triple play - AAA 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 (cont.) 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
Securing your web site 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
Getting started 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
Design and architectural considerations 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
Secure the web server processes 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.
Evaluate off the shelf software 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 (cont.) 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
Developing reasonable secure in-house applications 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
Thou shalt filter thy inputs aggressively! 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
Follow CERT recommendations for mitigating output vulnerabilities Specify which character set is being used; e.g. ISO 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
Check your sites for consistency with DOE and other Federal government mandates 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
Summary (and you thought we’d never get there!) 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