Google Site Search


Tuesday, December 30, 2008

Dr.Ron Rivest on Computer Security and Cryptography

Dr. Dobbs Journal has posted a transcript of an interview with Dr.Ron Rivest from 1997. He talks about Computer Security and Cryptography. Even though the interview is dated - the concepts, concerns etc. remain the same.

You can find the interview here.

Some important comments from Dr.Rivest.

In general, security consists of implementing the policies of someone who designed the system, policies regarding who should have access to, and who should control, various kinds of information.

.. probably safer using their credit card for Internet transactions than they are using it in a local restaurant. It's much easier for the clerk with a credit card slip to make off with your number than it is for someone to mount a sophisticated attack against an encrypted Internet line.

With electronic voting, you can tell that your vote has been counted.

MD5 is considered harmful

Message Digest Algorithm 5 (aka MD5) was invented by Ronald Rivest in 1991 as a replacement to the insecure MD4 algorithm. But current research has shown that MD5 is insecure, due to "collisions".


MD5 considered harmful today : Creating a rogue CA certificate
dated December 30, 2008

Authors: Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger

We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol.

Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 "collision". Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats.

An active discussion on this issue is happening at

Additionally, US-CERT has issued an advisory.

Read More.

Tuesday, December 16, 2008

Java CodeSource Based Security Model

We have shipped JBoss Application Server v5.0 based on VFS (Virtual File System) semantics in the microcontainer. To get the Application Server to run under a Java Security Manager while trying to retain the default policy implementation in the JDK, I went through a lot of troubling times as evident from this design forum thread. There was a lot of finger pointing, crying and swearing in public involved. Equally there were enough emails flying across in internal mailing list(s) with the designers of the JBoss microcontainer.

Well some of the issues are being described by my friend, Dennis Pilipchuck (Enterprise Security Architect at BEA/Oracle) in his article titled:
"Pitfalls of the Java Permissions Model"


Pitfalls of the Java Permissions Model by Denis Pilipchuk -- Is Java a good choice for creating applications with configurable security? Denis Pilipchuk argues that Java's permissions-based security model is a relic of its browser days and lacks the configurability, expressiveness, and efficiency that enterprise Java developers need. In this article, he looks at the problems of the permissions model and considers some alternatives.


The CodeSource URL based Java Security Model is outdated. It has never been updated since the browser-applet security days. Li Gong architected the model, then moved to Microsoft and then eventually to Mozilla Foundation (his journey has taken a decade - but the Java permissions model has neither seen any updates nor seen any desire for alternatives). So this article from Dennis seems like a coincidence in blessing. So we are not alone.

We were able to ship JBoss Application Server v5.0.0.GA to run under a security manager with the following security manager policy as a template.
Java Security Manager Policy

What were our options?
a) Write a new policy provider - this would mean a new configuration format for the permissions and would actually shoo away any rare souls who want to run the application server under a security manager.
b) Try to somehow get the default jdk policy provider to recognize or tolerate vfs urls. We ended up with this option of having dummy URL protocol handlers in the JBoss AS bootstrap and at the time of policy enforcement, we would get the real vfs codesource urls read in as the vfs protocol handlers were in place.
c) Update the VFSClassLoaderPolicy implementation to return real urls of the code jars rather than the vfs urls. We do this now by default. It avoids the issues we had with the default policyfile implementation not understanding vfs urls. But we have kind of disabled the superior vfs urls for consideration by the security manager.

Complaints with the Java Permissions based Security Model:
1) CodeSource takes an URL instance and not URI.
2) No negative permissions that can be declaratively defined (Dennis talks about this too). JACC 1.1 has a work around in the actions of WebResourcePermission for "excluded" security constraints with a "!" prefix.
3) Stack frame checking across the call path is performance intensive. Privileged blocks in the source code mitigate the walking penalties but are so poorly understood (or avoided) by developers that an introduction can accidently be the source of security holes.

We really need updates to the Java Policy class/interface with alternative mechanisms and a need to foster usage of policy.implies (after the alternatives have been identified) in the enterprise source code before embarking on sensitive operations such as using reflection, getting the classloader etc.

I wonder about the following:
a) How many enterprise deployments run under a Java Security Manager? If not, without explicit policy.implies checks, everything is open.
b) How well Java privileged blocks are understood and adopted by enterprise developers and Framework writers?

JBoss portal previously attempted to define their access model based on JACC. They had to define their own permission classes and got it working. The developers found it extremely cumbersome. Currently they are working on adopting an XACML based approach using JBossXACML. In JBoss AS5, we provide a pluggable access control model where in you can plug and play access control stacks based on JACC, XACML or your custom implementation.

Related References
Ted Neward's White Paper:

Additionally, improving the Java Security Model is not the responsibility of Sun alone. It has to be pushed for by the other VM vendors (IBM, BEA/JRockit etc) also. Maybe Dennis can ping his own JRockit folks?

Monday, December 15, 2008

CSIS Report:Securing Cyberspace for the 44th Presidency

The Center for Strategic and International Studies (CSIS) provides strategic insights and policy solutions to decisionmakers in government, international institutions, the private sector, and civil society. A bipartisan, nonprofit organization headquartered in Washington, DC, CSIS conducts research and analysis and develops policy initiatives that look into the future and anticipate change.,com_csis_pubs/task,view/id,5157/

Experts : James Andrew Lewis

The CSIS Commission on Cybersecurity for the 44th Presidency has released its final report, "Securing Cyberspace for the 44th Presidency." The Commission’s three major findings are:

1. Cybersecurity is now one of the major national security problems facing the United States;
2. Decisions and actions must respect American values related to privacy and civil liberties; and
3. Only a comprehensive national security strategy that embraces both the domestic and international aspects of cybersecurity will improve the situation.

Rep. Michael Mccaul, who co-chaired the work has an open letter here:
Congressman McCaul Unveils Cybersecurity Recommendations to the 44th President

Federated Identity Support with JBoss

People ask me the following questions:
* when are we getting SAML support in JBoss?
* when will we get a formal identity management solution for JBoss community and enterprise users?

For a while, I have been deferring answering this basically to first get a clear picture of the stabilization of the federated identity space. In addition, we had the great JBoss Application Server v5.0 to be sent out of the door with great security features.

Given this, what are our plans?

JBoss Identity:
Various projects under the JBoss umbrella have gotten together with stakeholders and formed this project called as "JBoss Identity". JBoss Application Server, JBoss Portal, JBoss SOA, JBoss Rules/Drools, JBoss Seam etc will all utilize the work from this common project.

Results Desired:
JBoss Identity Management (Management of Users, roles etc) for a single domain
JBoss Identity Federation (Allow support for federated identity standards)


Going forward, we want to support the following standards from a federated identity perspective:

1) SAML v2.0
2) WS-Trust
3) Liberty ID-WSF

These 3 standards are important for the JBoss SOA Platform.

JBoss Identity Federation v1.0.0 (February 28, 2009)


SAML core Structures
Web Browser SSO Profile
- HTTP/Redirect Binding - Jan 15, 2009 (with Signature support)
- HTTP/Post Binding - Feb 15, 2009 (With Signature support)

WS-Trust (Parallel work with SAML)

JBoss Identity Federation v1.1.0 (May 31, 2009)
SAML v2.0
- Encryption Support to Web Browser SSO Profile
- Identity Provider Discovery Profile

Liberty ID-WSF

Note: These dates are subject to change.

Challenges: It takes years (if not close to a decade) to actually get a fully compliant federated identity management solution. There are a lot of issues involved - testing, complex configuration, complex diverse requirements etc. So, we will follow the path of least resistance - listen to our users as to what their needs are.

* We have to make the system very simple to configure (of course we should assume reasonable defaults). No point in piling on to the configuration headache associated with security.
* We will allow the system to work with the great container security (JBoss/Tomcat). Why reinvent the wheel?

How can you help?
Please use the following thread to talk to us with use cases etc and be early adopters of out technology.

