Friday, November 7, 2008

Security Policy Document - New Draft

Raja and Joseph put out a new draft of the PHGrid Security Policy Document.

It's available on the wiki for your review.
Posted by Brian Alexander Lee at 1:35 PM
Labels:

3 comments:

Ron Price said...

I think the security policy document is a great start.
After studying the document I have a couple of points I would like to mention:

-What is DURSA? Where can I find more info on DURSA? The document felt a little incomplete due to lack of details on DURSA


-This document has the potential to be a fairly large burden on public health entities around the country. It seems the security document would require them to do a significant amount of administration and from what I understand most public health entities already feel like they are short on resources. Maybe the burden can be minimized by providing a set of tools to help with the administration and logging that a grid node would require.


-I think section 4.3 needs to mention Certificate Revocation Lists (CRLs). For instance how will the CRL at each site be updated? Should a node be trusted if the trust fabric (CRL) has not been updated recently? I think it is good practice to have a grid node update its trust fabric once every couple of hours and before any major interactions occur. In Dorian/gaards terms this can be easily done by running a single command from the command line or via line or two of code if one wants to update the trust fabric from a grid service. It may be the the CRL details are buried somewhere in the NIST/FIPS documentation and if it is please ignore this comment.


-It seems that auditing will require resource from the PH entity. I think it may be useful if the document differentiates between node based auditing and service based auditing. It may be possible to build the necessary auditing into the grid node that is deployed to various PH entities via log4j. Also, caGrid 1.3 will offer more auditing features and this may help with the service based auditing.

November 17, 2008 at 5:42 PM
Raja Kailar, Ph.D. (BNETAL.com) said...

1) DURSA: Yes, this can be considered an extension to the policy, to deal with data sharing agreements, similar to the DURSA between HIEs in the NHIN. As such, the policy can be considered complete only with a valid DURSA. Developing a DURSA is on our Todo list.

2) Burden on public health - some of this is to be expected if a minimum level of assurance is required. With no security policy, or with a very loose security policy, adoption will be relatively easy but it will lower the security assurance of the network - so that is the tradeoff.
That said, the burden is not significantly different from what it takes to secure access to a PHIN application or PHINMS node.

3) Support with management tools - certainly will help, but some of the burden will be administrative/ process related as well.

3) CRLs: We will state this as part of the trust policy, that certificate authorities will have the ability to revoke certificates (e.g., CRLs), and as part of the I&A policy that each node will check for certificate revocation before allowing access.

4) Although the policy is stated in terms of audit requirement per node, the underlying components may support enabling per-service audit logging. We will make this distinction explicit.

Thanks,
Raja Kailar

November 18, 2008 at 9:30 AM
Raja Kailar, Ph.D. (BNETAL.com) said...

A quick summary of the NHIN DURSA appears as part of the following
presentation (URL below):

http://www.hhs.gov/healthit/
documents/m20080226/loonsk_files/textonly/
slide6.html

November 18, 2008 at 9:38 AM

Post a Comment

Subscribe to: Post Comments (Atom)