Mark Burgess wrote: > I tend to agree with Ed that looking for unauthorized changes is like looking > for a needle > in a haystack. Change is the normal state of affairs for many systems. If > nothing changed > our systems wouldn't be much use.
I agree with many of the comments thus far. It is a hard problem. That's why it's better to change the problem, if you can. For example, most commercial change management systems centrally log EVERYTHING (that is the only right way since nothing slips past) for reporting BUT also have a notion of "change windows". That is, "authorized changes" are ones which tie into your visible ops process (great book, BTW, cheap and fast read too). Authorized changes have been reviewed, approved and scheduled. Authorized changes don't happen outside scheduled change windows. Many commercial offerings lock systems down (think schg or RO / like you see on netboot systems) so that even root can not make changes unless the time falls within a scheduled window. If you log everything (also essential since you need to know what goes wrong when things break), and have a notion of "approved windows", you can more easily apply filters to your verbose logs giving meaningful reports on "good" vs "bad" vs "suspect" changes. You can also hush notification during approved windows. So time can be used to define "authorized" as much as content. These systems also have the notion of blacklists and whitelists -- files that should never change (and always alert if they do), and files that change so frequently no one cares. > The usual approach to "authorizing change" is to partition files somehow into > those that > we expect to change uncontrollably and those we don't. During "contolled > changes" of those > "authorized only" areas Justin would like no notification, this however leads > to all of > the preconditions for a "race condition" in security language. It would offer > a window of > opportunity for someone to make an unauthorized change (James Bond runs past > while the > camera is looking the other way). That's why you really must log everything, authorized or not. The system is still not perfect as you point out, but I think it is a few steps in the right direction. With everything logged, you can revert to log surfing as needed, but also get less spam for the overworked admin. With time, most of this can be designed by anyone for free... It becomes a cost-benefit discussion with management. Oh, and as for those "commercial systems" -- they have exorbitant costs which cover development time, limited platform support, no real community (I don't consider paid support a community -- it's a good option to have, but not a replacement for something like this list)... As many pitfalls as advantages. IMCO, better to work with an open source product like cfengine and feel you haven't sold your soul. > I think that reason security is a pain is that it has no short cuts. You have > to examine > all logs. We all hate being searched at airports, but we also know that > threats are > masters of disguise. It's a dull job, but someone has to do it. My OCD nature finds this to be one of the reasons security is fun. ;) I suggest hiring security minded types who share the same feelings if you really a) need this type of work at your organization and b) don't enjoy it much yourself (or wear so many other hats you don't have time to try to enjoy it). As usual, those who enjoy what they do typically do it best. The security profession is becoming more mainstream, and less "optional" for most organizations (thank $DIETY). Also, to point out the obvious, even when logsurfing... Computers make doing that faster and easier than ever before. There are many tools, and languages to write your own. Again, cost-benefit. > I imagine that there will be developments in cfengine to help with such > issues in the > future, but such things require a little research to figure out. Code founded on research. Still one of the most desirable cfengine characteristics to me personally. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