JBoss Identity will be put to test at the Oasis XSPA Interoperability event at HIMSS 2009 in April 2009 at Chicago. We will use SAML v2.0, XACML v2.0 and WS-Trust applied to use cases in the health care sector.

Vision: JBoss Identity along with Identity Federation, supplemented with JBoss XACML, will enable federated identity as well as federated authorization support for the community.

Thursday, December 11, 2008

JBoss AS 5.0 and Security

As you may already noticed, JBoss Application Server v5.0 was released a week ago. It is a Java EE 5.0 certified application server as shown from the compatibility page at JavaEE Compatibility.

JBoss AS 5 has many security enhancements that the community will benefit from.

Apart from the JBoss Microcontainer integration, the security layer has pluggable authorization stacks, auditing and simplified configuration.

To achieve the highest form of security for your applications running on the JBoss Application Server, it is recommended to run the application server under a Java Security Manager. You can configure your permissions assigned to your applications using the following security manager policy as a template.

Look for my blog posts on JBossAS5 security here.

Thursday, December 4, 2008

AS5: Fine Grained Authorization using Oasis XACML (Part 1)

Access Control is one of my favourite topics in security. There are two aspects to it - coarse grained and fine grained access control. The JavaEE specifications typically mandate container based authorization which tend to be coarse grained.

For Web Applications, there is enforcement on web resources (via URLs) using roles. The beauty of container based security is that user applications can delegate authentication, authorization and auditing to the container.

But coarse grained authorization may not solve all user applications' access control needs. You may have some fine grained use cases or context based use cases such as the following:

"Allow access to this part of the web applications for users who are 18 years and older"
"Only managers can update the payroll of their subordinates"
"Allow access to this section of the web application to users who are employed, accessing from the US, between 9am-5pm on Monday-Thursday"

These cannot be catered to by the access control mechanism in the Servlet specification, for example. You can turn off container security and try to do this yourself via servlet filters. What is the problem in doing this? Each time the requirements change, you have a code change.

How nice will it be if you could externalize the policy infrastructure from your code? JACC does do it with PolicyConfiguration etc. But it is not as extensive as Oasis XACML specification.

The great thing about Oasis XACML specification is that it is totally tailored towards access control and IT DOES NOTHING ELSE. It defines a language and structures to define your policies/rules and an architecture for a decision point (aka Policy Decision Point, PDP) and one or more Policy Enforcement Points (PEPs).

I am sure you can google XACML and learn more about it.

The good news is that JBoss Application Server v5.0 bundles JBossXACML v2.0.2.SP1. What does this mean? It means that you now have capabilities to extend your container authorization mechanism to include XACML policies shipped with your web/ejb deployments. Apart from this, if you need to do your own security work in your applications and looking for a XACML stack, then you can use the friendly JBossXACML api to create policies, do evaluations etc.

Please wait for Part 2 of this post to read more about using XACML for your web and ejb container authorization.

Wednesday, December 3, 2008

AS5 : Pluggable Access Control - EJB/Web

The key driver for security for Java EE components such as Web or EJB Components in JBoss Application Server is the concept of a 'security domain'. The security domain is an abstract concept that defines the authentiation, authorization, audit, mapping etc. modules in JBoss Application Server 5.

An user may need to make access control stacks pluggable for a particular component.

You can continue to configure your security domain name in jboss.xml (ejb) or jboss-web.xml (web) deployment descriptors. But there are multiple ways to configure your authorization modules that govern your web and/or ejb components.

1) Change the default authorization policy for all web/ejb components. You can do that by changing the "jboss-web-policy" and "jboss-ejb-policy" in deploy/security/security-policies-jboss-beans.xml

An example is here:

If you want to retain the normal authorization stack (do not care about JACC, XACML or custom authorization), then make no change and stop reading this blog entry. :)

2) You wish to change the authorization stack for a particular component. Lets say, test.war which has a security domain of "test-domain".

To configure JACC as the authorization stack, either in conf/login-config.xml or in a separate test-war-jboss-beans.xml (the file name should be xxx-jboss-beans.xml where xxx can be anything you desire), define the following.

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns="urn:jboss:bean-deployer:2.0">

<application-policy xmlns="urn:jboss:security-beans:1.0" name="test-domain">
<login-module code = ""
flag = "required">
<module-option name = "unauthenticatedIdentity">anonymous</module-option>
<module-option name="usersProperties"></module-option>
<module-option name="rolesProperties"></module-option>
<policy-module code="" flag="required"/>

<application-policy xmlns="urn:jboss:security-beans:1.0" name="test-domain2" extends="other">
<policy-module code="" flag="required"/>


What we have done here is that we have defined "test-domain" to have JACC and test-domain2 to have the same authentication modules as "other" but we have used XACML as the access control stack.

1) What happens when some security domains do not define any authorization modules?
A. In this case, the authorization modules defined in "jboss-web-policy" or "jboss-ejb-policy" in deploy/security/security-policies-jboss-beans.xml kick in.

2) Can I stack access control modes for a particular security domain?
A. Yes, you can use the JAAS way of stacking the authorization modules and also use the flag required,requisite,sufficient, optional} to influence the final decision.

<application-policy xmlns="urn:jboss:security-beans:1.0" name="some-domain">
<login-module code = ""
flag = "required">
<module-option name = "unauthenticatedIdentity">anonymous</module-option>
<module-option name="usersProperties"></module-option>
<module-option name="rolesProperties"></module-option>
<policy-module code="" flag="required"/>
<policy-module code="" flag="optional"/>

3) What about other components such as Messaging, JCA etc?
A. Patience. We will get there eventually. JACC is not defined for other components. While you can use XACML or write your own custom authorization provider, we have not yet provided the pluggable access control feature for components other than web and ejb. We will get there.

4) I would like to write my own authorization provider. What do I do?
A. What you need to write is a policy module such as the ones we have.

5) I know that authentication is not tied to any layer such as web, ejb etc; but authorization is always tied to the type of component we are guarding. Your examples do not show it.
A. We respect your smartness. You should start contributing to JBoss Security. We have the concept of delegates within the authorization modules. You can do something like this:

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns="urn:jboss:bean-deployer:2.0">

<application-policy xmlns="urn:jboss:security-beans:1.0" name="test-domain2" extends="other">
<policy-module code="xxx.yyy.MyAwesomeAuthorizationModule" flag="required">
<module-option name="delegateMap">web=xxxx.yy.mywebauthorizationdelegate,ejb=xxxx.yy.myejbauthorizationdelegate</module-option>


Remember, that your delegates need to be a subclass of AuthorizationModuleDelegate.

Examples are:

Read the post here:

Tuesday, November 25, 2008

Friday, November 14, 2008

Security mission critical for Application Developers?

Michael Vizard (Information Week blog) has a post titled "Security Becomes Mission Critical for Developers".

Some snippets from his blog:
There is no serious developer out there that wants to build an insecure application. It's just that there are any number of time constraints that they frequently work under that conspire to make the overall application less secure.

Mike, I agree fully. But the latter (the time constraint) is being used as a ruse for many security vulnerabilities that exist in your application. If the application is widely deployed such as browsers, then god save you. Your ruse will not work. What I would like to point out is that there are multitudes of open source tools out there that you can integrate into your builds which can perform security analysis as you develop your software. I agree that in many areas of software development, there is a scarcity of tools. In these cases, intuition/best practices/code review help. The key point is that security has to stop being an "after-thought" of any design.

I find FindBugs to be an excellent free static analysis tool, that can be used whenever to peek at some of the security vulnerabilities that you may have. It is better than nothing.

You know, if you develop insecure software, your competition is going to benefit. An example is what Joern Wettern writes in the Redmond Magazine column, titled "A Better Internet Explorer".
One of the main reasons for the success of Firefox is IE's reputation for being vulnerable to a wide range of exploits.

Isn't that Ouch? Now it will be hard for IE to gain back the folks that went the firefox way. Of course there are other reasons - firefox is cross platform. It is free and we trust Mozilla Foundation to not do any evil.

