hi Andrew,
in his e-mail, John has already provided several scenarios for changing the
system state from SEC. One of the examples John has outlined involved
changing firewall rules and I've done that as well in the past. To provide
more examples, Markus Kont released his SEC attack detection rules few
years ago (https://github.com/markuskont/SagittariuSEC/) which also
automate firewall configuration.
I have also used SEC for automating tasks often done with cron, such as
downloading signature updates and restarting daemons. While these actions
might not be considered fundamental changes, they nevertheless alter the
state of the system.
As a side note, SEC Calendar rules have one interesting feature that
cron/crontab lack, and it is best explained with the following time
specification: 0 1 25-31 10 7
Crontab interprets this time specification as "1AM in October, provided
that the day of the month is 25..31 OR weekday is Sunday". In October 2017,
that would have meant 1AM on October 1, 8, 15, 22, and 25-31. However, SEC
Calendar rule considers the above specification as "1AM in October,
provided that the day of the month is 25..31 AND weekday is Sunday". Since
conditions for day of the month and weekday are now joined with logical
AND, this essentially means "1AM on last Sunday in October" (for example,
1AM on October 29 2017 or 1AM on October 25 2009).
It is quite easy to see that implementing OR-like functionality is
straightforward with Calendar rules (for example, have two Calendar rules
with specifications 0 1 25-31 10 * and 0 1 * 10 7). On the other hand,
with crontab interpretation one can not implement AND-like functionality,
and scripts started by cron need additional checks for day/weekday. My
apologies for the lengthy sidenote :)
However, all system management tasks I have automated so far have had clear
execution paths, so it has been possible to write rules for handling all
execution scenarios. If that is not the case (for example, some execution
scenarios might require highly specific and unpredictable human
interaction), I would not use any automation, be it by SEC, cron or any
other tool.
kind regards,
risto
2018-03-07 20:12 GMT+02:00 Andrew Nieuwsma <anieuw...@cray.com>:
> Hello,
>
> I’m curious about use cases for SEC. I know from reading the man page,
> using SEC and viewing the documentation that SEC is obviously a correlation
> tool and that it can perform actions in response to state of the system
> (monitored in log files etc.). 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.
>
>
>
> 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. 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.
>
>
>
> 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. 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.
>
>
>
> Any response is appreciated.
>
>
>
> Regards,
>
> Andrew Nieuwsma
>
>
>
> ------------------------------------------------------------
> ------------------
> 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
>
>
------------------------------------------------------------------------------
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
