Its official now.
Howard A. Schmidt is the newly appointed US Cyber Security Czar in the President Obama administration. From the White House Blog entry, Introducing the New Cybersecurity Coordinator and email from Mr.John Brennan, Assistant to the President for Homeland Security and Counterterrorism to the WhiteHouse.gov registered email addresses, a great introduction to Howard is provided.
My guess over the last few months was either Bruce Scheneir or Howard Schmidt would get elected to the role. So my educated guess has been right.
In an illustrious career that has included being an advisor to a former President, Howard was also the president of the ISSA. He was an invited expert to the European Network and Information Security Agency (ENISA). His wikipedia entry will provide more justification to his stature than this blog post. :)
I do hope Howard will increase his confidence in Open Source Software after "Open source software a security risk, study claims". He gave a generic negative gesture toward Open Source software. :( In spite of this study, adoption of OSS has only increased.
This blog is a personal book on Security/ IDM related thoughts/opinions. The blog posts are a personal opinion only and neither reflect the views of current/past employers nor any OTHER person living/dead on this planet.
Google Site Search
Wednesday, December 23, 2009
Cyber Security Supply Chain Assurance
Reading the latest Information Week article by J. Nicholas Hoover titled : Securing The Cyber Supply Chain, I am wondering whether a trusted supply chain model for cyber security can give an advantage to large enterprises that handle the entire supply chain for their products.
While the reference assurance model designed by SAIC and the Robert H Smith School of Business (University of Maryland) is commendable, I still have this lingering doubt about the undue advantage well established vertically-integrated companies (or a partnership/alliance) have.
On the flip-side though, the threat is big. Ensuring a trusted eco-system for critical systems in Government, Financial Institutions and National Security is a herculean task. So the reference model is certainly a good positive step. But will it be harsh on smaller players? Maybe I am missing something.
While the reference assurance model designed by SAIC and the Robert H Smith School of Business (University of Maryland) is commendable, I still have this lingering doubt about the undue advantage well established vertically-integrated companies (or a partnership/alliance) have.
On the flip-side though, the threat is big. Ensuring a trusted eco-system for critical systems in Government, Financial Institutions and National Security is a herculean task. So the reference model is certainly a good positive step. But will it be harsh on smaller players? Maybe I am missing something.
SAML and XACML standards in US Healthcare
I was fortunate to utilize PicketLink (http://jboss.org/picketlink) in a Technology Demonstration (interoperability exercise) at HIMSS 2009, April 2009 at Chicago. The other participants were Sun Microsystems, Jericho Systems, US Department of Veterans Affairs and the US Department of Defense. I have reported on this in the past. We used PicketLink mainly for the SAML and XACML capabilities. The associated Oasis press release is OASIS and HITSP Collaborate on Interoperability Demo of Healthcare Privacy Standards at HIMSS09.
While we are on the topic, I am extremely glad to read the latest news item from the Oasis Consortium related to the use of XACML and SAML standards in the US Healthcare infrastructure. The news is OASIS Members Approve Security and Privacy Authorization Standards for Healthcare.
As co-chair of the Oasis XSPA Technical Committee that was the driver of the two profiles (one on SAML and one on XACML) that became Oasis standards recently, I was able to contribute and support these two profiles. I am pleased that Oasis XACML and Oasis SAML standards have made headway into being mandated for use in the US Federal Agencies. Hopefully, these two standards should play a pivotal role in the widespread usage of the National Health Information Network (NHIN), whose open source based initiative is CONNECT.
While we are on the topic, I am extremely glad to read the latest news item from the Oasis Consortium related to the use of XACML and SAML standards in the US Healthcare infrastructure. The news is OASIS Members Approve Security and Privacy Authorization Standards for Healthcare.
As co-chair of the Oasis XSPA Technical Committee that was the driver of the two profiles (one on SAML and one on XACML) that became Oasis standards recently, I was able to contribute and support these two profiles. I am pleased that Oasis XACML and Oasis SAML standards have made headway into being mandated for use in the US Federal Agencies. Hopefully, these two standards should play a pivotal role in the widespread usage of the National Health Information Network (NHIN), whose open source based initiative is CONNECT.
Labels:
healthcare,
InternetSecurity,
SAML,
XACML,
xspa
Monday, December 21, 2009
PicketLink:: Identity Management and JBoss
It gives me pleasure in announcing v1.0.0 of Project PicketLink
(Formerly JBoss Identity).
Website: http://jboss.org/picketlink
What does the project do?
PicketLink addresses the various facets of Identity Management and other
areas of security at JBoss.
What does v1.0 provide?
* Federated Identity: Support for SAML v2.0, WS-Trust v1.3 and OpenID.
* IDM: An Identity Model for managing identities and associated behavior.
Which Servers are supported?
For Federated Identity support, we support servlet containers, but
provide deeper integration with JBoss Application Server and Apache Tomcat.
What Projects have integrated?
* JBoss Seam has SAML support [From community volunteer Marcel Kolsteren].
* JBoss ESB has WS-Trust STS with SAML Token Support.
* RestEASY wants the OpenID integration.
Looking forward to v1.1:
* AuthZ, a developer friendly access control API, led by Sohil. Built on
top of our XACML offering.
* Negotiation, led by Darran, with integration in EPP as well as WS-T
Kerberos support.
* oAuth Support.
I know there will be gaps and bugs which we will fix as we go forward.
(Formerly JBoss Identity).
Website: http://jboss.org/picketlink
What does the project do?
PicketLink addresses the various facets of Identity Management and other
areas of security at JBoss.
What does v1.0 provide?
* Federated Identity: Support for SAML v2.0, WS-Trust v1.3 and OpenID.
* IDM: An Identity Model for managing identities and associated behavior.
Which Servers are supported?
For Federated Identity support, we support servlet containers, but
provide deeper integration with JBoss Application Server and Apache Tomcat.
What Projects have integrated?
* JBoss Seam has SAML support [From community volunteer Marcel Kolsteren].
* JBoss ESB has WS-Trust STS with SAML Token Support.
* RestEASY wants the OpenID integration.
Looking forward to v1.1:
* AuthZ, a developer friendly access control API, led by Sohil. Built on
top of our XACML offering.
* Negotiation, led by Darran, with integration in EPP as well as WS-T
Kerberos support.
* oAuth Support.
I know there will be gaps and bugs which we will fix as we go forward.
Labels:
GeneralSecurity,
IdentityManagement,
OpenID,
picketlink,
SAML
Thursday, December 17, 2009
The Changing Terrain of the Internet
This week, I have seen two interesting bits of information on the internet that at least forces you to think a bit.
Although the overall value of the Internet as a global information highway and enabler of International eCommerce cannot be undermined, there certainly have been some alarming trends happening on the internet that would not have materialized otherwise (Refer to item 1).
Information Item 1:-
One interesting view is in the Mint, an Indian newspaper from WSJ which goes as follows: THE NEW FRONTIER OF TERROR—CYBERSPACE Mr.Raghu Raman raises some very important questions about the usage of the Internet for reasons not in line with its original intent (the intent by which Sir Tim Berners-Lee created the WWW).
Information Item 2:-
On a lighter side, we do have the Israeli Rabbis issuing an ultimatum for ban of the internet.
Ultra-Orthodox Israeli Rabbis Rage Against The Internet
Is the Internet Evil? ;)
Although the overall value of the Internet as a global information highway and enabler of International eCommerce cannot be undermined, there certainly have been some alarming trends happening on the internet that would not have materialized otherwise (Refer to item 1).
Information Item 1:-
One interesting view is in the Mint, an Indian newspaper from WSJ which goes as follows: THE NEW FRONTIER OF TERROR—CYBERSPACE Mr.Raghu Raman raises some very important questions about the usage of the Internet for reasons not in line with its original intent (the intent by which Sir Tim Berners-Lee created the WWW).
Information Item 2:-
On a lighter side, we do have the Israeli Rabbis issuing an ultimatum for ban of the internet.
Ultra-Orthodox Israeli Rabbis Rage Against The Internet
Is the Internet Evil? ;)
Thursday, December 10, 2009
TIP:: Souce code for JBoss AS Security
If you are wondering where the source code for the security subsystem in JBoss AS 5.x (and also EAP 5.x) is, then you will need to look at the following locations:
Security Integration Code:
1. security module of the JBoss AS workspace.
2. Security SPI
3. JBossSX
The location of the source can be found from:
JBoss AS workspace:
http://anonsvn.jboss.org/repos/jbossas/
Security SPI:
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-spi/tags/2.0.4.SP3/
JBossSX:
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/tags/2.0.4.SP3/
Additional Note:
There are two security projects integrated into JBAS5/EAP5.x, namely JBossXACML and JBoss Negotiation.
You can get their source from here:
JBossXACML: http://anonsvn.jboss.org/repos/jbossas/projects/security/security-xacml/tags/2.0.4/
JBoss Negotiation: http://anonsvn.jboss.org/repos/jbossas/projects/security/security-negotiation/tags/security-negotiation-2.0.3.SP1/
Security Integration Code:
1. security module of the JBoss AS workspace.
2. Security SPI
3. JBossSX
The location of the source can be found from:
JBoss AS workspace:
http://anonsvn.jboss.org/repos/jbossas/
Security SPI:
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-spi/tags/2.0.4.SP3/
JBossSX:
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/tags/2.0.4.SP3/
Additional Note:
There are two security projects integrated into JBAS5/EAP5.x, namely JBossXACML and JBoss Negotiation.
You can get their source from here:
JBossXACML: http://anonsvn.jboss.org/repos/jbossas/projects/security/security-xacml/tags/2.0.4/
JBoss Negotiation: http://anonsvn.jboss.org/repos/jbossas/projects/security/security-negotiation/tags/security-negotiation-2.0.3.SP1/
Wednesday, December 9, 2009
Subversion caches clear text passwords
If you are a subversion/svn user, then you may not be aware of this. By default, subversion caches your password to the repositories under the $HOME/.subversion/auth/svn.simple directory in one or more files with names that match some arbitrary strings.
You need to do the following:
1) Delete all the files under $HOME/.subversion/auth/svn.simple
2) In the $HOME/.subversion/config file
uncomment the
store-passwords = no
The documentation says:
Have a safe source control system.
Disadvantage of not caching:
You will have to enter the password more frequently.
Related Issues:
There are similar issues with Maven. You need to provide clear text passwords to your repositories in the settings.xml file
Additional Notes from Colleagues:
----------------------------------------------------------------------------
If you are using Fedora and have the subversion-gnome package installed,
subversion will store passwords in the GNOME keyring. The equivalent
package for storing passwords in the KDE wallet is subversion-kde.
Only if you do not have these packages will subversion store clear text
passwords, but it will warn you about it and recommend installing the
keyring support. Fedora users might want to double check whether they
have the aforementioned package installed. I'm sure distros other than
Fedora provide this feature as well.
-Alejandro
---------------------------------------------------------------------------
It does not seem to be the case with Mac OS, it seems to be linked to the keychain somehow.
That being said, if someone has root access to my machine, it shouldn't be too much of a problem to open keychain.
- Emmanuel
---------------------------------------------------------------------------
You need to do the following:
1) Delete all the files under $HOME/.subversion/auth/svn.simple
2) In the $HOME/.subversion/config file
uncomment the
store-passwords = no
The documentation says:
### Set store-passwords to 'no' to avoid storing passwords in the
### auth/ area of your config directory. It defaults to 'yes'.
### Note that this option only prevents saving of *new* passwords;
### it doesn't invalidate existing passwords. (To do that, remove
### the cache files by hand as described in the Subversion book.)
Have a safe source control system.
Disadvantage of not caching:
You will have to enter the password more frequently.
Related Issues:
There are similar issues with Maven. You need to provide clear text passwords to your repositories in the settings.xml file
Additional Notes from Colleagues:
----------------------------------------------------------------------------
If you are using Fedora and have the subversion-gnome package installed,
subversion will store passwords in the GNOME keyring. The equivalent
package for storing passwords in the KDE wallet is subversion-kde.
Only if you do not have these packages will subversion store clear text
passwords, but it will warn you about it and recommend installing the
keyring support. Fedora users might want to double check whether they
have the aforementioned package installed. I'm sure distros other than
Fedora provide this feature as well.
-Alejandro
---------------------------------------------------------------------------
It does not seem to be the case with Mac OS, it seems to be linked to the keychain somehow.
That being said, if someone has root access to my machine, it shouldn't be too much of a problem to open keychain.
- Emmanuel
---------------------------------------------------------------------------
Tuesday, December 8, 2009
TIP::JBossXACML Logging
If you are interested in seeing the trace messages of the PDP engine in JBossXACML, you will need to add the following line to the logging.properties file in use for your setup.
# Set the default logging level for the logger named org.jboss
org.jboss.security.xacml.sunxacml.level = FINEST
If you are running it in Apache Tomcat, then the file is in conf directory.
In JBoss Application Server, you should just add a trace category in the conf/jboss-log4j.xml
The trace messages will be found in the logs of your server.
# Set the default logging level for the logger named org.jboss
org.jboss.security.xacml.sunxacml.level = FINEST
If you are running it in Apache Tomcat, then the file is in conf directory.
In JBoss Application Server, you should just add a trace category in the conf/jboss-log4j.xml
The trace messages will be found in the logs of your server.
Subscribe to:
Posts (Atom)