Mike says:
Unfortunately, we're soon approaching a time when some company will be sued for security breaches related to an application. The reasoning will be that there is no real good reason for making data that belongs to somebody else available to people who shouldn't have it because the application was not secure. In time, a court is going to see that kind of activity as a form a reckless disregard equivalent to a car manufacturer selling cars with faulty brake systems.

True. A faulty car can kill. A faulty software can kill and can also cause massive damages to finance, prestige etc.

The answer is processes at work and in education. Processes should exist to foster secure coding. Plus the educators at schools and universities, where software development is taught, need to inculcate curriculum on secure coding. Refer to Mary Ann Davidson's blog entry on "Supply Chain Problem".

Happy software development!!!

Sunday, November 2, 2008

Facebook and Corporate Users

In the latest debacle associated with the usage of Facebook, 13 employees (Crew) of Virgin Atlantic have been sacked for inappropriate discussions on facebook which has brought disrepute to the employer.

"Following a thorough investigation, it was found that all 13 staff participated in a discussion on the networking site Facebook, which brought the company into disrepute and insulted some of our passengers.

"It is impossible for these cabin crew members to uphold [our] high standards of customer service... if they hold these views."

A spokesman for the airline added that there was "a time and a place for Facebook".

Other aspects that you need to look at are the proliferation of viruses via the social networks - Facebook Koobface computer virus or Orkut scrap virus.

The biggest users of social networks are the Gen Y be it on personal, mobile or corporate set ups. A disturbing report on Information Week.

"Since Nov. 5, three separate studies -- from Accenture, Intel, and ISACA, a major IT users group -- have indicted the youngest generation of employees as one of the enterprise's newest and most serious security risks. People under the age of 28 -- sometimes called Generation Y and sometimes called Millennials, depending on how you define the category -- are engaging in online behavior that could expose their organizations to data leakage and information theft, the studies say."

"Interestingly, the Intel study suggests that many IT organizations are changing their behavior to accommodate the younger employees, rather than the other way around. Nearly 30% of the IT pros surveyed said they have changed their IT policies to meet the demands of Gen Y, allowing employees to access their work e-mail from noncompany smartphones or other devices and, in some cases, relaxing their rules surrounding the use of social networking sites."

Read >>>

Wednesday, October 22, 2008

Do you notice the padlock during online banking?

I hope you notice the padlock in the chrome of the browser (and not in the web content) when you do online interactions with your bank. This is very important when you enter any sensitive information into any html forms.

Yngve (Security Chief at Opera Browser) has this excellent blog entry about how opera users have started disproving claims that people rarely notice the padlock.

The entry is here: *Nobody checks the padlock* debunked by Opera users

Wednesday, October 15, 2008

Securing Open Source (DHS SwA Forum)

I had the privilege of making a presentation on "Securing Open Source" at the DHS SwA Forum at NIST. The forum was cosponsored by DHS, DOD and NIST.

The presentation is available here: Securing Open Source

Additionally, DHS has hosted the recording here:

Salient points proposed in the presentation:
a) Choose open source projects with at least one professional company with strong reputation, having stake in the project's success.
b) Choose platforms based on open source projects rather than picking and choosing arbitrary projects on the web.
c) Open Source projects need to work collaboratively with the entities (NIST/MITRE etc) who maintain public vulnerability databases.
d) OSS need to have an email address or an online contact form to report security vulnerabilities in a confidential manner. Remember, for JBoss projects, we have ""

Thursday, October 9, 2008

Gerry Gebel on State of Federated Identity Technologies

Gerry Gebel of Burton Group delivered a Keynote at the Oasis Security Forum in London last week. His talk was on the current state of Federated Identity Technologies.

His keynote is available here:
Current State of Federated Identity Standards and Implementations

Gerry highlights the growing divide between business needs and federated Identity evangelists as well as the critical need to simplify processes to scale business needs.

AS5: JSR-196 Integration: Web Http Basic Auth

Objective: Provide JSR-196 integration for the web layer to do Http Basic Authentication

Step 1: Configure your web.xml for basic authentication. An example:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns=""



Step 2: Configure your-web-app/WEB-INF/context.xml

className="" />

Step 3: You will need to configure the security domain for your web application in jboss-web.xml


Step 4: Outside of your web application, we will need a xxx-jboss-beans.xml to configure your JSR-196 modules. An example would be jaspi-webbasic-jboss-beans.xml

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns="urn:jboss:bean-deployer:2.0">

<application-policy xmlns="urn:jboss:security-beans:1.0"
<login-module-stack name="lm-stack">



<auth-module code="" login-module-stack-ref="lm-stack"/>


What this does is defines a JASPI configuration block with an ServerAuthModule that is capable of doing tomcat form authentication. In this case, we also define a login context delegation structure called lm-test.

Reference: Test Case :

AS5: JSR-196 Integration: Web Form Auth

Objective: Provide JSR-196 integration for the web layer to do Form Authentication

Step 1: Configure your web.xml for form authentication. An example:

<web-app version="2.5" xmlns=""



Step 2: Configure your-web-app/WEB-INF/context.xml

className="" />

Step 3: You will need to configure the security domain for your web application in jboss-web.xml


Step 4: Outside of your web application, we will need a xxx-jboss-beans.xml to configure your JSR-196 modules. Example would be jaspi-webform-jboss-beans.xml.

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns="urn:jboss:bean-deployer:2.0">

<application-policy xmlns="urn:jboss:security-beans:1.0"
<login-module-stack name="lm-stack">



<auth-module code="" login-module-stack-ref="lm-stack"/>


What this does is defines a JASPI configuration block with an ServerAuthModule that is capable of doing tomcat form authentication. In this case, we also define a login context delegation structure called lm-test.

Reference: Test Case :

Friday, September 26, 2008

New deployer mechanism in AS5

If you have not yet had a chance to look at this great blog post by BobMc on deployers in JBoss Application Server 5 (JBAS5), then the time is now. :)
Deployers in JBoss Microcontainer

The deployers are broken into categories that depend on stages - parsing, class loader and real.

Wednesday, September 17, 2008

JBoss Application Server 5 is EE5 Certified

The historic post is here:

JBoss QA King Rajesh says:
JBoss Application Server 5.0.0.CR2 has been released and is available for download.

This is the last candidate <>release of the JBoss 5.0.x series for the Java EE*™* 5 codebase
and the first JBossAS release that fully complies with the Java EE 5 conformance testing certification requirements

Detailed released notes:


If you want to know more about the security features in JBoss AS v5, then peruse:

In the time, please watch out for more information at Sacha's blog and Dimitris's blog

Phishing: reading celebrity gossip

Are you interested in searching for celebrities on the web? How about when you want to read on celebrity gossip? It does not matter whether you read this in your free time, sneakily during work hours or use the "Privacy Mode" in modern browsers behind closed doors late at night. The issue is the growing danger of cyber criminals out there to get you and your money.

I am referring to new scary information from Jeff Green, Senior Vice president of McAfee's Product Development & Avert Labs. You can read it here.

"Cybercriminals employ numerous methods, yet one of the simplest but most effective ways is to trick consumers into infecting themselves by capitalizing on Americans' interest in celebrity gossip"

Who are the celebrities to watch out for? Brad Pitt, Justin Timberlake, Beyonce, Heidi Montag, Mariah Carey, Rihanna and Fergie, Angelina Jolie, Jessica Alba, Cameron Diaz, George Clooney, David Beckha, Katie Holmes, Lindsay Lohan, Katherine Heigl and every other celebrity on the planet. :)

Security in Google Chrome

At the Oasis Security Forum in London in 2 weeks, Opera Browser Chief Security Architect, Yngve is going to be making a presentation on "Modern Browser Security". I am looking forward to Yngve's presentation. The Green Tool Bar (via EV Certs) is certainly a nice feature, except that it does not guarantee total security. Remember the authenticity of the website is guaranteed by the EV cert but there is no guarantee what the web content does. :(

