I guess I should have made the situation a little clearer. Were I a
contractor at the time, I'd agree with your view, but I wasn't - I was part
of the management team of the company.
The problem was twofold - 1) Our programming resources were tapped out on
other projects, and 2) The company at the time seemed to shy away from
directly setting an inflexible policy that directed their employees to do
what it is that we wanted them to do.
To me, asking me to write a program that would ensure that employees could
not punch in early or punch out late was being done as a way of enforcing a
policy that never existed. Why not go to the employees and say "Here's what
we want you to do - wait until 8:30 to punch in, and punch out at 5:00?" You
can then monitor to see if they complied. If they don't, you give a warning,
or what have you.
In the same way that a content filter would catch accidental disclosures of
confidential information, the time card code would catch accidental early or
late punch ins or outs. In my opinion, this type of use is fine, but, to use
tools like these to create a policy (whether it be time card usage or
nondisclosure of confidential company information), is trying to ask
technology to take the place of human interaction and leadership of your
employees..
Just my $.02
Evan
-----Original Message-----
From: Frederick M Avolio [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 14, 1999 3:19 PM
To: Evan Brastow; 'Matt Curtin'
Cc: '[EMAIL PROTECTED]'
Subject: RE: Content filtering
At 01:10 PM 1/14/99 -0500, Evan Brastow wrote:
>>> Don't try to solve social problems with technology.<<
>.. My answer is always no. That's a personnel issue, not a
Seems to me we have come a long way from "the security mechanism enforces
the security policy of the organization, if it can. it does not enforce a
policy of its own."
Granted, there are people who want intrusion detections systems with
psychic powers, but the requirement that a device filters incoming content
for viruses, or outgoing messages for certain key words is certainly easy
to do programmatically. If you don't want to do it on grounds of principle,
and I'm the boss, we might just terminate our relationship. If it is a
matter of "it just cannot be done," or "it cannot be done while still
keeping the system usable," then our job is education.
But that is not where this discussion has gone. It seems like it keeps
coming back to whether we think it *should* be done, not *could* be done.
Fred
Avolio Consulting
16228 Frederick Road, PO Box 609, Lisbon, MD 21765
410-309-6910 (voice) 410-309-6911 (fax)
http://www.avolio.com
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
