Debate regarding RICA act
David Naude
I came out of a meeting with a customer about a week ago where I was
told that they were unable to use log files in the courts because of
RICA. Since this meeting I have started reading the legal terms
regarding this act.
According to the RICA act, there are two defined forms of
communication, direct and indirect. I am assuming that log files are
an indirect form of communication. If I am right, then the following
extract is relevant and log files should be able to be used as
evidence without the consent of the party involved. Your input would
be greatly appreciated.
Chapter 2 : Prohibition of interception of communications and
provision of real-time or archived communication related information
and exceptions
Part 1 : Prohibition of interception of communications and exceptions
6. Interception of indirect communication in connection with carrying
on of business
1) Any person may, in the course of the carrying on of any
business, intercept any indirect communication -
a) by means of which a transaction is entered into in the
course of that business;
b) which otherwise relates to that business; or
c) which otherwise takes place in the course of the carrying on
of that business, in the course of its transmission over a
telecommunication system.
Julius Francis
It boils down to the constitutional rights of the individual to privacy vs
the rights of the organisation to protect its information assets.
In an organisation where the usage policy explicitly states that the users
relinquish their right to privacy when using the organisations' IT
infrastructure, and that they cannot expect privacy when using IT
infrastructure belonging to the organisation.
Having the employees read, understand and sign a usage policy such as the
one above, the interception is no longer illegal and as such, can be used as
evidence in court, provided the chain of custody can be proved and the
integrity of the logfiles are beyond doubt.
My 2c -- not a valid legal opinion, but I do understand English!
Hi all,
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.7/830 - Release Date: 2007/06/03
12:47
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.7/830 - Release Date: 2007/06/03
12:47
Jaco Kroon
Julius Francis wrote:
> It boils down to the constitutional rights of the individual to privacy vs
> the rights of the organisation to protect its information assets.
>
> In an organisation where the usage policy explicitly states that the users
> relinquish their right to privacy when using the organisations' IT
> infrastructure, and that they cannot expect privacy when using IT
> infrastructure belonging to the organisation.
>
> Having the employees read, understand and sign a usage policy such as the
> one above, the interception is no longer illegal and as such, can be used as
> evidence in court, provided the chain of custody can be proved and the
> integrity of the logfiles are beyond doubt.
And just there it all breaks down. How do you prove that the logs are
authentic? Using vi to modify some logs or even to generate logs is
pretty easy...
Jaco
Julius Francis
another thread.
The point that I was trying to make was that it is not illegal to intercept
communications, provided that it has been done in the right way.
David Naude
users have waivered thier rights to privacy.
Does this need to be in the form of a physical policy signed by the
users, or can it be displayed in the form of a logon window when the
users logon to the company domain?
Although, if I read the RICA act as extracted in my original post, I
would assume that the interception of indirect communication which is
realted to a standard business transaction using the organisations IT
infrastructure would be legal without a policy in place. For example,
if I were to use the business systems to clear the financial data of a
customer, then can the log files be used as evidence?
To reply to Jaco,
My understanding is that ensuring the authenticity of a log file can
be done by log management systems, but the court will also have to
default to best evidence available. It should also be up to the
defence to proove that the log file has not been tampered with.
Julius Francis
If it were me, I would do both -- the paper based usage policy, signed and
filed away, as well as the logon as a "reminder". I would imagine that it
would be far easier to get a conviction if it can be proved that the
organisation's management have been diligent in making users aware of the
policy. It's the same when arresting a suspect -- the more often you inform
him of his rights, and document when you do, the less chance his defence
attorney will have to get him off on infringement of rights.
I guess that your question is: Referring to the provisions under which an
employer may monitor and intercept communications as outlined in Section 2,
6 (1) and (2), are the 4 provisions mutually exclusive or not? And, if some
are, which ones? (My guess is that it is those without the "and"). So we're
going to need a legal mind after all. Would Johann or anyone else care to
comment?
What Jaco is referring to is that it is relatively easy to "inject " syslog
traffic on a network. The logfiles are also usually in text format, making
them easy to edit and tamper with. The syslog protocol can UDP or TCP, and
as we know UDP is connectionless, thus unreliable. If an organisation wishes
to produce evidence that can stand up to the scrutiny of the defense, then
they will need to display a certain amount of diligence with the collection,
storage and archival of key logfiles, something like calculating hash
checksums of the files and storing them in encrypted format. I know that if
I were called in as an expert witness for the defense, there are hundreds of
places where reasonable doubt can be created about the integrity of the
logfile evidence and especially the chain of custody in handling and storage
of logfiles.
-----Original Message-----
From: Whiteha...@googlegroups.com
[mailto:Whiteha...@googlegroups.com] On Behalf Of David Naude
Sent: 04 June 2007 15:43
To: WhitehatAfrica
Subject: [WhitehatAfrica] Re: Debate regarding RICA act
Jaco Kroon
> I agree with Julius that there should be a policy in effect where the
> users have waivered thier rights to privacy.
>
> Does this need to be in the form of a physical policy signed by the
> users, or can it be displayed in the form of a logon window when the
> users logon to the company domain?
If I'm not mistaken, according to the ECT act a click-through agreement
is good enough in this day and age.
> Although, if I read the RICA act as extracted in my original post, I
> would assume that the interception of indirect communication which is
> realted to a standard business transaction using the organisations IT
> infrastructure would be legal without a policy in place. For example,
> if I were to use the business systems to clear the financial data of a
> customer, then can the log files be used as evidence?
>
> To reply to Jaco,
> My understanding is that ensuring the authenticity of a log file can
> be done by log management systems, but the court will also have to
> default to best evidence available. It should also be up to the
> defence to proove that the log file has not been tampered with.
Which is my point. Let's take a general Linux system (simply because
that is what I'm most familiar with), logs are sent off to /var/log/*
according to your syslog (whatever flavor you like to use)
configuration. From there there is _nothing_ protecting it from vim (or
any other text editor for that matter). As such it is practically
impossible to prove anything with regards to the logs. Does logging to
a remote syslog engine help? Yea, I reckon, permitting you can prove
that the person administrating that system is not in league with
whomever compromised the original target and thus being able to
coordinate messing with the logs. Proving that logs is authentic is
insanely hard in my personal opinion, and have yet to see something that
can be proven in court (I've built existing systems where I can know
that the logs I'm looking at is authentic, but the accused can simply
state "the administrator had the potential capability to tamper with the
logs" and the Judge would need to take that into consideration - so how
do I prove beyond reasonable doubt that I didn't alter the log files?
Jaco
Barry Du Plessis
> Yea, I reckon, permitting you can prove
> that the person administrating that system is not in league with
> whomever compromised the original target and thus being able to
> coordinate messing with the logs. Proving that logs is authentic is
> insanely hard in my personal opinion, and have yet to see something that
> can be proven in court (I've built existing systems where I can know
> that the logs I'm looking at is authentic, but the accused can simply
> state "the administrator had the potential capability to tamper with the
> logs" and the Judge would need to take that into consideration - so how
> do I prove beyond reasonable doubt that I didn't alter the log files?
Shouldn't that be the other way around? Ie, if you can show due
diligence in collecting and storing the logs, they are accepted as
authentic unless the defense can prove that they have been tampered
with? I think the burden of proof would be, not to prove that they
haven't been (or couldn't have been) tampered with, but rather the
opposition would have to prove that they HAD been tampered with.
Thanks
Barry
Julius Francis
rests with the State (and thus the Accuser, or the Plaintiff). "Wie beweer
moet bewys".
There are very few exceptions where the burden of proof falls on the
Accused.
There is also a difference in standards of proof. The State has to prove
"beyond reasonable doubt", whereas the Accused must merely prove it on "a
preponderance of probability". Thus the Accused has a lower standard to meet
than the State.
-----Original Message-----
From: Whiteha...@googlegroups.com
[mailto:Whiteha...@googlegroups.com] On Behalf Of Barry Du Plessis
Sent: 05 June 2007 07:49
To: Whiteha...@googlegroups.com
Subject: [WhitehatAfrica] Re: Debate regarding RICA act
Thanks
Barry
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.7/830 - Release Date: 2007/06/03
12:47
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.9/832 - Release Date: 2007/06/04
18:43
kadesemo
kindly establish the intent/purpose of the log file wrt to their
inability to use log files in the courts because of RICA.
Has log files exist which they intend turning to
or
Will they commence use of log file (for suspect) to be use for case at
hand.
Existence of Policy in place for either might vary. If log already in
existence and policy exist that grant business use and none
expectation of privacy, one can then log at integrity of said log
(refer to ECT as well). Indirect communication rule might then apply.
Howver, if the purpose of the log file is to commence eavedroping on
the said suspect, it becomes trick. I would not thinking indirect
applies even if a acceptable use policy was drafted, adopted,
implemented and communicated through. It could be argued that such
policy exist and user consent, the PRIMARY intent of the policy might
surface during trial and could be messy - directed target without
judicial approvial. There could be contempt, disregard for RICA in
itself.
Kindly note "...by means of which a transaction is entered into in the
course of that business" would falls away if logging is to "COMMENCE"
primarily for 'monitoring' suspect.
With the basic above out of the way, one can look at the process and
then the technology.
A well-thought through LOG management system with full congnisance of
Law of evidence will work irrespective of system implemented.
I said this because the log system want to
log specified communications (attributes)
store the log with record of each log as a piece
secure log in use (Jaco)
identification of each piece as unique log (hash, marked each hash to
a specified piece)
secure log at rest.
archive each piece in a "safe" place.
etc etc
The process should be known irrespective if paper record or computer
record (logs in this case)
The technology to use comes in.
Purchase an elaborate log management system?
Use Unix/Linux syslog (except if a vi/vim/joe/mc... would not change
integrity of 'original' file!)
Use Windows logging ability ......
strenght of key and type of harshing to use....
Whilst not a legal guy, I am optimistic that with right intent,
purpose, process and techology as well as procedure, RICA and ECT
could be put to test effectively.
Lastly, we must not forget that Privacy is a relative and highly
subjective (making it an interesting case to prove...)
Privacy is defined as the rights and obligations of individuals and
organizations with respect to the collection, use, retention, and
disclosure of personal information
There is the right which is also enshrine in SA contitutional rights
There is the obligation of the organisation (RICA, ECT, Privacy
bill...
Why is it collected
Wat is it being use for or to be use for
How nad for how long is it being retained
to whom is it being disclose to
Why is it being disclosed, what is the intent/purpose
Voice of the non-legal ...
A. Kayode
On Jun 5, 12:20 pm, "Julius Francis" <jfran...@telkomsa.net> wrote:
> I cannot speak for Civil law, but in Criminal law the burden of proof mostly
> rests with the State (and thus the Accuser, or the Plaintiff). "Wie beweer
> moet bewys".
>
> There are very few exceptions where the burden of proof falls on the
> Accused.
>
> There is also a difference in standards of proof. The State has to prove
> "beyond reasonable doubt", whereas the Accused must merely prove it on "a
> preponderance of probability". Thus the Accused has a lower standard to meet
> than the State.
>
>
>
> -----Original Message-----
> From: Whiteha...@googlegroups.com
>
> [mailto:Whiteha...@googlegroups.com] On Behalf Of Barry Du Plessis
> Sent: 05 June 2007 07:49
> To: Whiteha...@googlegroups.com
> Subject: [WhitehatAfrica] Re: Debate regarding RICA act
>
> 18:43- Hide quoted text -
>
> - Show quoted text -
Jaco Kroon
> A well-thought through LOG management system with full congnisance of
> Law of evidence will work irrespective of system implemented.
> I said this because the log system want to
> log specified communications (attributes)
> store the log with record of each log as a piece
> secure log in use (Jaco)
> identification of each piece as unique log (hash, marked each hash to
> a specified piece)
> secure log at rest.
A hash doesn't prove anything. The only thing a hash value proves is
that the logs has most likely not been altered since the hash was
generated. It says nothing about when the hash was generated, and as
such I can easily generate the required hash-value on-demand when I
tamper with the logs.
Be very sure to understand cryptography before you recommend the use of
particular technologies for something for which it isn't appropriate.
Hashes by themselves are useless for ensuring data integrity.
What you want is something that can be verified afterwards, but that
cannot be modified on the fly, and then you still want to prove that log
entries weren't removed, added or modified on the fly.
I don't see any easy way of achieving that (conceptually).
> archive each piece in a "safe" place.
Define safe. If I'm root nothing (except encrypted/digitally signed
data perhaps - note, not hashed data) is safe. And now the problems
becomes how to sign the log data without allowing the system
administrator of the system performing the signing to fabricate logs.
SELinux? That might help - a little bit. But somewhere along the line,
someone will technically be capable of fabricating the logs.
> etc etc
> The process should be known irrespective if paper record or computer
> record (logs in this case)
>
> The technology to use comes in.
> Purchase an elaborate log management system?
> Use Unix/Linux syslog (except if a vi/vim/joe/mc... would not change
> integrity of 'original' file!)
> Use Windows logging ability ......
Not sure what you're trying to say here. You can't really get away from
syslog/windows logger - you somehow need to hook these to implement any
kind of elaborate log management system.
In the Linux case you can simply replace the syslog daemon, but then you
still have an implementation of syslog ... it's just a matter of what
happens with the data after it has been sent to syslog.
> strenght of key and type of harshing to use....
This point is moot. hasing is one way, if I change the original data I
can simply re-generate the hash along with it. HMAC? Well, in order
for me to be having access to the log data I most likely will have
access to the HMAC key as well, invalidating that point.
The only way I can see this even possibly working is if the key is
somehow being mutated for every entry being logged, so as to ensure
sequencing of log entries. So if an entry gets added everything after
that goes out-of-sync, or when an entry is removed it can be shown.
Does this fix the problem? Actually no, since I can just sequentially
re-generate all the hash values once more.
This still doesn't prevent me from on-fly injecting log entries into the
system to be appropriately signed as would legit entries.
Jaco
Hendrik Visage
>
> I cannot speak for Civil law, but in Criminal law the burden of proof mostly
> rests with the State (and thus the Accuser, or the Plaintiff). "Wie beweer
> moet bewys".
Civil law is about the probabilities...
kadesemo
technically.
There is nothing absolute. All are relative! (and we dont have to
delve into the spiritual realm anyway!)
I will restate
- have a clear view of intent and purpose of implementing log
- define the process to manage the log system (generation, signing,
archieving, retrieving...)
- use appropriate technology to implement agreed to defined process
Should we look at the specific of log integrity.
Firstly from audit point of view, nothing is Absolute only relative
assurance/reasonableness!
> A hash doesn't prove anything. The only thing a hash value proves is
> that the logs has most likely not been altered since the hash was
> generated.
Within the process, defined, that is the purpose of the log signing.
To have a piece that can be recognised and can be said to be true
representation of what is being referred to.
> It says nothing about when the hash was generated,
This is what the process looked into...
- log specified communications (attributes)
- store the log with record of each log as a piece
- secure log in use (Jaco)
- identification of each piece as unique log
(hash, marked each hash to a specified piece)
- secure log at rest.
- archive each piece in a "safe" place, including off-site.
I am optimistic that a thought through administrative process will
'fully' compensate for the technology lapse/inadequacy.
This implied a particular log is deemed to have been genarated for a
specified period - an hour, six hours, half day, full day...
That 'piece' is signed and stored away. It can be identified and
refered to PRECISELY.
Should this not be possible then MD5 checksum et al have woefully
failed.
> such I can easily generate the required hash-value on-demand when I
> tamper with the logs.
I am curious if the on-demand hash-value will be EXACT or REPLICA.
Whilst being aware of the inadequacy of cryptography, I had propose an
administrative process to wrap around the technology process to ensure
the technology work as intended and as specified by ...
> What you want is something that can be produce, refered to and verified afterwards, but that
> cannot be modified on the fly, and then you still want to prove that log
> entries weren't removed, added or modified on the fly.
and even when at rest
and can be refered to as being original copy.
This implied compensatory controls are in place to mitigate against
the risk of super-beings (root, administrator...)
Physical, logical security in place amongst others.
The fundamental remains, value-cost of control remain as-is.
If the log system should be as tamper-proof as possible, then
appropriate direct controls and indirected process will be put in
place.
Thus, I am saying when a or the best technology is not the best, then
compensatory controls comes to play.
Will the opposition be successful in lack of due diligence, reasonable
control, inappropriate log system/mgt or negligence... not so sure.
I might love to know what is the Absolute proof in paper record or
voice log (telecom interception).
Will the process be consider, will the procedure be looked at, will
the integrity of the recorg/log be then considered, and reasonable
control in place to produce and safeguard record/log.
Should the head of security go into the store room and replace the
record/log, how will it be know - similar to root/admin changing (edit
or replace) log
I still look forward to ECT, RICA ... standing the test of time in
court. ECT has made it relatively easy if it would be viewed in light
what is written there-in.
Many thanx