Since the major players in the browser makers have put in a lot of emphasis on security, it is important to see the security features in the new browser from Google called "Google Chrome".

1) Privacy Mode
Chrome has a privacy mode; Google says you can create an “incognito” window “and nothing that occurs in that window is ever logged on your computer.” The latest version of Internet Explorer calls this InPrivate. Google’s use-case for when you might want to use the “incognito” feature is e.g. to keep a surprise gift a secret.

2)Web apps can be launched in their own browser window without address bar and toolbar.

3) To fight malware and phishing attempts, Chrome is constantly downloading lists of harmful sites. Google also promises that whatever runs in a tab is sandboxed so that it won’t affect your machine and can be safely closed. Plugins the user installed may escape this security model, Google admits.

For more info, look at this blog entry at blogoscoped.

Apart from the Privacy mode, I think the modern browsers are making an honest effort at fighting phishing and malware.

Friday, September 12, 2008

Mozilla readies "Private Browsing"

Mozilla Firefox 3.1 (which will go beta this month) will have a "Private Browsing" mode (aka P0rn Mode in the informal circles). I guess the privacy advocates will be a little more happy about this move from Mozilla (or may be not considering all the other browsers - safari, chrome, IE etc have adopted a roadmap for this).

But lets ask the following questions about the need for Private Browsing:
a) What is it useful for?
- watch prohibited stuff at your cube? (Remember your visits are logged remotely but not within the enterprise. Ok, the proxy will log your web requests).
b) Missing feature that cannot be lived without?

From the WashingtonPost article:
Much like Chrome, users will be able to open a separate window in Firefox 3.1 that will let them browse the Web in any way they see fit without worrying about the wife or kids entering the History menu and seeing why they spent the last hour in the office with the door locked.

Interesting Feature?

Well, if Mozilla had worked toward providing a safe browsing mode for children (wouldn't that be a significant effort)..... I know, I know it is not easy to filter out content, links etc plus the market is small. Ok, what about "Do no evil" strategy? (it is google's but I consider Mozilla to also do no-Evil). Johnathan Nightingale, Human Shield, Mozilla is a good friend from the W3C Web Security Context Group. I am certain that Johnathan does not aspire to do anything evil. Now lets see a safe browsing mode for small children. Come on Mozilla.

Ok, lets look at the CNET News piece:

Another aspect of the current unnamed feature will save all tabs and close the session, re-opening a new blank browser window. When the private session is finally turned off, the older session will re-open. One difference from Microsoft's InPrivate will be that there won't be any neon advertising that private mode has been activated, according to Mike Connor, the lead developer on Firefox. The fact that you are using a privacy mode will remain private.

Certainly, this is a feature we have been missing. (sigh.......)

UPDATE: I do see an useful use case of a browser's private mode - (Look at the Private Browsing section).

Securing Open Source

The dust has not yet settled on the recent discussion in the media on the security worthiness of Open Source Software. In continuation of my assertion that Open Source software can be as secure as one intends to be, I will be making a presentation titled "Securing Open Source" at the DHS Software Assurance Forum at NIST in October. The DHS National Cyber Security Division is the main sponsor of this forum.

What will my presentation talk about? Well, once it is ready I will post it here. In the meantime, I would like to talk about the secure practices we undertake in JBoss development as well as lessons learned during the ongoing Common Criteria Evaluation of JBoss EAP 4.3.

This month, I am moderating a panel as well as chairing sessions at the Oasis Security Forum in London. Stop by if you live in and around London. :)

So what really goes into securing open source? It is mainly the processes followed in the development and maintenance phases of the software. Many a times, open source software is written by enthusiasts and philanthropic developers for whom getting the latest innovation out is of primary importance. In these cases, there certainly is a lack of significance associated to security and maintenance. But these cases do not become the general trend for open source. For Open source projects/products such as Apache Httpd, tomcat, Linux (Red Hat) and JBoss, you have a company(ies) standing behind the success of the project. In these cases, security is dealt with as and when needed. Every security vulnerability is fixed as soon as possible.

Read more here.

Monday, September 8, 2008

Can history help us prepare for HiTech Crime?

A very interesting answer from Paul Wright, Head of Computer Crime at City of London Police on LinkedIn Q&A forum (the question was "How important is to safeguard customer data?". I had asked the question. Well, you may say it is a dumb question. I was more interested in the answers from the experts than be satisfied with my perception.)

Can history help with this? Who brought down Alfonso Capone? Was it, Frank J Wilson, George E Q Johnson or Elliot Ness? They all played their part but in real terms, it was none of them, it was a shooting in February 1930 that led to Capone's downfall. The details of which are sparse, fragmented, and shrouded in secrecy, but what the event did do was trigger the formation of the 'Secret Six'.

There aim was to assist law enforcement to take down organised crime and in particular Alfonso Capone; and they succeeded for in July 1931 'The Chicago Herald' reported him as saying;

"The Secret Six has licked the rackets. They've licked me. They've made it so there's no money in the game."

Since that time the upper echelon of the criminal fraternity have responded by moving into the unlawful obtaining of customer data, where the perception is that information is less well protected and the sentencing of offenders, when caught, is relatively light.

If we do not invest in the skills necessary to enable us to investigate such abuse in this ever-changing environment, will have to contend with playing 'catch-up' in understanding how new technologies are associated with a range of traditional wrong doings.To achieve this all will have to commit adequate funding and combine it with a promise of quality.

Unfortunately not all of those who use the Internet do so with good intentions. In order to facilitate the goals of this element there is a growing amount of information on the web that is showing them how to commit various unlawful acts using a computer and the information highway.

Why is customer data so easily exploited? This is due to the Internet and it being readily available, then once obtained it is used to facilitate a cocktail of offences. This causes some to ask, should we consider the use of private sector controls requiring organisations to take effective steps to tackle the risk of security breaches. Especially as the works of those who produce investigative guidelines for hi-tech and e-crime tend to focus on detection and prosecution, give reduced attention to the area of e-crime prevention and little attention to the forensic intelligence analysis of seized data.

Therefore, is there a need for multidisciplinary partnerships between academia, industry and law enforcement to work on the loss of customer data? The combined effort could produce a number of significant results, from developing research into technologies and tools, to creating a repository for technical papers. Many already encourage us to share knowledge, expertise and experience. This sharing of information could give organisations the tools to put in place better defences to tackle the abuse of computers and computer systems. It is only through better understanding of the scale and the scope of the problem that they will be able to build effective strategies to deal with it.

Regrettably the percentage of organisations reporting computer intrusions has continued to decline. The key reason given for not reporting intrusions was the fear of negative publicity. As a consequence this has resulted in a belief that the threat and impact has also been gravely underestimated.

There has to be a realisation that organisations cannot create such a secure environment in isolation. It will require them to establish internal and external partnerships that are supported by a framework of regulation and legislation.

The 'Secret Six' showed us how an alliance can defeat organised crime, however seventy years on we are faced with a similar predicament, only now it's on a huge global scale and is being facilitated by the Internet and technology. Could a modern day 'Hi-Tech Six' achieve the same results?


Paul will be keynoting at the Oasis Security Forum in London this month. See you there, Paul.

If you live in/around London and are interested in software security, then you should try to attend the forum. I will be moderating two panels at the forum.

Friday, July 25, 2008

Jeremiah Grossman: Web Application Security Professionals Survey (July 2008)

Jeremiah Grossman: Results: Web Application Security Professionals Survey (July 2008)

This is an extremely important Survey for Web App Security.

JBoss is secure

We certainly strive to reach that goal.

Think about this: when you sleep at night, most of us lock the doors of our house. Why? We want to feel secure. Same phenomenon happens when we go out of town for a couple of days - we tell our neighbors to watch our house. Many a times, burglars just break open a window and get in or take something immediately. When that happens, you fix the window and continue to hope that your house is safe. Even when you install a security system to your house and pay some company a monthly fee, your house is not totally secure. Someone can still break in, pick something quickly and vanish before the authorities show up. What I am trying to drive is that - a totally secure system is a myth. The reasons are plenty - these so called systems are developed by humans who are prone to make mistakes - prone to overlook something. But we certainly can try to reach that goal of making a system as secure as possible. The system will become secure with the help of implementers, testers, users, maintainers, researchers and those who scream - "fire, fire"!!! JBoss is no different. We get better as usage and feedback increases.

