This is not the "traditional" approach - it is the "scientific"
approach. There is no other effective approach.
The proof is in the pudding - when the approach is used, we get
verifiable security
when we don't use the
approach, we get penetrate-and-patch systems
The first three axioms of security are:
1) You must trust someone
2) Physical protection of something is required and is
administrated by someone you trust
3) If Cryptography is used, Something must be passed physically
by someone you trust.
It is not possible to build a computer system that is completely secure
in spite of the actions of humans.
The purpose of auditing is to validate the trust you place in a person.
It is possible to build systems that require two or more people to
confer on an action before the system acts on it -
Any secure computer system relies on proper administration of the system.
Any secure use of the system depends on a operating policy - like
completely deactivate the accounts of a terminated employee.
Any secure installation has an overall security policy - some of it is
enforced by the computers and some of it is enforced by people.
No Sr. Executive of any corporation large enough to have real Sr.
Executives was ever the System Administrator.
Nor would I ever trust a system administrated by an executive of any
kind - that is responsibility of trained system admins.
Also, machines are not authenticated, humans are.
Having said that, there is _a_ place for machine to machine
authentication - when you have a distributed TCB. (Trusted Computing
Base). The workstation of a user is rarely a TCB extension. The users
workstation is not authenticated, the user is. The workstation acts as
an agent of the authenticated user.
Doug
Paul McDonald wrote:
> I am interested in some of the points that you have expressed here Doug,
> while this "traditional" approach to data management and security makes
> sense, what I am concerned about is dealing with flaws in subjects, which
> when talking about this particular approach, one has to rely on the
> truthfulness of the subject. What I am proposing in the last email was that
> when you have two or more parties involved in the security process to
> authenticate a machine, you start to minimize the effects of what seems to
> be a variable we cannot control with programming.
>
>
>
> A particular case in point that exemplifies this particular point is that
> one that has happened in Canada in 2004 between two air carriers, Air Canada
> and WestJet.
>
> http://www.cbc.ca/canada/calgary/story/2006/05/29/ca-westjet-settlement-2006
> 0529.html
>
> In this example, it's very easy to see that despite all the programming and
> software controls and security policies, weaknesses still exist in things
> programmers cannot control.
>
>
>
> In this particular case it could have been as simple as the Sr. Executive of
> Air Canada, could have created a user account in the website that did not
> have an obvious connection with that employee, on the release of the
> employee from his job, the IT staff removed his particular user name and
> password to stop him from having the only known access to the system that he
> was authorized to use. They did not discover the additional user name and
> password until the data was already stolen. By this time it's too late and
> all the security policies and safe guards that was in place was circumvented
> by the only thing we as programmers and system designers hope we can trust
> mostly because it's one of the only variables we cannot control.
>
>
>
> Paul
>
>
>
>
>
>
>> From: [email protected] [mailto:[EMAIL PROTECTED] On
>>
> Behalf Of Doug Hale
>
>> Sent: February 12, 2008 5:20 PM
>> To: [email protected]
>> Subject: Re: [delphi-en] I am looking for suggestions
>>
>
>
>
> Paul,
> I don't know how to respond, you have skipped lightly through so many
> subjects here, very few of which have much to do
> an authentication protocol. It seems to me that what is needed most is
> "Security 101". Internet Security is an oxymoron not
> because the technology doesn't exists, but because it is mostly ignored
> by the "Internet Community".
>
>
>
> .
>
>
> <http://geo.yahoo.com/serv?s=97359714/grpId=1997149/grpspId=1705115362/msgId
> =17445/stime=1202854821/nc1=4507179/nc2=3848642/nc3=5202322>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> -----------------------------------------------------
> Home page: http://groups.yahoo.com/group/delphi-en/
> To unsubscribe: [EMAIL PROTECTED]
> Yahoo! Groups Links
>
>
>
>
>
>
[Non-text portions of this message have been removed]
