Hello!
Thanks for all your input! I think we have a good handle on everything. My boss doesn’t want me to put “too much information”, so I’m deleting this initial message.
Thanks & take care!
Steve in NYC
“I think animal testing is a terrible idea. They get all nervous and always give the wrong answers.”
Subject: Is this enough security?
Yes, there are viruses that can infect Word docs. They’re called macro viruses, and they’re fairly common. You definitely have to scan.
But the problem is when? It’s got to be after submission via http, but before encryption. You could simply install a Domino-aware virus scanner and set it to monitor your submissions database. Most of them will mark documents by saving an item to indicate that it has been scanned. Your agent will run once when the document is first submitted, but do nothing. The scan will happen and that modifies the document, and your agent runs again, this time seeing the marker field and doing its thing. During this period, you have a theoretical vulerability, but your multi-passworded id mitigates that for the most part.
One thing you didn’t mention is auditing of the code. Given the sensitivity level you are trying to achieve, I think you need a mechanism for an independent auditor to validate that nobody injects any rogue code into the processing. Note that it it’s not just that database that needs auditing. If someone (presumably one of the holders of a “Master Admin” ID password) sneaks an agent into another database and manages to get it signed on the sly during a session when one of the other password holders isn’t quite paying enough attention to what’s going on, that rogue code could run in a loop checking your submissions database for unencrypted docs and copying them during the brief interval that they’re exposed. Auditing would also have to check for rogue EM code installed on the server.
All that said, this probably isn’t how I’d do it. I’d find a way to have the documents encrypted before they are ever uploaded to the server. And I’d push the responsibility for virus scanning down to the law firm. The justification for that is the scanning process on the server necessarily opens up holes that can be managed but never eliminated.
So, instead of accepting .doc files, I’d accept encrypted .zip files. I’d have the users receive individidual passwords via snail mail from the law firm. If snail mail isn’t possible, I would have a simple application run on an outsourced server. Users would connect, be issued a password, which would be simultaneously emailed directly to the law firm. The password never touches your servers so there’s no chance of intercept. (And the admins of the outsourced sever never have access to the zip files, so the system is secure.)
Users would be responsible for putting the documents into an encrypted ZIP file protected by that password and uploading it to your server. If possible, I’d check the ZIP to make sure its really encrypted, and delete it if not. (Admittedly, I have no idea how to do that.) Your application then does the routing of data to Ethics and the document to the law firm, and you can probably drastically simplify your operational procedures, maybe even forget about the multi-signed ID, because access to the application doesn’t breach security of the data.
-rich
Subject: RE: Is this enough security?
Howdy!
Thanks for the input! Here are a couple of other things I had forgotten, but may help:
the database design will be hidden.
“enforce consistent ACL across servers” enabled.
the only user who can refresh the design is the “Master Admin” user.
there will be logging to see who attempts to access it, adding their UserNames, IP address and date/time info.
It’s true what you mention about two “Master Admin” people getting together, but we have to have someone in charge of this thing! 
I see your point about encrypting the document right away, and letting the law firm deal with virus scanning. Is there a way for a NotesAgent to get a handle on the word document and disable all macros?
We will be using a seperate server for the law firm, ideally, but it’s still kinda premature… the application has to be in production before the law firm is selected. =8P
Thanks for the input!
Steve in NYC
Subject: RE: Is this enough security?
To disable the word macros, you’ll have to detach the document to the server’s file system. (We’ll get back to the implications of this in a second…).
Then, you open up the document using the COM API for Word. (Word must be installed on the server for this.) Then you disable the macros, and re-save. (Don’t ask for more specifics. I’m sure it can be done, but I don’t know the details of the API.) Then you re-attach it back into the NSF, and finally delete it from the server’s file system.
The problem is that you’ve just created a hole. You’ve built all this nice protection into the NSF, and then you go and put the unencrypted doc out on the file system. You’ve left it with only the protection of Windows security. Sure, it will be a short-lived hole, but it’s there. Plus, if your agent hangs or crashes at an inopportune moment, it won’t actually be a short-lived hole. The doc could be on disk for a long time.
Re: “we have to have someone in charge…” I understand that, of course. The thing is, if the sensitivity of the information exceeds the clearance of the people “in charge” of the technical solution by so much that you start thinking about erecting fences through dedicated servers, multiple passwords, etc., then it gets to the point where you have to ask whether pushing the encryption step down to the end users is the better choice. As I said previously, you can manage the risks, and you can audit, but you can’t ever eliminate the risks if the encryption is done on the server.
You can get to the point where it takes two of your Master Admins plus an auditor in conspiracy to breach security and cover their tracks; or that it takes one really sneaky Master Admin who decieves both an other Master Admin plus an auditor in order to be able to do it. Without doing the encryption before docs are uploaded to the server, you simply can’t do any better than that. Bear in mind that as the system designer and possibly as one of the Master Admins yourself, you’re going to be in the cross-hairs if there’s ever a breach. If you can live with that, though, fine by me.
Subject: RE: Is this enough security?
Howdy!
Good points. We will most likely look at a 3rd party product which can let the agent do the virus checking, but we’ll jump off that bridge when we get to it. I agree that opening the Word file to disable the macros is not a real safe idea.
We’ve settled on creating a Notes id with 3 passwords, and all 3 passwords have to login to authenticate. One password for three different departments. The Word document will be encrypted by this user id.
After meeting with everyone, I think that they are fairly confident that this will work well. 
There may be holes, but very small, and very little windows for opportunity. I still think it’s great to have you and everyone else giving ideas which can help others protect private information.
Thanks, and have a good weekend!
Steve in NYC
“Wherever you go, there you are.”
Subject: Is this enough security?
The first question I’d ask if the users’ financial info really has to be in Word docs. Things would be much simpler/cleaner if the users would simply type their information into a Domino form.
Subject: RE: Is this enough security?
Howdy!
I totally agree! However, it’s not really possible with the people running the project. =8( I may suggest it again, though, and see what they say.
Thanks!
Steve in NYC
Subject: Is this enough security?
Hi Steve
That’s a big question for Friday. I’d like to try and give you a fuller reply on this next week.
I have actually had quite a lot of experience with a very similar product that we rolled out in 2002.
In the UK the Stock Market was deregulated, followed by the associated Regulatory News Service - RNS. As a result of this the FSA put out to tender a number of licences to become what as known as a Primary Information Provider (PIP). The data that comes in is Financial Disclose Information before going to market, so it is ultra sensitive as to act on this information is Insider Trading. We had a 5 minute window to get a News Release in, process and out on to a Secondary Information Provider such as Reuters
Anyone who could access it illegally would have an advantage over the market.
We used Domino/Notes for this. Users could only upload .doc. .txt. html files which were virus scanned (we used Sophos which was called by a Notes Agent during the upload process) and converted to clean tagged HTML. The original doc was attached the Notes Document. It was then ready for processing internally.
That process aside, you need to consider Notes/Domino Security as a granular funnel starting with Server Authentication at the top, right down to field level encryption keys at the bottom.
We put our SSL on an Apache Reverse Proxy ahead of the Domino Server by the way.
You also need to consider Encryption the Notes Port and other encrypted VPN tunnels between servers.
Obviously Security in any environment goes wider that just Notes and Domino. For example all our servers had to be in 24*7 locked racks in a computer room that only had access via a swipe card and pin. All the Server OS had to be hardened and running the latest MS patches and hotfixes running in a workgroup with no ability to map drives etc. Ping was blocked on the firewalls etc
Remote Access
To start with Admins could only administer the box by standing in front of it, or via the ADMIN Client. After a while we moved to some encrypted Remote Control Software open on one port, from a select range of IP addresses.
Backups
What are you using? They also need to be encrypted. We used Veritas.
Consider enforcing the ACL, but be very careful using this as if you make a change in more than one place to the ACL you have had it. Remember enforcing the consistent ACL has two meanings. Enforce the ACL locally, and make it consistent across servers.
The Server Settings are Crucial. Review them all. Use an ACL Tool to do penetration testing against your box. Remove unnecessary Templates.
Rename the LocalDomainServers Group if you want to. Make sure all your ACL entries are specified, make sure anonymous is NO ACCESS everywhere. If you are using SSL directly onto Domino, consider not running PORT 80. Change the PORT numbers in the server doc. Set the database properties to require SSL for access.
There really is a lot you can do. Look at your session authentication, use a customised domcfg.nsf. Make sure you have logging enable to text so you have a clear audit trail. Enable Activity Tracking on the server, with User Detail enabled on the database.
Don’t allow Full Admin Access in the Server Document.
That’s a lot of ADMIN security off the top of my head.
As far as Application Security goes, there are better people than me around, but certainly you can consider roles, encryption keys and the security tab for design elements, forms/views etc. Password fields
Remember to have a backup of your ID files in a fireproof safe.
HTH
Good luck
Conrad
Subject: Is this enough security?
Is the DB Encrypted with the server ID?If not, I would probably try the following if I wanted to ‘hack’ the DB.
Try to locally access the DB. (therefore bypassing the ACL).
Then break your design. Maybe take a copy of your current design, modify it, and re-apply it somehow. Not too hard if I had local access to the DB. Modifications could include breaking the encryption mechanism, or creating another agent (or changing a submit button) to do something like send the data somewhere else (as well as what it currently does). I might need to re-sign the agents if I changed them somehow, so perhaps only changing the submit button, and then signing the form with the server ID would be enough… not out of the scope of a dodgy admin I reckon. But once the changes had been made, you probably would never notice…
I guess, you probably need to ensure the database is secure locally too.
NC
Subject: RE: Is this enough security?
Howdy!
No… the database is enrypted with the "Master Admin"s id. The server does not have access to the database. The design will be hidden, and “enable consistent ACL over all replicas” enabled. Noone has “replication or copy documents” checked, either.
It will be secured locally, as well, although that’s not my responsibility. =8)
How would you change the “Submit” button with no access to the design? Is it something possible over the web? In SSL with client certificates?
Thanks!
Steve in NYC
Subject: Is this enough security?
Your overall architecture is elegant, but not particularly secure to meet your needs. There are several very weak links in the process and a few issues that are still undefined. Primary risks include:
Administration risk (by anyone who has access to the server at any level)
Development risk (by a developer who intentionally or unintentionally manages the process)
Data Corruption risk - As for the virus checking, this can be done but really is an end-user issue, namely the law firm’s responsibility. Getting involved with manipulating the core data opens up a risk that, from your description, really is not your requirement to solve.
Audit risk - You will need to have a process to do auditing that is comprehensive, secure, and accurate.
For this application to be absolutely secure, it needs to have multiple escrow processes involved. It CAN be done, including within your timeframe, with a bit of creativity and some additional tools.
I hope this helps! Feel free to contact me for more information.
Sincerely,
–Daniel Lieber
Innovative Ideas Unlimited, Inc.
Wakefield, Massachusetts USA
+1-781-246-0370 x202
“Records Manager Express for Domino: Certified Records Management for Compliance, Retention, and Discovery”
Subject: RE: Is this enough security?
Howdy!
Thanks for the “elegant” comment!
I’ll answer your risks one-by-one:
Administration risk: the server does not have access, and the “Master Admin” user id will not be on the server or in the NAB. So, theoretically, stealing the server id and the database itself would not be enough. We are also keeping the server in a secure location and protected.
Development risk: because there a so few design elements, I guess we can go thru the new design elements before the “Master Admin” user refreshes the design. As a developer, I know I won’t have access alone, unless I get together with another person with a password for the Master Admin id.
Data Corruption risk (i.e. viruses): I agree. We can leave it to the law firm, but it would be somewhat embarassing the give them a database with a Word file that has a virus in it! =8O When running the agent that processes the document, can we disable Macros in the word document from the back-end? Hmm…
Audit Risk: since the server won’t have access, we’ll be coding all the logging information, including username, IP address, date/time, etc… Hopefully that’ll be enough. In the “$$ReturnAuthorizationFailure” pages, I can add the 10 years in prison as a deterrent, too! Or how about, “Punishable by death?”
Thanks for the input!
Steve in NYC