Wednesday, March 30, 2011

SiteMinder practical tips

For one of my client project, I volunteer to help on setting up SiteMinder Policy Server, and this post gives some practical tips gained from this experience in the past few weeks.

CA SiteMinder comes with on line documents that you can find on

https://support.ca.com/cadocs/0/CA%20SiteMinder%20r12%20SP2-ENU/Bookshelf_Files/HTML/index.htm?toc.htm%3Fps-install.html

If you need support from CA, you can bookmark

https://support.ca.com/cadocs/0/CA%20SiteMinder%20r12%20SP2-ENU/Bookshelf_Files/HTML/index.htm?toc.htm%3Fps-install.html.

Installation Tips

Environment I have is Windows 2008, Oracle11g for Policy store and Active Directory as user directory, SiteMinder r12 sp3.

1)      Tips on installation of Policy Server

You should let the installation to initialize Oracle database as policy store. This will save you time to use sql scripts to create various table with prefix "sm" and "xps". If you want to re-install Policy Server, you can drop all tables with "sm" and "xps". This will make your re-install clean.

2)      Tips on install Admin UI

Make sure the admin-prep installation file is co-located with admin UI installation file for it to find layout.properties file. You can extract admin-prep installation file and then copy  it to admin UI installation folder.

3)      For WebAgent 64 bit, make sure Microsoft Visual C++ 2005 Redistributable in installed before you install this Agent. Also make sure the Apache is installed for all users as Services.

4)      You can always un-install and re-install if something goes wrong. Make sure to use the uninstall.exe file come from CA to do un-install.

5)      Make sure to always "run as Administrator" for all installation files.

How Siteminder objects tie together to protect resources

 

CA Siteminder did a good job to explain various concepts in it 800 pages Policy Server documents. But, it lacks the actionable and practical step by step guide to tie all concepts together, I hope to fill this gap here. I assume that you have the basic concepts from CA document. The order of some of the following steps can be reversed in certain fashion, but I suggest to follow the order of the following steps to make the configuration smooth.

1: Create a Host Configure object(HCO). This HCO  specifies the policy server host name, and AAA ports.

2: Create an Agent and note the name of the Agent.

3: Create an Agent Configure object (ACO). In my case, I copy "ApacheDefaultSettings" settings. You will need to at least to enable "AllowLocalConfig"  so you can enable trace file for debugging. You will need to copy WebAgentTrace.conf file from WebAgent conf directory  to the location specified in LocalConfig.conf file.  

4: Make sure to add "DefaultAgentName" to your ACO. This is very important. The "# DefaultAgentName" comes with the default Apache setting, but Policy Server does not take it, this may be a bug in r12 sp3. You will get "Internal Server Error" if you don't add this value to your ACO.

5: Now you can install WebAgent and configure WebAgent to use the HostConfig (HCO) object and the AgentConfig (ACO) to register your web server as trusted host.

6: Once you configure WebAgent, you can use SMTest.exe tool to start configure domain, rules, user, etc.

7: Configure User directory. It is better to let the search on sub trees instead of one level if possible. This will make it easy for you to configure the policy down the road if your policy needs to look into sub tree (such as group membership). You will need some level of ldap knowledge. You can use tools such as Jexplorer or Softerra LDAP Browser. (I like Softerra LDAP browser) to view the LDAP tree structures and discover various DN you need to use for look up users.

8: You can now create a Domain and assign it to the Agent created in 2 and add the users to the domain.

9: You can now create an Authentication Schema

10: Create Realm and have it assigned to the Agent created in step 2 and assigned to Authentication Schema created in Step 9.

11: Create a policy and following the steps in screen to associate the policy to the domain, add the users with certain group membership for fine grained access control, add rules (make sure rules are enabled and use WebActions and enable Get and Post) and then add response and expression.

12: you should test the policy using SMTest.exe tool (comes with SDK) before testing with Web Server. During the policy configuration changes you may from time need to re-start Policy Server. This can be done use smconsole.bat file located at the bin directory of Policy Server (you will need to run as administrator to make this tool to work).

So, how all these tied together?

When WebAgent is configured, it will generate WebAgent.conf file in the Web Server (Apache in my case) conf directory and update httpd.conf file to load SM module to protect the resource. This WebAgent.conf file points to SMhost.conf file which points to the HCO object. The WebAgent.conf file points to ACO. ACO has the "DefaultAgentName" which points to Agent you created in Step 2.  There are two "glue" objects in SiteMinder. One is the "Agent" object which glues domain/Realm/Policy together. Another "glue" object is "Policy" which glues Users, Rules, Response, and expression together. These two "glue" objects explain why SiteMinder does not have a step by step workflow process to configure a simple working policy. You basically need to build the parts on your own and then glue them together. An enhancement to the Policy Admin UI would be having a step by step workflow which would guide user from Step 1 to Step 12 described above. As I said before, some of the above steps can be reversed or you can just cut in the middle to do some steps, follow above 12 steps will make the process more smooth and concepts much easier to grasp.

 

 

 

 

 

Wednesday, March 2, 2011

DroidDream


Security researchers today pulled more than 20 apps from Android Market after they were found to have been infected with the DroidDream malware. Analysis of the DroidDream malware suggests that it can gather sensitive data like a mobile device's IMEI (International Mobile Equipment Identity) number and user ID, break out of Android's application security sandbox and download additional code. 

It is certainly a wake up call for mobile security







Google Buys Security Firm Zynamics


Google has acquired a small German security start-up called Zynamics, which is well-known in the security industry for its reverse-engineering and analysis tools.

Zynamics announced the deal on its corporate blog on Tuesday, saying little other than that the company had been acquired by Google. The company is headed by Thomas Dullien, a respected security researcher and reverse engineer who is known by the handle Halvar Flake in security circles.

The acquisition by Google is an interesting one, as the company continues to build out its internal security team and its malware identification and classification capabilities. Google has assembled a deep team of researchers in the last few years, including Chris Evans, Neel Mehta, Michal Zalewski and Tavis Ormandy, and has been focusing on identifying sites that are serving malware or malicious ads and steering users away from them.

The software that Zynamics sells include several different analysis and reverse engineering products, most notably BinDiff and BinNavi, which enable customers to get detailed information on changes in binaries or executables without access to the source code. The company also sells a product called VxClass that is designed to identify and classify various pieces of malware.

"Based on the same ideas and algorithms that made zynamics BinDiff great, zynamics VxClass can structurally compare executables and thus ignore byte-level changes such as instruction reordering or string obfuscation. Small changes in the code or changed compiler settings will not fool zynamics VxClass," the company's site says.

VxClass may be the product that most interests Google in the Zynamics deal, given the company's interest in classifying malware and malicious sites.