Posted by Andrew DeFaria on 09/05/05 00:41

Jerry Stuckle wrote:

> Andrew DeFaria wrote:
>
>> Jerry Stuckle wrote:
>>
>>> Yes, you are entitled to your opinion. But I hope you don't work on
>>> any of my customer's systems!
>>
>> Who are you customers? ;-)
>
> Small and medium sized businesses and U.S. Government, mainly.

Name names. I cannot tell if I've worked on any of your customer's
system without such info!

>> Ah nobody was speaking of passwords at all really? We were talking
>> about replicating portions of a database so that the real database we
>> not directly manipulated by the end user, then implementing some sort
>> of syncing processes back and forth. To me that's overkill. For all
>> we know a very good password system is also in place. In fact that
>> was my assumption.
>
> But weak passwords are often how these things are hacked.

That may be, however that was not what was being discussed here.

>>> Medium security would also enforce random password rules, SSL for
>>> much of the data, no telnet/ssh/ftp/sftp access, email on different
>>> servers, etc.
>>>
>>> Now if you want high security - you're talking multiple passwords
>>> which change by the minute (user has a little credit card sized
>>> device which flashes a new password every minute) and biometric
>>> identification, everything ssl, access only from specific IP
>>> addresses, etc.
>>
>> Again we were not talking about passwords and SSL - we (or at at
>> least I) was talking about unnecessary replication of the database.
>
> No, but we ARE talking about protecting data.

So what? We are talking about protecting data even without any stated
requirement that the data needs protection. That's putting the cart
before the horse.

>>> And no, this isn't hard to implement. Oracle's replication can be
>>> set up in a few minutes by someone who knows what they're doing.
>>> The additional scripts take maybe maybe a half-hour to an hour to
>>> write each, depending on their complexity. Such a system can be
>>> easily set up in a couple of days. But, of course, you'd save some
>>> time on the web site because some of the code would be moved to the
>>> server site.
>>
>> Ah now you switched the argument back DB replication. Clever, but it
>> doesn't fool me. And I believe it was also suggested to do a subset
>> of the DB. Doing the whole DB is wasteful in terms of space and time.
>> Now doing a subset may be easy and may not - it depends on the
>> organization of the data.
>>
>> In any event, I fail to see how subsetting a DB and putting only a
>> part out there will really achieve any security if the are also all
>> kinds of automating synchronization scripts. The intruder can still
>> infiltrate your exposed data then just wait for the sync to occur.
>> This then becomes a false sense of security.
>
> It's all part of protecting data. If you can't understand that data
> that isn't there can't be hacked, then you have more than a little
> problem.

As it turns out the system involved is not facing the "outside world"
anyway. IOW security requirements are not as broad as you incorrectly
assumed.

>>> It takes much longer to actually create the web pages and the back
>>> end programming than it does to isolate the database on a different
>>> server.
>>
>> Irrelevant as the creation of the web pages and back end programming
>> need to be done anyway. All you're doing is adding more stuff to do,
>> more complexity to do the replication (thus making the data less
>> timely), etc. Now that's fine if you really get a benefit somewhere
>> and if that benefit or security is indeed required. I just don't see
>> it in this case. It was not even mention that such a worry or a
>> problem existed nor that there was any requirement for such.
>
> You indicated it was unnecessary work.

Yes and I still believe it is unnecessary especially lacking a stated
requirement.

> It adds very little complexity to the system.

I disagree. It adds complexity to the system. If, or rather when, the
synchronization breaks down and needs attending too it adds to the workload.

> But a large step in security.

I would beg to differ that it's a large step in security at all, but
nonetheless a step in security that was not asked for.

>>> And BTW - you indicated you have worked on government systems from a
>>> consumer POV. You may not think they are the greatest sites - but
>>> there is a LOT of stuff behind the pages you don't see.
>>
>> BFD. To me that is not relevant to this situation.
>
> Sure it is. For instance - the FCC has my SSN in its database.

So does Albertsons or any of a host of other business much less "secure"
than your blessed FCC. A false sense of security is what one gets when
they secure one place and fail to recognize that there are thousands of
other places that would be thieves would probably use to get such info.

> But you won't be able to hack it through the web because that data is
> protected.

If your SS # is replicated to the external database then it would be as
exposed to capture as if the database was not replicated. Besides, and
real world, your SS# is probably available from many other sources anyway.

> Remember - YOU brought up the subject of government systems. I just
> gave you a real-life example of YOUR subject.

And I fail to see how it's relevant at all. We have no clear security
requirements stated yet you put forth recommendations on based on FUD.
We have no indication of what the data is nor whether it contains
personal or confidential data nor an estimation of it's value. We didn't
even have any indication of whether or not the data was available to the
masses or confined to an already secured lab (turns out it's Intranet only).

>>> For instance - check http://www.fcc.gov. You can access their
>>> wireless license database, but not private information such as DOB's
>>> and SSN's. You can even update your own records. But you won't be
>>> able to hack the main database - it isn't on the same system.
>>
>> Is that really the situation that we have here? Or is that your
>> assumption?
>
> That is the situation.

Really? But you are not the OP. How do you know that the FCC security
requirements are the same as that which is needed for the OP's
situation? Do you work with the OP? Or are you just spreading more
misinformation?

> In case you're wondering - I do live in the D.C. area - and do a fair
> amount of government work.

Good for you. That's wonderful (and wonderfully irrelevant).

> And although I didn't work on this particular system, I know some of
> the programmers who did.

Ah so then you have insight into the security requirements for this
project? Or are you still just guessing? Because geeze you didn't even
appear to know that it was Intranet only...

> It really looks like you have no idea of what security is.

Yes I do know what security is. I was just questioning whether or not
such security was needed in this specific case. I saw nothing to
indicate that it was required and lacking that the steps proposed to get
additional security seemed like overkill to me. Why do you have sort a
hard time grasping that simple concept?

> So - please don't work on any of my customers systems.

Thanks for asking nicely however I will work for whatever people wish to
employ me provided they pay well, your polite request notwithstanding.

And nay I will implement as much security as required for the system
under task, but I do so from clear specifications that such security is
required. IOW I don't build a fortress when what was asked for is a tool
shed (this is one way to get $500 toilet seats!). Similarly, however, if
I notice that the tool shed would be carrying toxic stuff and there was
a real threat that it required stronger walls or a lock I surely will
suggest such things.

I do not, however, attempt to scare people into implementing additional
security where it is unwarranted simply to extend my contract..

> And let me know which ones you do work on - I don't want ANY of my
> personal data on them!

I'm everywhere! It's too late! ;-)
--
The trouble with doing something right the first time is that nobody
appreciates how difficult it was.

[Back to original message]