RE: [logs] Philosophical perspective on auditing

ericfat_private

I've found it useful to describe in this fashion, especially when
interacting with people who aren't familiar with auditing.

I perceive three distinct uses for auditing:

1) Accounting - maintaining a log of legitimate activity for
administrative purposes
2) Intrusion Detection - recording activity that *might* be
illegitimate.  Depending on the activity this might be easy or
difficult.  Different systems might alert in real time or post facto via
log analysis.
3) Forensics - recording enough information that even if illegitimate
activity wasn't directly detected, that when evidence of illegitimate
activity is discovered via some other mechanism, that the logs can
provide enough information track down the wrongdoer, restore the system
to a trustworthy state, and/or prevent the same attack from occurring
again.

Notice that all of these can apply to a system, regardless of whether it
is "locked down" or not.  The amount and type of auditing can vary
widely from system to system.

Without trying to start any debates, I perceive that "auditing" differs
from "logging" primarily in its degree of trustworthiness- audit
consists of logs generated by trusted code in the system; all other log
data is just that- log data.  From an evaluation perspective (TCSEC &
CC), audit has specific requirements regarding the integrity of the data
all along the code path from event generation to persisting the data on
disk.

Eric Fitzgerald
Microsoft Corporation

-----Original Message-----
From: Joe Wulf [mailto:joe_wulfat_private] 
Sent: Monday, December 16, 2002 10:17 AM
To: Brian Anon; loganalysisat_private
Subject: Re: [logs] Philosophical perspective on auditing

Brian,

I like the points you made and your examples to back them up regarding
the philosophy of auditing.  I am interested in further discussion on
this train of thought, as I believe there is a wealth of informed,
experience people with strong beliefs on the how's and why's of
auditing.

I offer for consideration that another purpose of auditing is to detect
occurances of conditions that are both acceptable and unacceptable.

Syslog, as well as other auditing/logging tools are "configured" to
perform (or not perform) certain actions, as well as generate log
records based upon the nature of the event.  If the system(s) in
question are locked down/secured to protect the operating system,
applications and data within them, then some level of system (and/or
application) auditing will (should?) be enabled as well.  And its
purpose is to (generally) record successful/approved accesses as well as
disapproved accesses and failed attempts.

Manual/human analysis of audit records from such a system will indicate
if "bad" things are happening.  To some extent I believe this analysis
can be automated.

Respectfully,
-Joe Wulf

--- Brian Anon <brian_anonat_private> wrote:
> Justin,
> 
> The purpose of auditing is to prove what you say you are doing.
> 
> Philogophically, think about a tree falling in a forest.  Does the 
> tree
> falling making a sound if no one is there to hear it?  One theory is
"esse 
> est percipi" - to be is to be perceived.  This suggests that the tree
(or 
> sound of it falling) does not exist unperceived.  A weaker form
acknowledges 
> that the tree may exist unpercieved, but how can we claim to have
knowledge 
> of it existing unperceived?
> 
> Let's apply this theory of perception to intrusion detection (or
> logging/monitoring of any sort).  How can anyone claim to have
knowledge of 
> events occuring (such as extended use of privileges) unperceived?
Without 
> auditing it will not be possible to proove the state of extended
privilege 
> use to determine if there is a problem or not.  With this knowledge, 
> management can make informed decisions.
> 
> If you tell a customer you do 'X', how do you proove 'X' is actually
> hapening?
> 
> I consider the field of information security to be about cost 
> effectively
> mitigating risks to acceptable levels.  The common practice is to
layer 
> controls that will deter, prevent, detect or react to security
incidents.
> 
> Despite all the preventative controls in place, 100% security is not
> achievable.  100% security is not the objective.  A company should
plan to 
> react to security incidents that are not prevented for whatever
reason.  
> This is why companies establish business continuity plans, disaster 
> recovery, and incident response teams.  Inadequately detecting the
incident 
> may delay or prevent any response.  Spending on reactive controls will
not 
> be effective without corresponding detective controls.
> 
> Is your manager prepared for security incidents to go undetected?  You
> cannot respond to what you don't know.
> 
> Regads,
> Brian
> 
> >I am trying to explain to a manager (non technical) about audit but 
> >unable to get through him the point below.  I tried and tried but 
> >unsucessful. I am looking for some plain English with examples to 
> >show to him.  Any advise/info is appreciated.
> >
> >Auditing makes it possible to do the following:
> >Discover extended use of privilege that occurs when a user changes 
> >identity.  How is this done ? how does a user outside of Unix change 
> >identity?
> 
> 
> _________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail
> 
> _______________________________________________
> LogAnalysis mailing list
> LogAnalysisat_private 
> http://lists.shmoo.com/mailman/listinfo/loganalysis

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis