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

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, JavaScript
• 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 / JSP / JavaScript / 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 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!
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”
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
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
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
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 / 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
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
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
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)
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)
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
• AllowUpdateComponentConfig, AllowComponentUpload
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
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
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)
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
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 (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
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
•
•
Second, select those with little cost/drawbacks
•
•
SSO, web proxies, Content Tracker
ProxyCredentials, SSL, simplified security model
Lastly, select those with significant cost/drawbacks
•
Scrub JavaScript 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 <[email protected]>
• 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)