Content Server Security – Challenges and Best Practices

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

2. 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

3. 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

4. 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

5. 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

6. 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

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

8. 1) Determine Threats and Risks • Definition of Risk • Probability andeffects 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

9. 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

10. 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, JavaScript • Which add-ons and components are secure?

11. 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

12. 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 / JSP / JavaScript / HTML Forms • Insecure components

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

14. 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!

15. 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 JavaScript, 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!

16. Cross-Site Scripting, cont. • Block forms submitted from untrusted sites • Block insecure HTTP referrers (HtmlPostAuthenticator) • Can be spoofed, in this case its usable • Block malicious URLs: EnableSecuredGets=true • Scrub XSS attacks from request data (FilterDataInput) • Blocks JavaScript in metadata, content, URL parameters • Especially important for anonymous contributors • Comments forms, resume submissions • Significantly restricts your “power users”

17. 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 JspEnabledGroups • 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 • IdocScript limited to page display for security reasons

18. 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), IdcCommandUX • 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 SocketHostAddressSecurityFilter

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

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

21. 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 / WebDAV 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 • NeedToKnow component • User can view some metadata, but not content

22. 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 (BrowserUrlPath) • Use SSL only for contributors / administrators

23. 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 SiteMinder • 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

24. 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 (ProxyCredentials) • 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)

25. 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 JdbcPassword • 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 FileStoreProviders (8.x)

26. 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

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

28. 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 • AllowUpdateComponentConfig, AllowComponentUpload

29. Secure Component Tips • Validate HTML form data in Java • JavaScript is handy, but not trustable • Encode IdocScript variables on pages • IdocScript 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

30. Secure Component Tips, cont. • Use the checkSecurity action in custom services • Service security flags require dSecurityGroup to be present • Cannot trust values sent by the user • First determine dSecurityGroup with SQL query • Then call checkSecurity action in service • Expect people to call custom IdocScript maliciously • Restrict functionality to read-only actions • Workflow IdocScript allows write actions in special context • Condition variable allowWorkflowIdocScript

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

32. Security Customization Examples, cont. • Custom validation of metadata and content • Content Profile rules, or Java filters (validateStandard) • Java User Providers for authentication • For legacy or atypical authentication protocols • Custom web authentication • Custom authentication filters (SiteMinder, 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

33. 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

34. 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

35. 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

36. Reaction – SCS specific • Block hacked user accounts • Supported by some SSO vendors • Block the administrator (SysadminBlocker) • 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

37. 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 • ProxyCredentials, SSL, simplified security model • Lastly, select those with significant cost/drawbacks • Scrub JavaScript content, SSL Providers, custom components

38. 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/

39. 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)