|
|
Posted by Jerry Stuckle on 09/05/05 05:32
Andrew DeFaria wrote:
>
>> 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!
>
I'm sorry - I don't give out my customer's names - especially in a
public forum!
>>
>>
>> But weak passwords are often how these things are hacked.
>
>
> That may be, however that was not what was being discussed here.
>
We were talking SECURITY - and passwords are part of it.
>>
>> 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 a LOT of companies don't realize their data needs protection -
because they don't understand the risks and consequences. As a
consultant, part of my job is to identify possible risks and inform my
customers of them.
>
>
> 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.
>
If the database is being directly accessed by the web site, it is facing
the outside world. Anyone hacking the web site can really screw up the
database.
And I did not "assume" anything. I pointed out a potential risk and how
to prevent it. It is up to the consultant and the company to determine
if the risk is valid and my solution is necessary.
But you incorrectly assumed the security requirements are not at all
necessary.
>
> Yes and I still believe it is unnecessary especially lacking a stated
> requirement.
>
Not understanding the customer's situation, you really have no idea.
>> 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.
>
Have you ever done it? I have many times. I've done it on DB2, SQL
Server and Oracle.
If synchronization breaks down, that's a major problem with the
database. But it's a lot LESS of a problem than if the database gets
hacked!
>> 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.
>
Right.
>>
>> 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.
>
I'm familiar with Albertsons as a company. While I don't know about
their IT department in detail, if they are anywhere near as competent as
the rest of the company, their critical data is not live on the web.
>
>
> 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.
>
But my SSN is NOT replicated to the external database. Part of security
is to replicate ONLY THE REQUIRED DATA.
>> 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).
>
Of course you don't. You don't understand security basics.
>> 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?
>
Because I know the person who designed this part of the web site, and we
have discussed its implementation in detail.
>> 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).
>
It is relevant when you're questioning whether I understand Federal
government systems.
>
>
> 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...
>
This project was intranet only. However, > 85% of security breaches
occur from INSIDE the company.
>> 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 far I haven't seen any indication that you can do anything more than
spell security. But your spell checker probably help there, also.
>> 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..
>
I explain the risks and consequences of poor security. I do it in a way
they can understand. That's one of the reasons they pay me. Another is
because I can implement multi-tiered security solutions.
Of course, they also hire me to help with run of the mill web page work.
>> 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! ;-)
Names, please! I can sell those names to hackers and make a fortune!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|