On Thu, Apr 12, 2001 at 12:16:14PM +0800, Thomas Duterme wrote:
> Next question: in terms of internal security, what do people
> do? ... a scenario ...
>
> Take a company outside of the US where NDA agreements and
> contract law realistically doesn't apply.
First, still get people to sign whatever passes for legally binding
agreements in that locale explaining expected behavior and describing
company responses, and make those stringent. Even if it's _almost_
unenforceable, it's at least setting a clear set of expectations, and at
best you could find (or buy) a friendly magistrate to help enforce them.
And stress that you'll do whatever's necessary to enforce them.
For example, In the US, even though non-compete clauses are, in many
cases, unenforcable (general rule is you can't prohibit an individual
from practicing their trade), they're still used. And more people than
you think assume they apply once they've signed them. Don't close any
possible avenue of defense.
> Add 100 people working there with about 10-15 technically competent
> workers with access to the critical data.
Do you trust those 10-15 people? Do you trust _anyone_?
> Base the company value on the data being stored. How do you
> secure/protect yourself from internal threats. (ie. data theft,
> logic bombs, etc)
Seed your data with known bogus data that won't be selected in the case
of normal operations. This is commonly done for databases; it allows
you to positively identify stolen data if and when it surfaces in a
jurisdiction in which you *can* go after the recipient. Change it on
a planned basis so you can identify the time/date of the theft.
> Things to keep in mind: the competent techies are all db programmers
They can't identify the bogus data. They shouldn't all have permissions
to the production system(s).
> and its impossible to audit all the code that's getting written.
THAT is impossible. If you're really serious about protecting yourself,
you WILL audit all the code. Send it off-shore for review before going
into production. Control production facilities, or move those off-shore,
too. Hire an external auditing authority. You can't accept that last
premise, or there is no way to prevent theft or
The whole equation is a teeter-totter: ease-of-access vs. security.
Add money to the equation as a modifier--the more secure, the more
expensive and restrictive. The less secure, the cheaper the security
costs and the easier it is for more people to access/modify data and
programs. The question to ask yourself is, what's more expensive?
Paying for security audits, or losing data to theft and productivity
to sabotage?
Cheers,
--
Dave Ihnat
[EMAIL PROTECTED]
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
