Content Server Security Challenges and Best Practices Brian

Content Server Security – Challenges and Best Practices Brian “Bex” Huff, Software Developer Stellent, Inc. January 30, 2006

Purpose § Outline what you need to protect your content • How Content Server fits into your security policy • Use risk-management to minimize cost § Discuss risks and known vulnerabilities • General network briefly, Stellent in detail § Present countermeasures to mitigate risks • General network briefly, Stellent in detail

Brief History of Internet Security § Early days • Little security except governments, banks, and telcos • Most software was far too trusting § First virus (1983), worm (1988), and trojan (1200 BC) • Networks must defend against malware • Sparked battle between cryptographers and US government § Tech boom: • http: //www. BURN-PILES-OF-MONEY. com • Spent on security, but didn’t understand it § Tech bust • All projects must justify expense, security was neglected

Brief History of Internet Security, cont. § Today • Little security except governments, banks, and telcos § The Future • Annoying/disruptive malware is for amateurs • Intellectual property theft is the future • Cheap and effective industrial espionage • Database, file server, web-based CMS are next targets • Popularity of web services will lead to new attack forms

Cyber Crime Statistics § Affected 55 million Americans in 2005 (USA Today) § Yearly costs estimates vary wildly • $105 billion (2005, Treasury Department) • $1 billion (2003, Gartner) § 42% of Americans used internet LESS in 2005 • Identity theft scares them away (Gartner) § Customers go elsewhere after security breaches (Ponemon) • 70% would leave after two thefts of customer data • Each customer record lost costs $75

What Should We Do? § Don’t panic! • 100% security neither possible nor cost-effective § Ultimately, people make your assets secure • Security products (hardware, software) merely assist • Make your network defensible § Consider security like risk management • Security breaches always possible • Can lower the odds, for progressively more money • Minimize risk for the minimum price § “Security is a process, not a product” – Bruce Schneier

Making A Security Plan 1. Determine risks and threats • Who is attacking you, and why? 2. Describe policy required to defend • Who should be allowed to do what? • Sarbanes Oxley compliance may also require this 3. Analyze vulnerabilities, design countermeasures • Cover all aspects: Protection, Detection, Reaction

1) Determine Threats and Risks § Definition of Risk • Probability and effects of a harmful event • Risk = Threat x Vulnerability x Impact • Threat: person with skills and motive to leverage vulnerability § Standard Consumers – LOW Risk • Customers, partners, site visitors, Google • Using leaked information against you § Contributors – MEDIUM Risk • Typical employees, Site Studio contributors • Information leakage, bad passwords, malicious content

1) Determine Threats and Risks, cont. § Administrators – HIGH Risk • Site maintainer • Setting security improperly, stealing content § Developers – HIGH Risk • Component, fragment, or portal designers • Creating insecure code on your system § Unauthorized Users – HIGHEST Risk • Hackers, malware, ex-employees, differs based on organization § Oft cited stat: 70% of attacks are insiders

2) Determine Security Policy § Specifics depend on organizational needs § Enterprise network policy • General process for users, administrators, applications • Most likely you have one already § Content Server specific policies • Who is allowed to view/change each type of content? • When is content fit for consumption? • Do contributors need access to scripting languages? • JSP, ASP, Java. Script • Which add-ons and components are secure?

3) Vulnerabilities and Countermeasures § Protection, Detection, Reaction § Vulnerabilities common to all enterprise systems • Security holes in OS, web server, database • Bad passwords, eavesdropping, malware • Evil developers and administrators • Probably addressed in your current security policy § Vulnerabilities common to web apps • Cross Site Scripting (XSS) • Information leakage

Vulnerabilities in Stellent § Java-based, immune to buffer overflows § Primary vulnerabilities in interfaces • Connection to authentication engine • Web server, portal server, LDAP • Database connections (SQL injection) • Administrative tools can impersonate users § Contributors uploading insecure content • Incorrect security group • Malicious ASP / Java. Script / HTML Forms § Insecure components

Protection - High Risk Vulnerabilities § Important regardless of your organization § General network security § Cross site scripting § Malicious content § Content server port access

General Network Security § Keep software/firmware patches up-to-date • 99% of attacks are known exploits (CERT) § Vulnerability analysis tools (Nessus, Metasploit) • Highly flawed, but catches known exploits § Secure network topology • Firewall both external and internal attacks (DMZ) • Minimize required trust and single points of failure § Restrict physical / shell access § Virus/Trojan scanners at internet gateway • Block malicious emails & web downloads • Cannot trust users to make secure decisions!

Cross-Site Scripting (XSS) § HTML & HTTP flexibility very useful: • Form on my site to submit a Google search • Click submit, search results displayed in your browser § But could cause security problems: • Click submit, content deleted from your server invisible to you § Attacks can originate from ANYWHERE: • Form submission, URLs, or simple page loading • Attacks can be Java. Script, or pure HTML § Executed with your browser & security credentials • Hacker tricks you into attacking the server for him • Advanced attacks with AJAX can hijack your entire browser!

