View feed: Anil's Security and Identity Management Blog
Navigation
Posts of this feed on this page
- Jeremiah Grossman: Web Application Security Professionals Survey (July 2008)
- JBoss is secure
- JBoss 4.2.3 released
- SSNs useful for authentication?
- Sun's Open Source Directory Server - OpenDS is 1.0.0
- Key Management - Oasis EKMI and IEEE P1619
- JBoss 5.0.0.CR1 out the door
- JBoss - Kerberos/SPNEGO etc
- Oasis Cross-Enterprise Security And Privacy Authorization (XSPA) Technical Committee
- Would you go any lengths to protect Customer Data?
- (to view more posts, click the next/previous link)
Recent posts from all feeds
- Mobicents JAIN-SLEE Server 1.2.0.CR2 released!<br…
- JSFUnit Beta 3 is out. Seam support and more!
- Netty reaches 75%+ test coverage. What's next?
- Tab Sweep : JBoss
- And now, something slightly different
- DZone Introduction to AOP article
- Updates on JBM 2.0 progress
- Revue de Presse
- Red Hat IT Switches to JBoss EAP 4.3!
- Please stand clear of the closing doors, this train is ready to depart - Seam 2.1.0.BETA1 released!
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 .
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 jboss.org
http://www.jboss.org/jbossas/downloads/
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.
https://sourceforge.net/project/shownotes.php?release_id=614346&group_id=22866
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.
Thanks
Rajesh
=================================================================
This is an important release for the community who have been waiting for bug fixes in the 4.2.x
series. Enjoy!!!!
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.
Sun's Open Source Directory Server - OpenDS is 1.0.0
Message from Ludo to the opends mailing list.===========================
All,
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
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
- 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...
Regards,
Ludovic Poitou Sun Microsystems Inc.
OpenDS Community Lead Directory Services
http://blogs.sun.com/Ludo/ Grenoble Engineering Center - France
=====================================
Congratulations to the Sun team and the OpenDS community on this milestone.
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.
http://events.oasis-open.org/home//forum/2008/schedule 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
https://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942&release_id=610469
Detailed Release Notes:
https://sourceforge.net/project/shownotes.php?release_id=610469&group_id=22866
==============================================================
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?
Oasis Cross-Enterprise Security And Privacy Authorization (XSPA) Technical Committee
Mark and I have supported a proposed Oasis Technical Committee Charter.http://lists.oasis-open.org/archives/tc-announce/200806/msg00007.html
===========
PROPOSED CHARTER FOR REVIEW AND COMMENT
OASIS CROSS-ENTERPRISE SECURITY AND PRIVACY AUTHORIZATION (XSPA) TECHNICAL
COMMITTEE
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
work.
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
functions.
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:
English
(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
any.
None.
(2)(g) Optionally, a list of contributions of existing technical work that the
proposers anticipate will be made to this TC.
None.
(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.
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.
OUCH!