This week, there was a news article "Open-source software a security risk, study claims" which basically generalized that Open Source Software is risky from security perspective. I will not go into a debate about the merits of this study or get into an argument over whether closed source products are more secure than the open source ones? You can read some debate here.

This report has been widely cited in the media. A postive thing about this report is that they have given top marks to JBoss on security and pulled us down on not having a separate email address for privately reporting security vulnerabilities. Ok, that was an issue with our html editing abilities that we had not posted it in the right places to look.

You can view the following pages to get the security vulnerability reporting information now. I hope everyone is happy: JBoss Security

I have also put the information on my project page here: JBoss Security and Identity Management

Have you found a Security Vulnerability in any of the JBoss Products/Projects?

If yes, then you can email either at (security AT jboss DOT com) or (security AT jboss DOT org) for a private handling of your vulnerability information. You can also use the Red Hat Security page to report the vulnerability here.

At JBoss, we take security very seriously. I try hard to keep up to speed with all the latest developments in the security field. I am a member of multiple technical committees at the W3C, Oasis and the JCP. We try to provide the latest cutting edge technology to the users while maintaining high security standards. I do interact with security experts in the industry and adopt best practices from discussions. As an example, I had a breakfast discussion with Johnathan Nightingale, Human Shield, Mozilla Software Foundation. During the discussion Johnathan described how Mozilla tries to adapt test cases on report of every vulnerability such that regressions can be detected with every release. There, I had a perfect best practice to be adopted into our process at JBoss. :) Jeremiah Grossman, during his presentation at CSI 2007 had told us that he would go to sleep at night (when he was the CSO at Yahoo and a early 20s kid) knowing fully that Yahoo would be hacked in the night from across the world. But he kept trying to beat the hackers out. All that experience made Yahoo strong as well as launched a platform for his new company, White Hat Security. Security is not easy. Security is not complete. We just have to get better at it. ;)

Howard Schmidt has cautioned to be wary with the usage of Open Source Software. I respect Howard mainly because he is the president of ISSA (where I am a member and I read his message on the ISSA Journal every month). Howard is also an invited board member at ENISA. He has tons of security experience and is a well respected visionary. He has made a general statement about open source software which may not be totally applicable to every OSS product.

Lets look at how US Federal Agencies are dealing with Open Source Software with information from the public domain:
1) GSA has placed huge bets on JBoss. Read it here.
2) NSA is using RHEL5 and has provided security guidance here. RHEL is based on Fedora.
3) Bill Vass of Sun Federal says:
Vass, president and chief operating officer at Sun Microsystems Federal Inc., also cited open-source software, a Sun specialty. “More agencies are standardizing on open source, he said. Small-business partners who understand the value of open source in addition to consolidation and virtualization are especially useful in government work, he said.

The march of the Open Source into the Federal Domain continues.

What else are we doing at JBoss to make everyone feel secure?

JBoss is undergoing Common Criteria Evaluation process to give its users the confidence needed that they are using a secure product that has undergone rigorous security evaluation.

I thank everyone for using JBoss. I also thank the author of the study for giving us top marks for being secure (and we have fixed the html pages to showcase an email address to report vulnerabilities).

Looking onward!

If you are unhappy with JBoss Security and would like to devour me for dinner, then you can email me at Anil DOT Saldhana AT redhat DOT com.

Anil is the Chief Bottle Washer for Security at JBoss. He greatly appreciates the gesture from the community here.

Friday, July 18, 2008

JBoss 4.2.3 released

Rajesh from JBossQA has released JBoss 4.2.3.GA.

JBoss Application Server 4.2.3.GA has been released and is available for download at

This is the 3rd bug fixing release of the JBoss Application Server v4.2 series. The aim of this release is to provide
fixes for bugs reported by the community against previous JBossAS v4.2.x releases. There were some backwards
compatible component upgrades so switching to AS 4.2.3.GA from a previous 4.2.0/4.2.1/4.2.2 release should not
present any problems. Please check out the Detailed Release Notes section for the full details.

A secondary target for this release was to improve support for Java 6. JBossAS 4.2.3.GA can be build with both JDK5
and JDK6. The JDK5 compiled binaries have undergone more rigorous testing, they constitute our certified version and
can run under both Java 5 & 6 VMs (with a few configuration changes for JDK6, see the configuration section below). The
JDK6 compiled binaries include support for the JDBC 4 APIs, but this should be considered experimental at this point.


This is an important release for the community who have been waiting for bug fixes in the 4.2.x
series. Enjoy!!!!

Tuesday, July 15, 2008

SSNs useful for authentication?

Brett A Scudder (on LinkedIn) basically referred to the following report on why SSNs are not appropriate for authentication....
Uses of Social Security Numbers in the Private Sector:Why SSNs Are Not Appropriate for Authentication

Multiple banks over the last few years have used SSNs as the userid for online banking. Some of these banks are prominent banks. But they have all migrated (or given an option to the user to choose a personal username). In my view, phishing attacks will aggravate the dangers, if SSNs continue to be used for authentication by those who have adopted it.

Friday, July 11, 2008

Sun's Open Source Directory Server - OpenDS is 1.0.0

Message from Ludo to the opends mailing list.


The OpenDS development team is very please to announce the release of OpenDS 1.0.0, the first stable release of the OpenDS project.

OpenDS 1.0.0 delivers a fully compliant LDAPv3 server (*) that passes all of the compliance, interoperability and security tests suites. Furthermore, OpenDS 1.0.0 implements most the standard and experimental LDAP extensions defined in the IETF as RFCs or Internet-Drafts, ensuring maximum interoperability with LDAP client applications.

With a limited footprint allowing the server to be embedded in other Java applications, OpenDS has a very rich set of APIs making it easy to extend and increase usage scope.

OpenDS also supports a multi-master replication model that guarantees the high availability of the data for all operations, searches or updates. While theorically unlimited with regards to the number of masters, the OpenDS 1.0.0 server has been stressed under heavy and durable load with 4 Masters.

OpenDS 1.0.0 also includes :
- A 6 steps graphical installation tool that allows to have a server configured, up and running in less than 3 minutes.
- A graphical status panel
- A rich command line tool to perform all online administrative tasks both interactively or scripted.
- Advance security and password policies
- Advance backup and restore capabilities.
- A DSML gateway servlet.
- A complete user documentation set.

Note that the defaults settings for the OpenDS server are targeted for the initial evaluator or developer, running on a machine with a limited amount of resources. So it is important to do initial tuning of the Java VM and the OpenDS server to scale.
The first recommendation is to use the latest version of the Java VM (as of today Java 6 update 6 aka 1.6.0_06).
Some recommendations for the Java VM settings have been published on the OpenDS Documentation Wiki . More specifically, in order to have constant performance, tuning the Garbage Collector is needed. We recommend the CMS GC or ParallelGC.
Finally, OpenDS does provide better performances when the database files are cached into memory. The initial size for the DB cache is 10% of the heap size and is definitely under sized. A good rule of thumb is to allocated a DB cache size about half of the heap size if the later is below or equal to 2 GB, and for heap size greater than 2 GB to allocate a DB cache size equal to the heap size minus 1GB.

While we are really happy with the first stable release of the OpenDS LDAP directory server, our roadmap includes many other features and some ambitious ones:
- Native packages for OpenSolaris and Linux.
- Transactions for LDAP
- Assured Replication which is a replication model where a changed is assured to be received on at least 2 masters before it get acknowledge to the client application.
- Access to the log of changes over LDAP in order to provide external synchronization services.
- Basic management GUI for the most common tasks.
- Confidentiality and Encryption negotiation through SASL
- Improved performances
For more up to date information about the OpenDS roadmap, please check the OpenDS wiki page for the Roadmap :

