content server security – challenges and best practices
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
Content Server Security –Challenges and Best Practices
Brian “Bex” Huff, Software DeveloperStellent, Inc. January 30, 2006
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
Purpose
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
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
Brief History of Internet Security, cont.
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
Cyber Crime Statistics
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
What Should We Do?
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
Making A Security Plan
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
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
1) Determine Threats and Risks, cont.
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?
2) Determine Security Policy
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
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
Vulnerabilities in Stellent
Important regardless of your organization
General network security
Cross site scripting
Malicious content
Content server port access
Protection - High Risk Vulnerabilities
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!
General Network Security
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 (XSS)
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”
Cross-Site Scripting, cont.
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
Malicious Content
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
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
Direct SCS Port Access, cont.
Less important, depending on organization and network
Data leakage
Eavesdropping
Passwords
Hacked database, file server, web server
Protection - Lower Risk Vulnerabilities
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
Data Leakage
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
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 Web Server
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)
Hacked File System
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
Database Connections
Difficult to measure
Untrusted developer making customizations
How to make secure components
Possible security customizations
Protection - Risks in Customizations
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
Malicious Components
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
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
Secure Component Tips, cont.
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
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
Security Customization Examples, cont.
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 – Network Violations
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
Detection – SCS Specific
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 – Respond to Intrusion
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
Reaction – SCS specific
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
Conclusions
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/
Useful Links
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)
Questions?