Re: Alarming (was protocol analysis)

From: John S Flowers (jflowers@well.com)
Date: 03/07/02 

Date: Thu, 7 Mar 2002 14:24:42 -0800
From: John S Flowers <jflowers@well.com>
To: "Kohlenberg, Toby" <toby.kohlenberg@intel.com>

Toby,

I would postulate that there are two levels of network security with
regard to intrusion detection. The first level would be discovery; the
place where you hold some kind of recent, reliable network awareness about
what is actually running on your network. We could call this "Exposure
Enumeration" or some other language, but it's the important understanding
of your security posture.

In this first phase, you compare your exposures to your corporate policy
and come up with a detailed description of where you are within policy,
where you're outside policy and need to perform corrective action and
where you're outside policy, but cannot perform corrective action without
jeopardizing the requirements of your network (or business, for that
matter).

In this way, you've created an active policy profile, which is the basis
for the first part of any security system (network or physical);
established boundaries.

The second level would be to install burglar alarms on the network
environment. In this way, you can be (theoretically) alerted if your
policy has been violated. If the alarm goes off, you should assume your
policy failed in some way and an event has been triggered. You can then
match the alarm with the known network state and suddenly you have
knowledge of what, when, where and why; although probably not who. :)

This alarming level should ideally be comprised of several different types
of alarms, with the hope that at least one of them will catch the policy
violation. This is the repeated argument for pattern matching, anomaly
detection and other types of alarming.

Finally, and I believe the most complicated issue to date, you need some
way of correlating this information (hopefully, in real-time) so you can
act on those alarms that are outside of your known understanding of the
environment.

This last part is the real concern: there are very few, if any, commercial
products that provide an open way of communicating between the exposure &
policy management system and the burglar alarm systems. Because of this
and other technical issues, we're bombarded with false positives (and
negatives) from these burglar alarms because we can't correlate the
information in a meaningful way.

In my near-future dreaming, I imagine a system that performs discovery
(correctly), allows the customer to create & enforce policy based on the
uniqueness of their environment, and also provides a clean, well written,
accepted way of interfacing with the various types of intrusion detection
systems (alarms).

To me, that is the visible and tangible requirement for the future of this
technology if it is to succeed in the current climate; dynamic, high-speed,
  ever changing, hurricanes of data gathering, events and logging
requirements.

On Thursday, March 7, 2002, at 02:00 PM, Kohlenberg, Toby wrote:

> So this goes to a question I sent out yesterday or the day before-
> Will the winners be the folks who do one technology very very well
> and create partnerships or improve interoperability to handle the
> multi-tech approach or will the winners be the folks who do all the
> techniques in one product?
>
> Toby
>
>> -----Original Message-----
>> From: Marcus J. Ranum [mailto:mjr@nfr.com]
>> Sent: Wednesday, March 06, 2002 10:09 PM
>> To: John S Flowers; Robert Goldman
>> Cc: focus-ids@securityfocus.com
>> Subject: Re: Alarming (was protocol analysis)
>>
>>
>> John S Flowers wrote:
>>> I would put every possible different kind of alarm into my network
>>> environment and start comparing notes with them.
>>
>> Right!
>>
>> Remember the whole proxy/packet inspection firewall debate? Both
>> sides had good points! _BOTH_ sides were right, they just had
>> different
>> design goals and definitions of success. That's what will happen with
>> IDS. The eventual winners will be the folks who throw
>> everything they can
>> at the problem and make sense of the results.
>>
>> mjr.
>>
>

Relevant Pages

  • Re: No Shut Down or Restart for Domain Admins
    ... run rsop.msc from your DC and check which policy is responsible to this. ... I have created a group policy in a development network and imported it ... NT AUTHORITY\Authenticated Users Read (from Security Filtering) No ... Enforce user logon restrictions Enabled ...
    (microsoft.public.windows.server.active_directory)
  • Re: EventID 1054 from Userenv for startup script
    ... So if you said "some machines don't have full access to the network ... at startup" the GPO's seems not to apply correct. ... startup script policy. ...
    (microsoft.public.windows.group_policy)
  • Re: COBOL is Number One
    ... used for policy discussions across companies and continents. ... The Network empowers this. ... about the users using spreadsheets but was more worried about the fact ... My point was that there is increasing computer literacy in the work ...
    (comp.lang.cobol)
  • Re: Hang @ Applying Computer Settings/Applying Your Personal Setti
    ... It would appear the you have ruled out network connectivity problems ... >> Policy that has had changes but that should not happen every time unless ... >> computers having a gigabit network adapter. ... Policies are being created and maintained only on ...
    (microsoft.public.windows.group_policy)
  • Re: EventID 1054 from Userenv for startup script
    ... in the right window "Group policy Inheritance tab", ... Those two contain the requirement to "Wait for network before ... where the startup script did run but the deployment GPO would not. ...
    (microsoft.public.windows.group_policy)
Quantcast