Cross-Site Scripting, cont. § Block forms submitted from untrusted sites • Block insecure HTTP referrers (Html. Post. Authenticator) • Can be spoofed, in this case its usable • Block malicious URLs: Enable. Secured. Gets=true § Scrub XSS attacks from request data (Filter. Data. Input) • Blocks Java. Script in metadata, content, URL parameters • Especially important for anonymous contributors • Comments forms, resume submissions • Significantly restricts your “power users”

Malicious Content § Virus scanner on stellent/vault/~temp directory • Checks for malicious / careless contributors § Lock down JSP/ASP contribution to just developers • Lock down JSP with Jsp. Enabled. Groups • Enable ASP only for specific security groups • http: //myhost/stellent/groups/scripts/ • Remove secure data from JSPs/ASPs • Consumers with access to native file can view the source § Malicious HCSP same as malicious HTML • Idoc. Script limited to page display for security reasons

Direct SCS Port Access § Authentication performed outside of SCS • Web server authenticates, passes username to port 4444 • Out of the box, only localhost is trusted • With dedicated server & trusted admins, fairly safe § Rogue administrator can impersonate users • Content Integration Suite (CIS), Idc. Command. UX • SOAP is safer – password authenticated by web server § First: block access with firewalls • Block all but web server and portal server • Restrict to specific users if possible • More safe than just Socket. Host. Address. Security. Filter

Direct SCS Port Access, cont. § Second: password secure access (Proxy. Connections) • Set Proxy. Password to a large random string • Web server sends secure authentication token: • User, hashed user password, IP, time, and Proxy. Password • Blocks connections without token • Some admin tools blocked • Manually create token for portal servers (CIS, Idc. Command. UX) § Or Third: encrypt access with SSL (Security. Providers) • CIS only, default web server not yet supported • Authenticate with SSL certificates • For systems with extraordinary needs

Protection - Lower Risk Vulnerabilities § Less important, depending on organization and network § Data leakage § Eavesdropping § Passwords § Hacked database, file server, web server

Data Leakage § How much does Google know about you? § Simplify the security model • Less accidental information leakage • Use security groups to secure, not to organize! • Use Profiles / Web. DAV to simplify contribution § Workflows for public facing content § PDF Watermark, Dynamic Watermark • Embed the word CONFIDENTIAL in converted PDFs • Add date and viewer’s name with Dynamic Watermark § Need. To. Know component • User can view some metadata, but not content

Eavesdropping § Network vulnerable to packet sniffers • Spy on downloaded content or passwords § Use SSL (HTTPS) • Protects passwords and content • Important for Basic authentication and cookie login • NTLM authentication is already “encrypted” • Drawback: performance suffers § Customizations: use SSL only when needed • Login with cookies from HTTPS page • Set up both HTTP and HTTPS (Browser. Url. Path) • Use SSL only for contributors / administrators

Password Hacking § Cannot trust users with their passwords • 70% give away passwords for chocolate (BBC) • Computers getting faster, passwords still 8 letters • Reused passwords, easily guessed passwords § Use Single Sign On (SSO) • NTLM, Active Directory, LDAP, Netegrity Site. Minder • Eases maintenance of passwords, users, new applications • Drawback: no login prompt can make XSS worse § Don’t allow users to know their access key! • USB / smart cards with SSL certificates for authentication • Protect certificate with password • Add biometrics for more security • In practice, managing such keys is very difficult

Hacked Web Server § Web server primary target for unauthorized users • Typically exposed to outside world • Firewalls help, but don’t stop everything § Password secure SCS / web server connection • Require access tokens (Proxy. Credentials) • Hacker cannot impersonate users § Web proxy for extra security layer • Run web server on same machine as SCS • Connect to web server with proxy (Squid) outside firewall • If proxy is hacked, SCS is still safe (for now)

Hacked File System § Compromise of SCS machine or file server • If user gains root access, anything is possible § Use NTLM/Kerberos authentication for Database • No need to store Jdbc. Password • SQL Server: Use JTDS 1. 2 driver, manual install • Oracle: Use version-specific thin driver § Encrypted file system • Secure the vault, weblayout, search, data directories • Performance loss, might not work with web server • Expanded support with File. Store. Providers (8. x)

Database Connections § SQL Injection attacks • Similar to XSS – malicious SQL through hacked web form • Can take over database through some web applications § SCS protected by abstraction layer • SQL in predefined queries, strongly typed parameters § SCS validates user-submitted data • Parses dates, numbers, escapes quotes in strings • Extra parenthesis added if found in query terms § Reduce table-modification rights of Stellent JDBC user • Adding metadata, schema, components requires DBA approval • User-level activity unaffected

