Hello Andrew:
In message
<bn7pr11mb277181d7ccd8b8a64b276ba8c2...@bn7pr11mb2771.namprd11.prod.
outlook.com>, Andrew Nieuwsma writes:
>[...] I've been having a
>discussion with some colleagues about a particular SEC use case and I
>am wondering if anyone can say if they've run across it before and
>what their general opinion of it was.
>
>Specifically SEC can be setup to perform SHELLCMD actions, which can
>in theory probably do anything as it's a shell (assuming
>permissions). Do you know of anyone using SEC to modify the state of
>the world? To add more clarity, I don't mean just writing a log
>file, or sending a notification, or adding a value to a whitelist or
>blacklist, but some sort of action that more fundamentally changes
>how the system operates.
I have done the following:
* changing firewall rules across a number of machines to respond to
a horizontal port scan. Then later after a timed interval clearing
the same rules.
* running an automated cleanup script once to free up additional
disk space between 10PM and 7AM if a disk passes 80% full. On a
second event in the 10PM-7AM time period, annoy a human until they
take action.
* restarting a malfunctioning service up to three times in 5 minutes
before giving up on automated recovery and notifying a human
Do these meet your criteria?
>An abstracted and very hypothetical example might be, the system
>detects higher than normal power usage in a hard drive and uses the
>shell to forcibly unmount the drive and kill the power to it. This
>action would be taken to prevent physical drive destruction, but is
>considered a dangerous action as it may cause some data loss, for the
>sake of preserving the drive.
I would expect if the drive was in a raid array, using SEC to fault
the drive and trigger/control a rebuild to a spare would be another
use case.
>And for sake of argument let's pretend
>that if a human operator received a notification about such an event
>that they would be highly likely to do the same action.
>
>Maybe a different hypothetical example is: SEC notices that user X
>has tried to modify a protected part of the operating system
>repeatedly, so the SEC launches a SHELLCMD to find all active process
>by user X and forcibly Kill them and disconnect his session.
>
>Does anyone know of usages where 'state changing actions' are taken?
>Is it generally considered in the use case for SEC, or is it just
>something that SEC "can do" using your own best judgement.
I have done my three examples above. One as part of a plugin to
nagios where SEC was used as the correlation engine.
How people use SEC is up to them. Triggering automatic actions when
recognizing a pattern is certainly part of SEC's use case. They can
either be run directly by SEC, or SEC can trigger another process
(with sufficient privs) to take action.
If you can't determine exactly what action should be taken because the
events you see can have multiple causes, then you simply notify a
human with SEC to sort out what's happening.
>The reason why I ask this is, from an architectural point of view if
>the system has this SEC daemon running that may be configured to
>actually modify the state of the system based on event correlations,
>it increases the overall risk of an admin potentially not having
>visibility into 'what really running' on the system and could
>certainly lead to an increase in system complexity.
Well that's true of any automation mechanism. If a problem happens and
the documented fix is run the script "blah", does the admin know what
"blah" is really running? In this case does it matter if a human
operated as a pattern recognizer and ran a canned script or if SEC
recognized the pattern and ran the same canned script?
If you are using config management and the CM agent runs every 10
minutes to validate/change the system, do you know what it's actually
doing?
Using SEC doesn't mean you don't report/log the action and state
change to some human so they can see that something ran to fix a
problem.
Automation in most cases means giving up a level of control for
automatic responses to failures. E.G. a raid array increases
complexity and introduces new failure modes if not set up
correctly. It also means that you aren't taking 24 hours downtime to
restore your data if a disk fails.
>It is my position that 'actions that modify the actual state of the world'
>should be done by a different application, and not just 'pushed into
>SEC' because it has the capacity to run shell commands.
SEC can trigger that different application to do SEC's bidding. In
most cases I have SEC directly run a script that carefully vets
arguments and implements much more complex logic than could (should)
ever be expressed in a single shell command.
However SEC can write trigger commands to a pipe, socket (TCP or UDP),
or file if you want to drive some uber-application daemon that has
root privs while SEC has limited privs. I am hard pressed to find
value in maintaining another piece of software that acts as a broker
for SEC's actions unless you are doing some sort of privilege
separation mechanism.
Have a great week.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