For the complete documentation of OpenDS 1.0.0, please go to

Support for OpenDS 1.0.0 will be soon available from Sun Microsystems.

(*) with the exception of a partial support of RFC 4518 - International String Preparation

Many thanks to the whole team behind OpenDS 1.0.0 : developers, quality engineers, technical writers, release engineers, users...


Ludovic Poitou Sun Microsystems Inc.
OpenDS Community Lead Directory Services Grenoble Engineering Center - France

Congratulations to the Sun team and the OpenDS community on this milestone.

Tuesday, July 1, 2008

Key Management - Oasis EKMI and IEEE P1619

InformationWeek has an article titled "Oasis' open Enterprise Key Management Infrastructure initiative promises less-complex encryption. But will vendors get on board?", written by David Brown.
Information security pros do put stock in encryption--it was named the third-most-effective security practice in our most recent Strategic Security Survey, behind only firewalls and antivirus products. However, there have been obstacles along the path to ubiquitous encryption of data, including weak ciphers, deployment and integration issues, and, perhaps most notably, key management.

It is very critical that the issue of key management is tackled with utmost importance. PKI/Asymmetric Encryption is all fun and good but they internally do latch on to symmetric encryption during a transport layer handshake such as SSL/TLS(with the generation of session key during the handshake). Symmetric encryption is here to stay in the industry.

It is very easy to do encryption with keys, but managing keys is NOT EASY.

EKMI is trying to secure security systems mainly at layer 7. If you secure data at any of the lower layers, you still expose your applications to breaches, because breaches can occur at higher layers.

NOTE: I am a secretary of the EKMI Technical Committee. I would very much liked to see a little more detail on EKMI efforts in the Information Week article rather than a bird's eye view.

Related Efforts:
IEEE P1619 is an effort by IEEE for encrypting stored data. The IEEE efforts work close to the network later. EKMI focuses at the layer 7. has a session on PKI and EKMI by Tomas Gustavsson, Co-Founder, PrimeKey Solutions AB

JBoss 5.0.0.CR1 out the door

The day is not very far when we will see the GA release of JBoss5. We have reached the first milestone - JBoss 5.0.0.CR1.

JBoss Application Server 5.0.0.CR1 has been released and is available for download from

Detailed Release Notes:

Thursday, June 26, 2008

JBoss - Kerberos/SPNEGO etc

Darran has released the first beta version of the JBoss Negotiation project that enables applications to use SPNEGO. Things like Windows Desktop SSO against Active Directory or SSO against a Kerberos server etc should work for you.

Please find more information here:
JBoss Negotiation Wiki

NOTE: JBoss Negotiation will be the OFFICIAL kerberos related implementation for JBoss. If not, what is the point of starting the project and working on it. You agree?

UPDATE (Nov 14, 2008): Some minor tasks plus doc work remain to go before GA. You can use the CR versions.

Wednesday, June 25, 2008

Oasis Cross-Enterprise Security And Privacy Authorization (XSPA) Technical Committee

Mark and I have supported a proposed Oasis Technical Committee Charter.


1a. Name
OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC

1b. Statement of Purpose
Enterprises, including the healthcare enterprise, need a mechanism to exchange
privacy policies, consent directives and authorizations in an interoperable
manner. At this time, there is no standard that provides a cross-enterprise
security and privacy profile. The OASIS Cross-Enterprise Security and Privacy
Authorization (XSPA) TC will address this gap.

The need for an XSPA profile has been identified by the security and privacy
working group of the Healthcare Information Technology Standards Panel (HITSP).
HITSP is an ANSI-sponsored body charged with identifying standard building
blocks that can be leveraged to implement common healthcare use cases. The XSPA
profile will require the participation of subject matter experts in several
areas, including WS-Federation, SAML, WS-Trust, and possibly others noted below.
OASIS has the unique combination of member expertise necessary to complete this

The purpose of the XSPA profile is to address common needs: allow parties to
adopt a set of methods that, taken together, will enable them immediately
interoperate with other diverse participants in the same data exchanges; use
readily available open standards, so that participation is broadly possible
without significant licensing limitations, hardware or software choice
constraints or single-source vendor risks; and provide a fully specified stack
or set of specifications or options, all known to be interoperable. The
foregoing needs are especially acute when the use of a particular set of methods
is mandated, either by law or as a practical matter by its adoption by central
actors in a mandatory system.

Governmental health regulators are increasingly requiring certain parties
exchange health and health payment information (such as personal health records,
and itemize statements of health care charges and benefit payments) in
electronic form, and use sets of data standards identified as broadly suitable
and secure. Similar government-sponsored or government-encouraged
standardization projects are underway in many other countries. The XSPA profile
will provide another "building block" in the creation of large scale
interoperability of health information. These profiles will also aid in
achieving interoperability for secure data exchange among various health care
entities including providers, hospitals, pharmacies and insurance companies. It
is envisioned that the work produced by this committee will also help the
National Health Information Network (NHIN) in the US for secure data exchange.

It specifying the XSPA profile, where stable open standards exist, they should
be noted and adopted. Where functions are not available, or some connective
choices or additional material is required, it will be created. Doing so is the
purpose for this committee's creation.

The profile specified by this TC will have broad applicability to health
communities beyond the regulated portion of U.S. healthcare data transactions
that the HITSP panel is directed to address. Use cases from other instances of
cognate data exchanges, particularly in healthcare privacy contexts, may be
solicited and used to improve the TC's work. However, the first priority of
this committee will be to deliver and demonstrate sets of standards-based
methods that fulfill the identified security & privacy functions needed by
HITSP's specifications of functions and mandates.

The XSPA TC may also cover a more general enterprise server profile which will
provide the building blocks for business models and industry applications. Some
of the models investigated will include enterprise security and more generally
SOA security. Application of how these security and privacy models apply to
different industry sectors, including domains such as finance where privacy
rights must be supported, will also be investigated if time permits.

1c. Scope
The purpose of the TC is to specify sets of stable open standards and profiles,
and create other standards or profiles as needed, to fulfill the security and
privacy functions identified by the functions and data practices identified by
HITSP, or specified in its use cases, as all are mandated or specified from time
to time. These functions will at a minimum support the HITSP Access Control
Transaction Package specification TP20, including those access control
capabilities required to support the HITSP Manage Consent Directive Package
specification TP30. This includes the support of reliable and auditable methods
to identify, select and confirm the personal identity, official authorization
status, and role data for the subjects, senders, receivers and intermediaries of
electronic data; data needed to convey and/or enforce permitted operations on
resources and associated conditions and obligations; and reasonable measures to
secure and maintain the privacy and integrity of that data from end to end.

1. The TC may identify existing, stable open standards, and sets of standards,
and alternative standards, extensions and profiles, for fulfilling each of the
HITSP-identified functions and use cases. Where HITSP subject-matter-specific
profiles have already identified such standards as recommended, those approved
standards will be included in the TC's identified sets of standards. Where the
TC identifies elements or alternatives not already so identified as recommended,
the TC should, if it believes the additional alternatives are necessary or
advisable, recommend their inclusion to the appropriate HITSP expert panel.

2. The TC may create and approve specifications, and extensions or profiles of
specifications, as needed to fulfill HITSP-identified functions and use cases
not satisfied by existing stable open standards. Contributions made to the
committee for work issued by the committee itself will be subject to the OASIS
IPR Policy. Any such work must include appropriate conformance clause or test
information. Such work will be recommended for inclusion, as appropriate, in
the standing recommendations of the appropriate HITSP expert panel.

3. The TC may elect, in the above specifications, extensions or profile, to
indicate methods for the fulfillment of other publicly-available health-related
use cases (or mandates), or functions described in those use cases (or
mandates), including from other regions and other regulatory regimes; and may
elect to create and approve additional specifications, and extensions or
profiles of specifications, as needed, to fulfill those use cases or component

