Oracle UCM Security: Challenges and Best Practices

UCM Security: Challenges and Best Practices Brian “Bex” Huff Chief Software Architect

Purpose
Outline what you need to protect your content
How UCM fits into your security policy
Use risk-management to minimize cost
Discuss risks and known vulnerabilities
General network briefly, UCM in detail
Present countermeasures to mitigate risks
General network briefly, UCM 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 (SOAP, ReST) 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 lost customer record lost costs on average: $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 , not impregnable
Consider security like risk management
Security breaches always possible
Can lower the odds to zero, but for progressively more money
Minimize risk, but also keep costs under control
“ Security is a process, not a product” – Bruce Schneier

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

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, competitors
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, clearing log files
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, ASP.NET, JavaScript
Which add-ons and components are secure?

3) Vulnerabilities and Countermeasures
Protection, Detection, Reaction
Check vulnerabilities common to all networked 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 Oracle UCM
Java-based, so “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
Especially when they connect to remote systems

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

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
Referrer can be spoofed, but in this case it’s useful
Block malicious URLs: EnableSecuredGets=true
More flags available in the HtmlPostAuthenticator component
Scrub XSS attacks from request data
Use encodeHtml function, and all HtmlDataInput config flags
Blocks JavaScript in metadata, content, URL parameters
Vital for anonymous users, might restrict “power users”
Available in pre-10gr3 as the FilterDataInput component
Out of the box in 10gr3

Malicious Content
Virus scanner on ucm/vault/~temp directory
Checks for malicious / careless contributors
Lock down JSP/ASP contribution to just developers
Lock down JSP with JspEnabledGroups
Enable ASP at web server only for specific security folders
http:// myhost/stellent/groups/scripts /
Remove secure data from JSPs/ASPs
Consumers with access to native file can view the source
Treat malicious HCSP same as malicious HTML
IdocScript limited to page display for security reasons

Direct UCM Port Access
Authentication performed outside of UCM
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 ), RIDC , 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 named users if possible
More safe than just SocketHostAddressSecurityFilter

Direct SCS Port Access, cont.
Second: password secure access
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, including some admin tools
CIS , RIDC , IdcCommandUX
Third: encrypt all communication on port 4444
Uses SSL Certificates
For J2EE connections only (CIS/CPS/RIDC)
Use the SecurityProviders component, and the RIDC Developer’s Guide
NOTE: depending on version, 2&3 might not be compatible

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

Data Leakage
How much does Google know about you, without even trying?
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
Form-based 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 full 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 difficult and time consuming
If security protocols are tough, people make “back doors” to do their jobs

Hacked Web Server
Web server primary target for unauthorized users
Typically exposed to outside world
Firewalls help, but don’t stop everything
Add a reverse proxy for extra security layer
Run web server on same machine as UCM
Connect to web server with reverse proxy outside firewall
If proxy is hacked, UCM is still safe (for now)

Hacked File System
Compromise of UCM 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 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 your web server
Use FileStoreProviders to encrypt just a handful of items

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 , encodeHtml
Prevents introduction of new XSS attacks
Use predefined SQL queries, avoid raw SQL
Predefined queries thwart SQL injection attacks
Validate all code that is sent to a new server, or new process
Check all command-line calls for malicious attacks
Understand your remote system well enough to stop attacks

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
Be paranoid about malicious usage of custom IdocScript
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 HowToComponents
Deny general access, allow it for specific requests
Establish download quotas, or download behavior monitors
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, if not already a rule in SSO system
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 – UCM 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 – UCM specific
Block hacked user accounts
Supported by some SSO vendors
Block the administrator at least ( 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
Oracle UCM less vulnerable than most systems
Smaller target than operating system, database
Recommendation: minimize 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

Now Available…

My Company: http:// bezzotech.com
My Blog: http:// bexhuff.com
My Self: [email_address]
Questions?

http://bexhuff.com	1447
http://www.slideshare.net	82
http://www.techgig.com	20
http://www.bexhuff.com	11
http://webcache.googleusercontent.com	8
http://bexhuff.bezzotech.com	6
http://translate.googleusercontent.com	2
http://itnewscast.com	2
http://www.thiswayup.de	1

Oracle UCM Security: Challenges and Best Practices

by Brian Huff on Nov 10, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

9 Embeds 1,579

Statistics

Oracle UCM Security: Challenges and Best Practices — Presentation Transcript