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), http://www.oasis-idtrust.org/, 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,' http://events.oasis-open.org/home/forum/2008. The IDtrust MS has sponsored similar events and they have been extremely successful. We are
currently soliciting presentations,
http://events.oasis-open.org/home/forum/2008/call. 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!
Regards,
Dee Schur
OASIS - Member Support
=====================================
Friday, May 16, 2008
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
<http://www.us-cert.gov/legal.html>
This document can also be found at
<http://www.us-cert.gov/cas/tips/ST05-010.html>
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
<http://www.us-cert.gov/legal.html>
This document can also be found at
<http://www.us-cert.gov/cas/tips/ST05-010.html>
Monday, May 5, 2008
Primer on EJB Security
In this blog post, I will try to provide a short primer on security with EJBs.
Client Side:
For EJBs, you can pass the security context from client side in two ways:
a) Username/Password via properties into initial context
Properties p = new Properties();
p.put(Context.SECURITY_PRINCIPAL, "principalName");
p.put(Context.SECURITY_CREDENTIALS, "pass");
Context ic = new InitialContext(p);
Object ejbHome = ic.lookup("someejb");
AccountHome accountHome = (AccountHome)javax.rmi.PortableRemoteObject.narrow(ejbHome, AccountHome.class);
b) Do an explicit JAAS login before doing InitialContext
LoginContext lc = new LoginContext("someconfig");
lc.login();
Context ic = new InitialContext();
Object ejbHome = ic.lookup("someejb");
AccountHome accountHome =(AccountHome)javax.rmi.PortableRemoteObject.narrow(ejbHome, AccountHome.class);
NOTE: Do not forget your try/catch/finally blocks above.
General JNDI security is highlighted here:
http://java.sun.com/products/jndi/tutorial/ldap/security/index.html
Server Side:
On the server side, the EJBs are packaged in a jar file. This jar file can also be packaged in an EAR (Enterprise Archive). For EJB2, the security descriptors go in the ejb-jar.xml via the method permission elements. You define the roles that can access the methods of EJBs. You can also define "run-as-identity" to propagate a role to other deployments.
Do remember to create a jboss.xml to define a security domain.
Client Side:
For EJBs, you can pass the security context from client side in two ways:
a) Username/Password via properties into initial context
Properties p = new Properties();
p.put(Context.SECURITY_PRINCIPAL, "principalName");
p.put(Context.SECURITY_CREDENTIALS, "pass");
Context ic = new InitialContext(p);
Object ejbHome = ic.lookup("someejb");
AccountHome accountHome = (AccountHome)javax.rmi.PortableRemoteObject.narrow(ejbHome, AccountHome.class);
b) Do an explicit JAAS login before doing InitialContext
LoginContext lc = new LoginContext("someconfig");
lc.login();
Context ic = new InitialContext();
Object ejbHome = ic.lookup("someejb");
AccountHome accountHome =(AccountHome)javax.rmi.PortableRemoteObject.narrow(ejbHome, AccountHome.class);
NOTE: Do not forget your try/catch/finally blocks above.
General JNDI security is highlighted here:
http://java.sun.com/products/jndi/tutorial/ldap/security/index.html
Server Side:
On the server side, the EJBs are packaged in a jar file. This jar file can also be packaged in an EAR (Enterprise Archive). For EJB2, the security descriptors go in the ejb-jar.xml via the method permission elements. You define the roles that can access the methods of EJBs. You can also define "run-as-identity" to propagate a role to other deployments.
Do remember to create a jboss.xml to define a security domain.
Saturday, May 3, 2008
Incorporating Secure Coding Guidelines in Curriculum
An interesting read on Mary Ann Davidson's blog on the Supply Chain Problem. Mary is the Chief Security Officer of Oracle Corporation. She brings out some excellent observations about the lack of security education in universities as part of regular curriculum. The "Time To Market" and "Please The Market" courses have kind of engulfed the typical curriculum. Hence the traditional Computer Science courses have taken the back seat. If developers have no clue what the O-notation means, what depth-first/breadth first search or traversal means etc, then you can visualize the quality of software over time.
Do we need to incorporate secure coding practices in to the curriculum of Computer Studies? I am sure having at least one mandatory course will not be bad. Question is where will the colleges find the right faculty to teach Security..... Now that is a interesting question to be answered.... The right things would be to inculcate security into the relevant courses.
But what Mary is pushing for is a necessity of the software industry.
Do we need to incorporate secure coding practices in to the curriculum of Computer Studies? I am sure having at least one mandatory course will not be bad. Question is where will the colleges find the right faculty to teach Security..... Now that is a interesting question to be answered.... The right things would be to inculcate security into the relevant courses.
But what Mary is pushing for is a necessity of the software industry.
Subscribe to:
Posts (Atom)