[OPEN-ILS-DEV] a question of security

Wed Dec 16 10:15:48 EST 2009

Just a few comments following up on Erik's post. For many small to medium size libraries, it may not be practical to run a multi-server installation. Some sites just won't have the IT support or other resources to go beyond a "single turn-key box." So I'd echo Erik's comments that IF the proper precautions are taken it's not a high risk imho and needs to be balanced with other goals as well.

A couple of points:

1. It's worth noting that the vast majority of non-Evegreen ILS installations out there are "single box" (database + webserver) implementations. It's so common that most of the large academic sites running, say III, are single box ILS's.  In our case, even though we have the "Oracle option" with our III system, I don't see any evidence that the company would even permit you to run it detatched from the webserver, and all of the III sites running Oracle that I've networked with are single box implementations.  With our previous Unicorn system (from a pre-merger library), we did run the Oracle database separately, but if you're on the default proprietary database associated with most ILS systems, you're likely restricted from running anything but a single box implementation.

And to add an interesting side note,  up until recently, III's policy was not to disclose what webserver they were running with their WebOPAC platform (the predominant platform in use with III customers today)!! All they would say was that it was "proprietary" [1]. Now that's a security 101 violation!  With their new Encore product, they now disclose that it runs on Apache, although I'm told that they don't disclose what OS runs on the Encore box, and you're not allowed onto that server anyways...

I mention another vendor because I think EG offers us the option to be much more in control of  the "security throttle" than any other proprietary system on the marketplace IMHO.

2. You can be certain that all of the larger consortia running Evergreen are doing so with separate web and database servers (I would guess more so for performance, redundancy, and other advantages than for any security advantages offered).  

Everyone has to make their own assessment, but when I think of the data risk of the ILS in the big picture, it doesn't rank up there that high *relative*  to much more sensitive data servers imho:

- our bib records (open to the world in our OPAC)
- our patron records (well, for the most part, they're all here in a world accessible staff directory: http://tinyurl.com/yez9j4y <http://tinyurl.com/yez9j4y>  ), but sure, there's related ILS data that is very sensitive like circ history, etc. but even that's not quite up there like banking or medical data, etc.
- vendor records - all public - details on vendor's web sites
- inovice & purchase order records - ultimately, all subject to public access anyways, via Access to Information Act for anybody who wants them
- etc.

So while all of our public servers have daily log reportings of  attempts to "check things out" via automated scripts, and so on, I don't see the ILS itself a particularly appealing target.

But having said that, keeping paranoid is the way to be on security for all kinds of reasons, so we've got hardware and software based firewalls, network firewalls and intrusion detection systems (managed by dedicated external staff), then we at the library reproduce another layer of security at the EG server with software firewall, OS security practices (patches, etc.),  logwatch monitoring, and so on. And then all of that is further buttressed by an ESI technical support contract, development community monitoring of security issues, and so on. 

George Duimovich
NRCan Library / Bibliothèque de RNCan 

[1] I haven't asked the company about the III webserver question in a few years, having found out what they're running through other means.  Ask any III sys admins what web server is running on WebOPAC and most won't be able to tell you with any certainty (unless they're running Encore, which as noted is being disclosed by the company). 

________________________________

From: open-ils-dev-bounces at list.georgialibraries.org [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Erik Lewis
Sent: December 14, 2009 19:08
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] a question of security

General comment

Security cannot impede service nor detract from your primary mission.  If security concerns create an unspportable configuration they become an impediment.  Security 101 does dictate seperation of roles and interfaces but a app server database server configuration can be just as secure/insecure as both on the same host.  

You owe your patrons data security but you also owe the the basic business of being a good library.  

On Dec 14, 2009, at 6:23 PM, "John DeRosa" <technology at aptalaska.net> wrote:

	Hello evergreen community,

	This is my first email to the community. I have been employed as the technology coordinator in the haines borough public library in haines, Alaska, for the past 5 months. I am new to the evergreen system.

	Evergreen was picked as a solution for our library earlier this year before my tenure. We have a small, isolated community of about 2000 people with a healthy percentage involved in the library. I am aware that evergreen has some very large installations.

	During the planning and negotiations stage and before my time here, security concerns were brought up. Network and security folks with more experience than me in that area stated that "network 101 security" says that your database should be in a more secure location than the webserver. There was great concern expressed that private patron information could be hacked if someone gained access to the webserver.

	Working with esi, our installation of evergreen was broken up between two servers with the database and some other services on a server behind a firewall and the webserver on the front-end server. The system is up and running.

	This solution is less then perfect. Maintenance has become a headache as stopping and restarting the servers is time consuming and not error-proof for a neophyte like me. I have also expressed security concerns with the technology that allows these servers to communicate. Having evergreen split between these two servers has added a level of complexity that makes my job more difficult.

	So, finally, here's my questions. What are you guys doing out there? Have you seen this as a problem? Have you had security concerns with the evergreen system running on one server? Has anyone done what we've done here? Have you seen security breaches with the standard evergreen installation? Any other information you could send me would be greatly appreciated.

	Thanks,

	John DeRosa

	Haines Borough Public Library

	907-766-3830 ext 3

	technology at aptalaska.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20091216/b0880e03/attachment.htm 