Andrew,
From an architectural point of view SEC correlates events and fires up actions
in response. If you need to modify something, it would be done with an external
tool anyway because SEC knows nothing about the world.
I think I am missing your point.
-- ek
From: Risto Vaarandi [mailto:risto.vaara...@gmail.com]
Sent: Thursday, March 08, 2018 7:22 AM
To: Andrew Nieuwsma <anieuw...@cray.com>
Cc: Simple-evcorr-users@lists.sourceforge.net
Subject: Re: [Simple-evcorr-users] SEC use cases -> modifying the state of the
world
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<mailto: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<mailto: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