Protection - Risks in Customizations § Difficult to measure § Untrusted developer making customizations § How to make secure components § Possible security customizations

Malicious Components § Difficult to defend against • Requires complete auditing of code for back-doors § Install “development” servers • Protects content against rogue developers • Components audited and installed by trusted admin § Block Admin Server component installs • Restrict to Component Wizard from the console • Allow. Update. Component. Config, Allow. Component. Upload

Secure Component Tips § Validate HTML form data in Java • Java. Script is handy, but not trustable § Encode Idoc. Script variables on pages • Idoc. Script functions: js(), xml(), url() • Prevents introduction of new XSS attacks § Use predefined SQL queries, avoid raw SQL • Predefined queries thwart SQL injection § Execute command-line applications with caution • Validate the command first

Secure Component Tips, cont. § Use the check. Security action in custom services • Service security flags require d. Security. Group to be present • Cannot trust values sent by the user • First determine d. Security. Group with SQL query • Then call check. Security action in service § Expect people to call custom Idoc. Script maliciously • Restrict functionality to read-only actions • Workflow Idoc. Script allows write actions in special context • Condition variable allow. Workflow. Idoc. Script

Security Customization Examples § Modify security with Java components • Web security plugins require C++ code § Allow anonymous user to check in content • Security. Filter component in 7. 5 How. To. Components • Deny general access, allow it for specific requests § Establish download quotas • User can only download 50 MB per day § Block certain service calls for consumption servers • Block SOAP or Web. DAV explicitly • With firewall, or customization • Block all services except bare essentials (SS_GET_PAGE)

Security Customization Examples, cont. § Custom validation of metadata and content • Content Profile rules, or Java filters (validate. Standard) § Java User Providers for authentication • For legacy or atypical authentication protocols § Custom web authentication • Custom authentication filters (Site. Minder, SSL Certificates) • Custom tokens for flexible SOAP security • Block login after 3 bad passwords § Custom cookie login • Existing sample version doesn’t have a timeout • Be sure to hash the username, a timestamp, and a secret

Detection – Network Violations § Check logs frequently • Firewall, intrusion detection, web server • Sometimes only human eyes catch ‘suspicious’ behavior § Syndicate access logs to remote servers • Must compromise several systems to “cover your tracks” § Intrusion detection systems (Snort, some firewalls) • Detects known attacks, generally suspicious packets

Detection – SCS Specific § Check SCS web logs • Access violation logged • Login failures not automatically logged • Use SSO or custom component § Content Tracker • Tracks popularity – who viewed what? • Check for allowed – but unusual – activity: • Downloading data before quitting • Downloading random highly secure data • Excellent dual-purpose technology

Reaction – Respond to Intrusion § Someone someday will bypass all your security • Reaction depends on business needs • Block access with firewall? Unplug from network? • Minimize damage and disruption while you patch § Establish backup and recovery plans • Backup all applications and data • Most high-availability sites have sufficient plans § Redundancy is primary • System must survive a crash / compromise of one server • One compromise shouldn’t lead to several

Reaction – SCS specific § Block hacked user accounts • Supported by some SSO vendors • Block the administrator (Sysadmin. Blocker) § Make database read-only • Block ‘commit’ rights to Stellent’s JDBC user at the database • Blocks ALL write activity, possible side effects • Make Counters table read-only • Blocks all transactions

Conclusions § Stellent less vulnerable than most systems • Smaller target than operating system, database • Recommendation: block XSS and direct port access • Others countermeasures as needed § Which countermeasures to use? • First, use dual-purpose technology • SSO, web proxies, Content Tracker • Second, select those with little cost/drawbacks • Proxy. Credentials, SSL, simplified security model • Lastly, select those with significant cost/drawbacks • Scrub Java. Script content, SSL Providers, custom components

Useful Links § Security Books: • Secrets & Lies: http: //www. amazon. com/gp/product/0471453803 • Source for some material presented here • Counter Hack: http: //www. amazon. com/gp/product/0131481045 • Hacking Exposed: http: //www. amazon. com/gp/product/0072260815 • Network Security: http: //www. amazon. com/gp/product/0072226978 • Tao of NSM: http: //www. amazon. com/gp/product/0321246772 § Open Source Tools: • Vulnerability Analysis: http: //www. nessus. org/ • Intrusion Detection: http: //www. snort. org/ • Packet Sniffer: http: //www. ethereal. com/

Questions? § Contact Information: • Brian ‘Bex’ Huff <bex@stellent. com> • http: //www. stellent. com • http: //groups. yahoo. com/group/intradoc_users/ § See Session 1502 on SSO Integrations § See Session 908 on Disaster Recovery § Please complete the session survey before you leave today Access this presentation* and materials at: http: //www. stellentcrescendo. com/Crescendo/Sessions/index. htm *Log-in and password required to access presentations (watch for an email containing your codes)