Hi Helen,

Am 07.01.2014 um 04:33 schrieb Helen Borrie <helebor@...>:

> At 10:25 a.m. 7/01/2014, Marc Hakman wrote:
>
>
>> Hi Helen,
>>
>> if I understand you well, I have a steel armor archive cabinet on wheels without a rear wall.
>
> In the worst-case scenario, yes. But there is far from enough information to deduce exactly how your vendor has set up your installation.
>

I can not publish it here.

>> Approved by all security agencies (NSA etc) and several other criminal organizations. And, I even didn’t know. ;)
>
> I expressed surprise that the software would have received government certification if it was set up wrongly from a security perspective. Only your supplier/developer can go through this with you and explain what (if anything) you need to do.
>

Every client has a pw and different rights: the cabinet. In my view, the database file with the unchanged default admin account name and pw is the missing rear wall. Is that correct?

>> I have contacted them, the supplier / developer (not vendor) and the certification body. Waiting for their reactions.
>
> Correct course of action, but especially the developer. Ask him/her to explain how the SYSDBA account figures in client access to your database and how SQL permissions are set up for your database.
>

I’ll do.

Btw: I had for 1 y. another certified p.i.s. The patients reports are stored in an open directory, outside the system, between other directories on the server.

>> It is possible to sent you a personal mail? Uncleared ist my problem with the chip card.
>
> No; except in the context of a support arrangement with IBPhoenix.
>

OK. So youraccount@... is blocked.
Still untouched: patient chip card.
Where can I find info about the possible risks of patients chip cards. In your books? How can I read out, wether they do something / nothing with my database file. I don’t like to trust not trust my developer, because he has interest in selling and therefore in certification; not in the security of my database files (= patients and financial company files). Could an arrangement with IBPhoenix be helpfull?

>> PS: read also the mail of <mailto:rudyhuang10@...>rudyhuang10@...
>
> I did. His problem is different to yours. Someone has taken a copy of his database and has stolen his database design. Whether his data security is good or bad is not relevant to this particular problem. Maybe he is less concerned about the security of the data than the theft of his intellectual property. It is likely that his database contains executable code in the form of triggers and stored procedures, which may have cost him hundreds of hours in development time. Sadly, if people store their databases and backup files in insecure places, they make them vulnerable to theft.
>
> -- Don't put databases or backup files in shared locations

sic.

> -- Don't allow unauthorised access to locations storing databases and backup files
>
> Those two are easy. These are tougher:
>
> -- Don't employ people who are likely to steal files off your servers
> -- Don't deploy your software to customers who might employ software thieves.
>
> Actually, I was puzzling about how he knows this bad guy stole his database....he would have needed to "steal back" a copy to establish that, no?
>
> Helen Borrie, Support Consultant, IBPhoenix (Pacific)
> Author of "The Firebird Book" and "The Firebird Book Second Edition"
> http://www.firebird-books.net
> __________________________________________________________________
>
>
>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Yahoo Groups Links
>
>
>