At the end of an SSL decryption back into memory, are the objects from the SSL transmission immediately disposed of?
Robert,
Don't just consider SSL in transit - Laserfiche also supports Transparent Data Encryption (TDE) for SQL/Oracle, as well as Encrypted File System (EFS) on Windows Server for the images. That way it's encrypted in motion, as well as at rest immediately after Laserfiche writes the files.
This is a very complex question, and it is unclear to me what exactly you are asking. I can give you a few things to think about, which might get you started into researching things more for yourself. If you have any doubts, get a real security expert involved because I doubt you'll get all the answers you need from here alone. Especially if this is a security critical application.
In general, SSL protects the packets while in transit, but does NOT specify anything about how the data was handled before or after transmission. That is up to the applications sending/receiving on either end.
I don't know about Laserfiche's internal operations, so I can't say whether or not it writes temporary information to disk at any point during it's operations. Maybe someone from Laserfiche could help you there.
The simple fact that the Laserfiche Server is writing data either to the volumes as images or to the SQL tables for templates/field data means that the unencrypted data IS getting written to disk somewhere. The communication between SQL and Laserfiche is another route where the data may be transmitted over the network in the clear... did you use SSL for this connection as well? Are the database and volumes located on a network that is properly isolated from the outside world? (Even if you use full disk encryption, it doesn't matter if someone gains remote access to the machine through some network connection, and I don't believe there's any way to use encrypted containers or file formats with Laserfiche images).
Any programs running on either the Client side or Server side with enough permissions to access information in RAM can potentially access the unencrypted information whether or not it is ever written to disk. I believe this was the very same kind of flaw that led to Target having all that Credit Card information stolen off their Point of Sale machines. Note that if you are using virtualized servers at all, then the host computer managing your virtual servers can potentially read any information in the RAM of the virtual servers fairly easily.
I'm sure there are others, but that's a start at least.
Scott
Thank you. You pointed to SQL as another path I did not think of. I have a consultative session with LF tomorrow to hopefully clarify some of this info. However the bottom line appears to be that if the computer running the application is not isolated from the outside world, then there is potential risk. I am curious as to how LF certifies for DOD 5015.2 with this sort of potential risk? Any thoughts on that?
I think my wording above was more serious than I intended. The consultation tomorrow should clear things up for you tomorrow.
In fact, most of what I mentioned doesn't have anything to do with Laserfiche, but rather with the security of your customer's IT infrastructure/network in general. As long as your Laserfiche and SQL servers are behind firewalls and are being maintained by knowledgeable IT staff, they should be fine. As long as you use SSL for any communications that you want to protect from eavesdropping, you should be fine.
I guess my point boils down to this: your data can only be as secure as the computers on which it is running. By far, the biggest "attack surface" for the installation is NOT Laserfiche itself, but rather any other software/hardware on the server that data is stored on.
As far as DOD 5015.2, I thought that was primarily for dealing with Records Management - ensuring records are stored, managed, and disposed of properly. Not sure what it says about security. In fact some records are meant to be public, right?
Scott
You have verified my thoughts exactly, that LF per se is covered if it is behind the firewall. As far as DOD 5015.2, it is RM, but part of RM is moving info across networks and I would think SSL would come into play there the same as the scenario we are discussing here. Thanks again.
Gareth,
Thanks. Just in time as I send the SOW out the door and very useful.