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 Simplefirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users