Re: All Fluff
Posted Jun 6, 2002 22:11 UTC (Thu) by
DeletedUser1598 ((unknown), #1598)
In reply to:
Re: All Fluff by AnswerGuy
Parent article:
Unique Preventative IDS for Linux
Hello Jim,
I appreciate the time you've taken in formulating your responses to my comments.
About authentication in general...
I don't bring this up as a particular problem area, but rather as an area that must be done "right" in order to have securable systems. Individual users might screw up and impinge the security of the system, but without the mechanisms in place and some formal policy stating that they're going to be followed, the box is not very securable.
Firewalls...
I don't know that I have a good handle on the benefits of commercial firewalls vs. their open source brethren. My suspicion is that the benefits fall into the areas of managebility by "C" or "B" level staff rather than "A" level staff. Beyond that, maybe it's just that budget people want to have a company that they can blame when things break.
Encryption...
In my own experience, I've found that GPG is enough extra work to use, that I just don't endup using it as often as I should. I could probably institute a policy here that would for me to, but I doubt that I'll do that any time soon. Human laziness simply isn't working for me here. :(
MAC...
I think that an older version of Grsecurity was included in a Mandrake distribution not to far back. But yes, the fact that some form of MAC (beyond just file access control) is not a default feature doesn't help. The subverted user or process method of getting around ACLs is why behavioral control is a key component of creating securable systems. The difficulty of actually using strict MACs without just creating blanket holes is, in my opinion, the reason for their scarcity despite their age and the protection they can provide.
More MAC...
I guess this is a shameless plug, but it's for open sourced code, so I don't feel to bad about it. We are working with Michael and Brad of the Grsecurity.net project to make the ACL system self training. Well, sort of self training, as the admin you have to tell it when to start and stop training. This provides for a much simpler way to create ACL rules that have only the necessary holes in them, and ensure that those holes are no bigger than absolutely necessary. We're currently running this code in house shaking some of the last bugs out of it before its beta release. Information about this will be carried at www.grsecurity.net and at www.cylant.com.
File integrity...
This is an area where I have mixed and conflicting feelings. On the one hand, file integrety checkers can be a tremendous boon when an attacker manages to subvert the security mechanisms in place on a server. On the other hand, if the security mechanisms weren't so frail and blindsidable as they are today, this wouldn't be nearly the issue it is. Mostly, I like the fresh-backup on a CD or a spare off-line disk method myself.
Behavioral control...
This is the one area that you didn't address. It also happens to be the area that I see most security and comp sci folks ignore, but the area that engineers and accountants look at first. I think this has to do with the education we get in the security and comp sci disciplines, but I'm not sure. Behavioral control speaks to monitoring application execution looking for deviances from its normal execution activity. There are a variety of ways to do this, some are really slow, others aren't, some don't work very well, others do.
Security seen as control...
We tend to look at security as control because of the following:
If you can control the resources a process can access, and if you can control the execution behavior of that process, and if you can control who is allowed to run that process, you've got a handle on security. But, if you can't do even one of those things, then attackers, internal or external, can do things your security policy probably doesn't allow. Control is where the rubber meets the road. Control is not forensics, its purpose is to prevent undesirable situations, not generate reports about their damage level and outcome.
Naturally we'd like people to use our software where it's applicable. But, we also recognize that we don't build tools or offer services across the three areas of preventative security. To a certain extent, we're not really interested in doing so. We're moving into the MAC area simply because it makes sense for that to integrate with our current product. We're also giving it away for free too, since that seems to be the smartest thing to do in that case.
Regards,
scottwimer
(
Log in to post comments)
