Now and then we get questions about security for Sakai. Typically this comes from people who want to store sensitive research data.

Sakai is at the same level of security as most Rutgers central services that are done on dedicated servers. (Systems such as RCI and eden are less secure because they allow a large number of end users to login. No matter how careful the system administrators are, this involves additional risks.) The Sakai application itself has been fairly free of security issues, and the design makes it less subject to problems than many other applications. However no application of this complexity is bug-free.

However Sakai is not specifically designed to comply with regulations such as HIPPA. It's probably as good as many systems that claim that level of security, but it hasn't had the same level of formal review. For example, at higher security levels, organizations will demand background checks of staff. While we're careful about our staff, we don't do police checks. Currently we encrypt any data that is sent over the network, but we don't encrypt data as it's stored. (It's nearly impossible to do encryption of data "at rest" in a way that actually gains anything, but some standards require it).

We think Sakai is sufficient for most academic and research data. However for real health data, we would prefer to see an additional level of security used. E.g. we have verified that PGP, Inc's Netshare will allow you to store data on Sakai in encrypted form. That provides "end to end" encryption, protecting against problems on Sakai and on the network between you and Sakai. We would be comfortable with putting most health data on Sakai when it is protected by a product like this. Note that the same caveat would apply to most servers at Rutgers.

We would point out that if you're seriously concerned about the security of Sakai, you really need to be looking at the security of your entire system. Sakai is only a small part of that. Typically the weak point of security is not the central service such as Sakai, but your desktop systems, and procedures such as password management. Thus if you are interested in storing sensitive data, we'd suggest that you set up a meeting with OIRT staff and staff from Information Protection and Security, to look at the entire problem, and not just Sakai. Depending upon your needs, Sakai might have a role to play in storing moderately sensitive research data. But we'd like to have a chance to look at the entire system before doing that.