Thin line indeed. That's why most sysads write and implement policies and
inform user about such policies to ensure the network is safe.
SysAds maintain security in the server level not on a client  - particularly
remote client or clients not belonging to the network - as is the case of
web applications. Of course in intranets the end users of web app belongs to
the network, in which case the SysAd has more control over how certain
services will be accessed and how client pc's will be configured.

On "... Actually snooping on users regarding what sites they're using
(through remote viewing _without visual indicators that he is being
monitored_ ) might be tantamount to invasion of privacy", it is invasion of
privacy.

In the case of web applications, where the majority of users are out in the
open, you can not mess with their system's settings. You have no right to.
You must inform them of your actions and make them agree with it in writing
(knowingly or unknowingly - since most do not read the Terms of Service
seriously) But even with client side scripting languages that enhance
interactivity, the scripting language is restricted to not be able to access
client data - it was coded that way on purpose. Even if it is able to access
certain data, the scripting language will actually take longer time to
perform security measures and calculations. Given that one coded a
javascript to actually perform security on the client side, how many lines
of code do you think it will take to give that javascript that security
implementation? LOC is relative to filesize which is relative to page load.
Once loaded, that security related javascript is on the client's machine,
the client - with enough patience - can deobfuscate your javascript, know
your security implementation. What then? there's still the server security
right? So how far is your server security implementation from the javascript
implementation? It needs some level of compatibility right? So the
client/attacker already knows a portion of your security implementation ...
that helped the developer/sysad? It an extra layer that you need to watch
out for.

It is a fact that not all web developers are good javascript coders. And
what happens with poorly coded javascript? It can cause/trigger memory leaks
and information disclosure. You just gave your would be attacker a DOS
window or you're giving yourself DOS and an extra layer of something to
watch out for. Add to the fact that not all clients have the same computer
specs - not the same processing power. It is best that you handle security
where you have greater control over data and resources. Something that you
do not have over your internet application user.


On 3/22/07, hard wyrd <[EMAIL PROTECTED]> wrote:



On 3/20/07, Raymond Olavides <[EMAIL PROTECTED]> wrote:

>
> Our jobs (as web developers, or sysad) is not to secure their pc, but to
> secure the data once it reaches our servers. That's why browsers has levels
> of security that users can customize. User awareness is better than
> overpowering user's security practices or controls.


In a corporate environment, sysads will have choice but to implement
stringent security measures. One thing you have to take note is that
implementing security measures is _not synonymous_ with invasion of privacy.
Securing data as it comes and goes is just one facet of implementing
security within the organization.

It is still the obligation of the admin to employ security tools and
policies (group pols, user pols) in order to meet stringent corporate
security standards (HIPAA, Sarbanes Oxley, ISO, etc..). In other words,
sysads _must_ be the ones to secure the corporate workstation since users
have no idea what is going on and will only care about their day to day work
flow.

Security as the topic goes, is multifaceted. SysAds must secure the data,
secure the equipment, and secure user activity. Though there really is a
fine line between security and invasion of privacy. Securing user activity
means you are only going to limit what the user can and cannot do while
within the environment. Securing the equipment means securing how the
machines are used, and what devices are allowed access to. And this must be
implemented in the most transparent manner and make the user aware of the
security policies and related activities that the SysAds will undertake.
Actually snooping on users regarding what sites they're using (through
remote viewing _without visual indicators that he is being monitored_ )
might be tantamount to invasion of privacy. But producing a list of sites
where he has been, through automated tracking, is not invasion of privacy.

Key to security is implement the rules and the fence to prevent whatever
untoward event that may arise in the future and deter whatever issue
that currently exists. Of course, SySAds must know the boundaries that they
can tread on in implementing security. Again, with regards to security and
privacy, SysAds will be treading on a very thin line.



hat has no bite, barks loudest."
Registered Linux User #400165
http://baudizm.blogsome.com
http://phossil.ifastnet.com
Subscribed to:
LARTC, Open-ITLUG, PRUG, KLUG, sybase.public.ase.linux

_________________________________________________
Kagay-Anon Linux Users' Group (KLUG) Mailing List
[email protected] (http://cdo.linux.org.ph)
Searchable Archives: http://archives.free.net.ph




--

http://audienceone.blogspot.com
_________________________________________________
Kagay-Anon Linux Users' Group (KLUG) Mailing List
[email protected] (http://cdo.linux.org.ph)
Searchable Archives: http://archives.free.net.ph

Reply via email to