Documentation Effort for argus-3.0 release

Michael Hornung hornung at cac.washington.edu
Mon Oct 15 13:58:34 EDT 2007


Maybe one approach would be to extoll the virtues of Argus for a broad 
variety of uses, appealing to what people do and in so doing revealing 
the multiplicity of things Argus can do for all of them:

	- Security
		Policy audit, anomaly detection, scanner/worm detection
	- Accounting
		Per-customer use tracking
	- Performance
		Latency, loss, host configuration settings
	- Provisioning
		Bandwidth utilization, number of hosts on network
	- Reporting to mgmt
		Making pretty graphs =)

Then for each category give some working examples of how the various tools 
can be combined to produce immediately useful results.  With just a couple 
examples for each, people's minds will start racing with new ways to 
visualize their data.

-Mike

On Mon, 15 Oct 2007 at 13:36, Carter Bullard wrote:

|Hey Mike (et al),
|I think you're right, and possibly the best way to go then is to
|start telling people how to do stuff.  I have the things that I think
|are important, but again, most people are not that interested
|in my esoteric issues.
|
|So where to begin?  The principal strength of argus is the
|audit trail, at least from a forensics perspective, so many/some
|of the examples should be oriented toward the audit.  Most
|of the recent stuff is oriented around real-time situational
|awareness.  But that is pretty high on the complexity chart,
|so maybe not a primary focus?
|
|Most people do periodic audit processing for things, like access
|control policy validation, Top N talkers, rudimentary intrusion
|detection, matrix baselining etc....  We can start talking
|about what one can do from this perspective.
|
|A lot of sites run simple scripts, such as out-order (the number
|of hosts an internal machine is talking to).  If a machine gets
|over a certain threshold, generate a list.  That kind of thing.
|Is this a reasonable starting point?
|
|I quietly slid in radark.pl, a sample perl script that  generates a
|scanner report, which is pretty useful.  Is that a good starting point?
|Generating IP address inventories is extremely important for
|long term tracking, should we talk about that?
|
|
|Sorry to ask so many questions, but I can write about a lot of
|things, so if we had some consensus, I could/should start today ;o)
|
|
|Carter
|
|
|On Oct 15, 2007, at 10:44 AM, Michael Hornung wrote:
|
|> Yes those look good but I think their importance is the reverse of the
|> order listed.  Probably most people interested enough to learn about Argus
|> can get it installed and running, and most can get archives working pretty
|> well, but the data analysis portion is what is most interesting.  If you
|> can get people seeing good results/reports when evaluating the software
|> then they will be more motivated to make sure they get it deployed and
|> maintained well.  That's my $.02.  =)
|> 
|> -Mike
|> 
|> On Sat, 13 Oct 2007 at 12:57, Carter Bullard wrote:
|> 
|> |Gentle people,
|> |Now that we're getting closer to official release (code does seem
|> |to be stable) I need help on what to do to get the release ready.
|> |
|> |I would like to put a final effort into documentation, as that has been
|> |the biggest criticism of the argus project.  I believe the man pages
|> |are in good order, the INSTALL and README I also believe are in
|> |good shape, but there probably is need for an up to date FAQ, and
|> |a set if HOW-TO guides may be in order.
|> |
|> |I can write pretty quickly, but I need some direction, in order to be
|> |quick about it.  I'm sure that what I think is needed, is not what
|> |others actually need.
|> |
|> |I see three basic areas:
|> |   1. Deployment
|> |   2. Archive Establishment and Mantenance
|> |   3. Data Use and Analysis
|> |
|> |This is just one break out.  Would it be what you would work on
|> |to make argus better for the new user/ casual user?
|> |
|> |Carter
|> |
|> |
|> 
|



More information about the argus mailing list