4. The TC may elect to elaborate or extend any of the above use cases or
functions, publish the same and create additional standards, profiles or
extensions to support those augmented use cases or functional descriptions. In
any such augmented work the TC must specify whether it is intended to fulfill an
HITSP (or other) mandate. Any such work must include appropriate conformance
clause or test information. Such work completed may be recommended for
inclusion, as appropriate, in the recommendations or reports of any relevant
health regulatory or advisory body.

5. The TC may elect to create supplemental information regarding the above
matters such as demonstrations, implementation guides, best practices, FAQs, or
other explanatory, implementation or promotional material as it may deem useful.

6. In all of its work, the TC should, to the extent feasible, prefer widely
implementable, widely interoperable, modular standards, extensions, profiles and
methods that permit use by a variety of participants with diverse hardware,
software, data architecture and messaging practices. The TC intends to ask
OASIS to contribute all or part of its final work, as relevant, HITSP or related
panels for incorporation into its recommendations and mandates.

1d. List of Deliverables
1. A list of the specific HITSP use cases and functions that the TC plans to
fulfill, by October 2008.

2. A set of specifications, sets, profiles and extensions, as described in
paragraphs #1 and #2 under 'Scope', to fulfill each of the HITSP use cases and
functions identified for fulfillment in deliverable paragraph #1, with the first
such specification or profile to be approved as a Committee Specification by
[December 2008], and the remainder if any to be approved by Committee
Specifications by [June 2009]. The TC may elect to create one or more of such
deliverables in whatever combinations it deems appropriate.

3. An interoperability demonstration of the XSPA profile, consistent with
paragraph #5 under 'Scope,' demonstrating the end-to-end enforcement of
healthcare security policy at the HIMSS (Healthcare Information and Management
Systems Society) meeting (April 2009).

4. Optionally, such other deliverables (e.g., those listed in paragraphs 1-6
under 'Scope') as the TC may elect, until the later of December 2009 or such
later date as the TC may elect to conclude.

1e. IPR Mode:
Royalty Free on Limited Terms under the OASIS IPR Policy

1f. Anticipated Audiences:
Health-related data transaction participants, especially in exchanges subject to
security or privacy regulation; regulators of healthcare, health payment and
personal privacy; vendors and integrators supplying products or services to the
foregoing; and, secondarily, participants in regulated or closely monitored
data exchanges with privacy and security requirements in other topical fields.

1g. Language:

(2) Non-normative information regarding the startup of the TC, which includes:
(2)(a) Identification of similar or applicable work that is being done in other
OASIS TCs or by other organizations, why there is a need for another effort in
this area and how this proposed TC will be different, and what level of liaison
will be pursued with these other organizations.

The proposed Cross-Enterprise Security and Privacy Authorization (XSPA) TC will
be incorporating several standards in a profile allowing the exchange of privacy
policies, consent directives and authorizations in an interoperable manner. The
need for an XSPA profile has been identified by the security and privacy working
group of the ANSI-sponsored Healthcare Information Technology Standards Panel
(HITSP). No other organization is addressing this identified gap in standards.
The profile will use standards from several OASIS TCs: SAML (SSTC), WS-Trust
(WS-SX) and XACML. Liaison will be established by concurrent work items in the
cited TCs' area of expertise.

(2)(b) The date, time, and location of the first meeting, whether it will be
held in person or by telephone, and who will sponsor this first meeting. The
first meeting of a TC shall occur no less than 30 days after the announcement of
its formation in the case of a meeting held exclusively by telephone or other
electronic means, and no less than 45 days after the announcement of its
formation in the case of a meeting held face-to-face (whether or not a telephone
bridge is also available).

The proposed XSPA TC will hold the first official meeting on August 8, 2008 by
telephone and will use a free conference call service.

(2)(c) The projected on-going meeting schedule for the year following the
formation of the TC, or until the projected date of the final deliverable,
whichever comes first, and who will be expected to sponsor these meetings.
The TC will meet biweekly or as otherwise agreed upon by the members of the
technical committee.

(2)(d) The names, electronic mail addresses, and membership affiliations of at
least Minimum Membership who support this proposal and are committed to the
Charter and projected meeting schedule.
Mark Little (Redhat)
Anil Saldhana (Redhat)
Sampo Kellomki (Symlabs)
Anil Tappetla (Cisco)
David Staggs (Veterans Health Administration)

(2)(e) The name of the Convener who must be an Eligible Person.
David Staggs.

(2)(f) The name of the Member Section with which the TC intends to affiliate, if

(2)(g) Optionally, a list of contributions of existing technical work that the
proposers anticipate will be made to this TC.

(2)(h) Optionally, a draft Frequently Asked Questions (FAQ) document regarding
the planned scope of the TC, for posting on the TC's website.
To be provided at a later date.

(2)(i) Optionally, a proposed working title and acronym for the specification(s)
to be developed by the TC.
To be provided at a later date.

I strongly feel that this TC is a great step toward health care security.

Friday, June 20, 2008

Would you go any lengths to protect Customer Data?

If no, why NOT?

With widespread reports of data breaches and frequents postal mails from enterprises to users/customers that their data/accounts/secrets may be compromised, it is high time the industry took steps to ensure that all data is encrypted and safe.

Here is a recent story of a Citibank system being hacked to go on an ATM theft spree in New York City. The comments on the post do claim that it is not possible for anyone to hack in to a system and get pins but is it correct? I am unsure.
Citibank Hack Blamed for Alleged ATM Crime Spree

The dust has not yet settled on the massive TJMaxx breach which has been the worst data breach.

Digital certificates/https, SSL, EV Certificates can ensure Identity and safe transport of information over the wire, but are we SURE that controls exists beyond the url for our data/information? Only time will tell. The PCI-DSS standard is a welcome change in this regard.

As architects and stakeholders, I fervently wish that everyone takes this issue of data security a little more seriously and make it part of the design process upfront and not as an after-thought or a reactive fix. :)

I am quite hopeful that the upcoming OASIS EKMI Standard will provide a decent specification to implement Symmetric Key Management for applications. Even though the charter seems ambitious (management at the applications level), it does provide practical all-round security. We are not talking about an infrastructure to encrypt data across multiple enterprises. If we are able to encrypt and properly manage keys within an enterprise, then majority of the job is well done.

A British Law requires the submission of the encryption keys when law enforcement officers demand. It is called the "Regulation of Investigatory Powers Act 2000" It does not help for an enterprise if the keys are dispersed all around the enterprise or embedded within applications.

Here is an alarming report about how SSNs are vulnerable.
Uses of Social Security Numbers in the Private Sector:
Why SSNs Are Not Appropriate for Authentication

Social Security numbers fall into the category of something one knows. The problem is that one’s SSN is widely known. It’s not all that difficult to obtain if you are a criminal engaged in the types of identity-related fraud that I mentioned earlier.


Thursday, June 19, 2008

Oasis Open Standards Forum in London

At the end of September and beginning of October, OASIS is holding a very important forum in London.

I am on the Program Management Committee for this forum which has an apt theme "Security Challenges for the Information Society".

-Image source from Oasis Event Page (

Gerry Gebel from Burton, an analyst I envy and a good friend (ok, or a person I know) is one of the Keynote speakers.

So if you are going to be in the region around that time, this forum is for you.

I am pretty excited about this forum because it not only covers all the advances in the Federated Identity Space, but also some of my favourite topics such as E-Gov Security, Browsers Security, Healthcare Security, Key Management and Access Control.

Gerry's Bio:
Gerry Gebel, Vice President and Service Director for Burton Group Identity and Privacy Strategies

Gerry covers identity management, federation, entitlement management, user provisioning, authentication technologies, directories, privacy issues, and PKI. Since joining Burton Group in 2000, Gerry has written numerous reports and articles on these topics. Gerry has also been instrumental in advancing the state of identity-based interoperability by leading demonstration projects for federation, entitlement management, and user-centric standards and specifications. Prior to joining Burton Group, Gerry gained experience in architecture, engineering, integration, and production support of mainframe, client sever and distributed systems in the financial services industry since 1986. Gerry was a founding member of Securities Industry Middleware Council (SIMC), a vertical industry organization representing the securities industry to the IT provider community and served as council vice president and Security Focus Group chairman.

Call for SAML Profiling

Please take a look at the following call for saml profiles:

Note: The Oasis Security Services Technical Committee (SSTC) is issuing this call.

The SSTC is issuing a "call for profiling intentions" in order to organize its work for the next several months. If you are planning to submit a SAML profile, binding, or extension to the SSTC for its consideration sometime soon(ish), please drop me a note with a proposed title, short abstract/rationale, and the timeframe in which you plan to bring the draft to the SSTC.

Similarly, if you are working on a SAML profile or extension in your own venue and want to seek the SSTC's guidance, let us know that as well.

Please let us know by Friday, July 25 of your plans so we can put together a comprehensive plan for SSTC activities through the fall.

Tuesday, June 17, 2008

Mozilla Firefox 3 will be released today (June 17th)

Ok, my good friend at Mozilla Foundation, the Human Shield (Johnathan Nightingale) has confirmed that Firefox v3.0 will be released today (JUne 17th, 2008). You can check out his blog entry at:

Go catch a party or get ready for the Guiness World Record.

Firefox 3 is a very important release with tons of Security features (that does include EV Certificates).

Q: When will Fedora 9 have Firefox 3?
(09:43:55 AM) anil: johnath: is ff3 a go today?
(09:50:54 AM) johnath: anil: it is, yes
(09:52:13 AM) anil: johnath: bring it on man
(09:52:42 AM) johnath: you signed up to be part of the world record?
(09:53:04 AM) anil: johnath: where is it?
(09:53:18 AM) ***johnath offers generic backgrounder:
(09:54:18 AM) johnath: anil^^
(09:54:56 AM) anil: johnath: seeing it man.
(09:55:04 AM) anil: johnath: when will fedora 9 have ff3
(09:55:19 AM) anil: johnath: not yet got any answers yet from fedora guys
(09:55:41 AM) johnath: soon - we generally work with the distros to make that process as easy as possible - I don't know a date, though, just that discussions are active and ongoing

Friday, May 16, 2008

Elected to the Oasis IDTrust Steering Committee

I am pleased to inform you that I have been elected by Oasis members to the Oasis IDTrust Steering committee. The following email says it all.

[xml-dev] IDtrust Member Section Announces New Steering Committee Members and the Security Forum 2008

Wed, 14 May 2008 13:22:53 -0400

OASIS Members,

The OASIS IDtrust Member Section (MS),, is pleased to announce the newly elected members of the IDtrust MS Steering
Committee. Jung Leung and John Bradley have been elected to serve two year
terms and Anil Saldhana of Red Hat has been elected to serve a one year
term. June, John and Anil will be joining Abbie Barbir of Nortel and John
Sabo of CA, Inc. on the Steering Committee. The IDtrust Steering Committee
provides guidance to help the Member Section achieve its goal of promoting
greater understanding and adoption of standards-based identity and trusted
infrastructure technologies, policies, and practices. Congratulations to the
new Steering Committee members and sincere gratitude to all the MS members
that cast their vote in this election process.

OASIS would like to thank Ann Terwilliger of Visa, Inc. and Arshad Noor for
their devotion and service to the IDtrust Member Section Steering Committee.

Also, the IDtrust Steering Committee is happy to announce sponsorship of the
'Open Standards Forum 2008: Security Challenges for the Information
Society,' The IDtrust MS has sponsored similar events and they have been extremely successful. We are
currently soliciting presentations, OASIS events are open to members and non-members, so please feel free to distribute this information
to colleagues. Hope to see you at the Ditton Manor in the fall!


Dee Schur
OASIS - Member Support

Wednesday, May 14, 2008

US-CERT Cyber Security Tip ST05-010 -- Understanding Web Site Certificates

Cyber Security Tip ST05-010
Understanding Web Site Certificates

You may have been exposed to web site, or host, certificates if you
have ever clicked on the padlock in your browser or, when visiting a
web site, have been presented with a dialog box claiming that there is
an error with the name or date on the certificate. Understanding what
these certificates are may help you protect your privacy.

What are web site certificates?

If an organization wants to have a secure web site that uses
encryption, it needs to obtain a site, or host, certificate. Some
steps you can take to help determine if a site uses encryption are to
look for a closed padlock in the status bar at the bottom of your
browser window and to look for "https:" rather than "http:" in the URL
(see Protecting Your Privacy for more information). By making sure a
web site encrypts your information and has a valid certificate, you
can help protect yourself against attackers who create malicious sites
to gather your information. You want to make sure you know where your
information is going before you submit anything (see Avoiding Social
Engineering and Phishing Attacks for more information).

If a web site has a valid certificate, it means that a certificate
authority has taken steps to verify that the web address actually
belongs to that organization. When you type a URL or follow a link to
a secure web site, your browser will check the certificate for the
following characteristics:
1. the web site address matches the address on the certificate
2. the certificate is signed by a certificate authority that the
browser recognizes as a "trusted" authority

Can you trust a certificate?

The level of trust you put in a certificate is connected to how much
you trust the organization and the certificate authority. If the web
address matches the address on the certificate, the certificate is
signed by a trusted certificate authority, and the date is valid, you
can be more confident that the site you want to visit is actually the
site that you are visiting. However, unless you personally verify that
certificate's unique fingerprint by calling the organization directly,
there is no way to be absolutely sure.

When you trust a certificate, you are essentially trusting the
certificate authority to verify the organization's identity for you.
However, it is important to realize that certificate authorities vary
in how strict they are about validating all of the information in the
requests and about making sure that their data is secure. By default,
your browser contains a list of more than 100 trusted certificate
authorities. That means that, by extension, you are trusting all of
those certificate authorities to properly verify and validate the
information. Before submitting any personal information, you may want
to look at the certificate.

How do you check a certificate?

There are two ways to verify a web site's certificate in Internet
Explorer or Mozilla. One option is to click on the padlock in the
status bar of your browser window. However, your browser may not
display the status bar by default. Also, attackers may be able to
create malicious web sites that fake a padlock icon and display a
false dialog window if you click that icon. A more secure way to find
information about the certificate is to look for the certificate
feature in the menu options. This information may be under the file
properties or the security option within the page information. You
will get a dialog box with information about the certificate,
including the following:
* who issued the certificate - You should make sure that the issuer
is a legitimate, trusted certificate authority (you may see names
like VeriSign, thawte, or Entrust). Some organizations also have
their own certificate authorities that they use to issue
certificates to internal sites such as intranets.
* who the certificate is issued to - The certificate should be
issued to the organization who owns the web site. Do not trust the
certificate if the name on the certificate does not match the name
of the organization or person you expect.
* expiration date - Most certificates are issued for one or two
years. One exception is the certificate for the certificate
authority itself, which, because of the amount of involvement
necessary to distribute the information to all of the
organizations who hold its certificates, may be ten years. Be wary
of organizations with certificates that are valid for longer than
two years or with certificates that have expired.

When visiting a web site, you may have been presented with a dialog
box that claims that there is an error with the site certificate. This
may happen if the name the certificate is registered to does not match
the site name, you have chosen not to trust the company who issued the
certificate, or the certificate has expired. You will usually be
presented with the option to examine the certificate, after which you
can accept the certificate forever, accept it only for that particular
visit, or choose not to accept it. The confusion is sometimes easy to
resolve (perhaps the certificate was issued to a particular department
within the organization rather than the name on file). If you are
unsure whether the certificate is valid or question the security of
the site, do not submit personal information. Even if the information
is encrypted, make sure to read the organization's privacy policy
first so that you know what is being done with that information (see
Protecting Your Privacy for more information).

Authors: Mindi McDowell, Matt Lytle

Produced 2005 by US-CERT, a government organization.

Note: This tip was previously published and is being re-distributed
to increase awareness.

Terms of use


This document can also be found at