openxdas-devel Mailing List for OpenXDAS - Distributed Auditing Service (Page 2)
Brought to you by:
dsandersorem,
jcalcote
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
(8) |
Mar
(1) |
Apr
(25) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Wayne H. <wh...@no...> - 2007-04-19 14:01:43
|
Are we confined to these names for the Correlation only? I thought the = field is extensible, therefore, instrumenation application can use = whatever names that make sense within its domain, be it sessionid or auid, = as long as it follows the name=3Dvalue format. Wayne Hsu Senior Software Engineer, eXtend Engineering (703) 967-4980 Novell, Inc., the leading provider of Net Business Solutions. www.novell.com >>> "David Corlette" <dco...@no...> 04/13/07 7:43 PM >>> John, I agree with what you are saying, exactly. Correlation has a slightly = broader meaning in the context of Sentinel, but the use of that word here = - e.g. to help us correlate between several related events - is perfect. As for the field format, that also works for me. So far we seem to have come up with: sessionid processid threadid requestid I notice that the LAF (SuSE Linux audit framework) uses "auid" - but = perhaps this could be considered a "sessionid" or "requestid"? Anyone else care to comment? >>> On Sat, Apr 14, 2007 at 12:58 AM, in message <461F6251.37FF.0081.0@nove= ll.com>, John Calcote wrote:=20 > Okay, I see now.=20 > =20 > You called it instanceid, but in reality, it's a form of general = purpose=20 > correlation id, right? I think the concept of correlation id is = generic=20 > enough (regardless of the domain) to put it into the HDR section.=20 > Furthermore, why not define some standardized correlation id types, and = apply=20 > them within a single field in the HDR section?=20 > =20 > For instance, you called it instanceid, but that could mean anything. = Why=20 > not have a field in the HDR section called <correlation> whose format is = comma=20 > separated <idname>=3D<idvalue> pairs. For instance: > =20 > sessionid=3D096v432lkna9er8h42okn,processid=3D12345,threadid=3D27 > =20 > That way, we can add id types as we see the need - the field is = extensible,=20 > like the event data field, but it is specialized enough, and globally=20 > important enough to warrant its own field, and is generic enough in = nature to=20 > events in general to warrant a place in the HDR section. > =20 > From an API perspective, header information is VERY controlled - most of = it=20 > is self generated. That is, not specified by the caller, but rather by = the=20 > XDAS client library. This is not always true, but where it's not true - = as in=20 > the cases of (eg) event number and outcome code - the client API = provides=20 > well-defined functions to set those values and ensures that they conform = to=20 > the XDAS standard. We would want to provide similar additions to the API = to=20 > set correlation information, and we would want to auto-generate some of = the=20 > more obvious id values such as process and thread. The auto-generated = values=20 > could be policy controlled by configuration file entries. > =20 > Whereas event data is very free form and user-defined/specified, = correlation=20 > information is very controlled. > =20 > I believe correlation information is important enough to warrant this = sort=20 > of management. What do you think? > =20 > John >=20 >>>> On 4/12/2007 at 7:04 PM, in message <461...@no...>,= David Corlette <dco...@no...> wrote: >=20 > Hi John, >=20 > I debated about this - I think the Instance ID will be wildly useful = outside=20 > the EVT structure (NVP) as a way of connecting multiple events together = into=20 > a stream of related events. So I *absolutely* think that it needs to = have=20 > its own field, and I think it can be domain-specific as to the meaning = of the=20 > ID (NAM, for instance, creates some sort of connection ID which is = opaque,=20 > but would serve this purpose). >=20 > As for putting it in EVT, I don't actually care - HDR seemed to be = more=20 > information about the structure of this event, not actually any event = data. =20 > But I could see pulling it up to that level as well. >=20 >=20 >> May I ask why you've decided to add this value here? Event Data has a = very=20 >> well-defined format: comma separated name=3Dvalue pairs. You could = have=20 >> specified that instanceid be added as a well-known name/value pair. = Better=20 >> still, if it's supposed to be a process id, then simply call it=20 >> processid=3Dxxx, as a well known name/value pair. The standard doesn't = define=20 >> any well-known name/value pairs today. If it's something that is = really=20 > useful=20 >> in all cases, perhaps we should consider adding it to the HDR section. >=20 >=20 >=20 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share = your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE= VDEV _______________________________________________ openxdas-devel mailing list ope...@li... https://lists.sourceforge.net/lists/listinfo/openxdas-devel |
From: David C. <dco...@no...> - 2007-04-13 23:43:24
|
John, I agree with what you are saying, exactly. Correlation has a slightly broader meaning in the context of Sentinel, but the use of that word here - e.g. to help us correlate between several related events - is perfect. As for the field format, that also works for me. So far we seem to have come up with: sessionid processid threadid requestid I notice that the LAF (SuSE Linux audit framework) uses "auid" - but perhaps this could be considered a "sessionid" or "requestid"? Anyone else care to comment? >>> On Sat, Apr 14, 2007 at 12:58 AM, in message <461...@no...>, John Calcote wrote: > Okay, I see now. > > You called it instanceid, but in reality, it's a form of general purpose > correlation id, right? I think the concept of correlation id is generic > enough (regardless of the domain) to put it into the HDR section. > Furthermore, why not define some standardized correlation id types, and apply > them within a single field in the HDR section? > > For instance, you called it instanceid, but that could mean anything. Why > not have a field in the HDR section called <correlation> whose format is comma > separated <idname>=<idvalue> pairs. For instance: > > sessionid=096v432lkna9er8h42okn,processid=12345,threadid=27 > > That way, we can add id types as we see the need - the field is extensible, > like the event data field, but it is specialized enough, and globally > important enough to warrant its own field, and is generic enough in nature to > events in general to warrant a place in the HDR section. > > From an API perspective, header information is VERY controlled - most of it > is self generated. That is, not specified by the caller, but rather by the > XDAS client library. This is not always true, but where it's not true - as in > the cases of (eg) event number and outcome code - the client API provides > well-defined functions to set those values and ensures that they conform to > the XDAS standard. We would want to provide similar additions to the API to > set correlation information, and we would want to auto-generate some of the > more obvious id values such as process and thread. The auto-generated values > could be policy controlled by configuration file entries. > > Whereas event data is very free form and user-defined/specified, correlation > information is very controlled. > > I believe correlation information is important enough to warrant this sort > of management. What do you think? > > John > >>>> On 4/12/2007 at 7:04 PM, in message <461...@no...>, David Corlette <dco...@no...> wrote: > > Hi John, > > I debated about this - I think the Instance ID will be wildly useful outside > the EVT structure (NVP) as a way of connecting multiple events together into > a stream of related events. So I *absolutely* think that it needs to have > its own field, and I think it can be domain-specific as to the meaning of the > ID (NAM, for instance, creates some sort of connection ID which is opaque, > but would serve this purpose). > > As for putting it in EVT, I don't actually care - HDR seemed to be more > information about the structure of this event, not actually any event data. > But I could see pulling it up to that level as well. > > >> May I ask why you've decided to add this value here? Event Data has a very >> well-defined format: comma separated name=value pairs. You could have >> specified that instanceid be added as a well-known name/value pair. Better >> still, if it's supposed to be a process id, then simply call it >> processid=xxx, as a well known name/value pair. The standard doesn't define >> any well-known name/value pairs today. If it's something that is really > useful >> in all cases, perhaps we should consider adding it to the HDR section. > > > |
From: John C. <jca...@no...> - 2007-04-13 17:41:04
|
(Adding the thread to the developer list) David, You're right, I was really confused about the usefulness of event classes initially during implementation, because there didn't seem to be any sort of encoding of event class within the audit record. Here's the enlightening bit from section 4: - - - - 4.4.3 Event Classes Audit Events may be specifically referenced by an Event Number. A set of Audit Events may be referred to by an Event Class. The concept of an Event Class is included in the XDAS solely as an administrative convenience. It provides an efficient and convenient reference to sets of audit events so that audit filters can be easily defined. An audit event record only includes the Event Number. It does not include any reference to Event Class for two reasons: its inclusion leads to redundant information in the audit record; and the mapping of event classes across administrative domains is problematic. When specified in filtering selection criteria, an event class is translated internally into the individual event numbers. Default Event Classes The XDAS defines a default set of event classes. Others can be defined by the implementation and configured by a system administrator to group together XDAS event numbers in a meaningful way. The default set of event classes defined by the XDAS are listed below: * Account management events * User session events * Data item and resource element management events * Service and application management events * Peer association management * Data item or resource element content access events * Exceptional events * Audit service management events The default mapping of events to these event classes is as listed in Section 4.4.2. - - - - The spec talks here about redundancy between event numbers and event classes - I think "redundancy" in this case refers to the fact that ALL events in the A, B, or C event types must be registered with a central public registry, so everyone has access to all of the important event set information. Basically, event classes can only be defined for registered (and thus well-known) sets of event numbers. If that's so, then presumably class information really is redundant because all vendors will have public access to all registered event classes/sets. If, on the other hand, you take the stance that event classes are similar in nature to the application id's registered with Novell for Novell Audit, and event class owners may do what they wish with the values within that class, then you have an information problem. Without knowing the event class, you can't make a guess as to the nature of the events within the class. But this is exactly why the spec writers chose the path they did. Even within Novell Audit, which sends out the class id with the event id, you still have no earthly idea of the nature of a given event with only the public knowledge of the semantic meaning of the class id to go on, and Novell didn't require (or provide a mechanism for) vendors to document publically the nature of their application specific events - only the class was registered. XDAS was trying to solve this problem two ways: 1. Force major event classes to be publically registered by individual event number, so that independently written tools would work well with all known event types. 2. Pressure audit instrumentation writers to choose to use existing well-known events by making it somewhat painful to make up their own events (they have to use the registration process). Instrumentation writers don't like this because they rarely feel that their event needs fit nicely into the existing categories. But the categories were designed to be truly generic, and the EDATA section was added to allow application instrumenters to add domain-specific information in an easily consumable manner (comma-separated name/value pairs). Remember, the end goal here is to standardize an audit event taxonomy. If it's simple to add events, then eventually overlapping sets will become prolific, and the entire system will break down. I think the XDAS spec writers did an admirable job of designing something that was both simple to use, reasonably simple to extend, and flexible enough that most people would be happy with it. As an aside, it's also interesting to note that, while this section makes reference to specifying filtering criteria based on event class, there is no mechanism defined by the section on filtering to actually filter by class! John >>> On 4/13/2007 at 4:38 AM, in message <461...@no...>, David Corlette <dco...@no...> wrote: Hi John, OK, I'm confused. The XDAS spec talks about "Event Classes" (section 6.10.3), but I don't see where those would show up in the actual event. There's a vague reference earlier on saying: "It does not include any reference to Event Class for two reasons: its inclusion leads to redundant information in the audit record; and the mapping of event classes across administrative domains is problematic. When specified in filtering selection criteria, an event class is translated internally into the individual event numbers." So, my reading of this is that the Event Class is used internally to the audit system to help with filtering, but the downstream consumers are screwed. ;-) I also don't see why the Event Class can't be embedded in the event code bitmap, the way the Outcome codes are classed. Of course, I also come back to my argument about using the higher-order bytes for holding the classes, rather than the lowest. The language I'm using does not support bit-wise operations, so I can't do what they suggest to filter by class. What's your interpretation of all this? >>> On Fri, Apr 13, 2007 at 1:39 AM, in message <461...@no...>, John Calcote wrote: > Dave, > > You should have a copy of this spec if you're going to help with changes to > it (and I hope you will continue to do so). > > John |
From: John C. <jca...@no...> - 2007-04-13 16:58:21
|
Okay, I see now.=20 =20 You called it instanceid, but in reality, it's a form of general purpose = correlation id, right? I think the concept of correlation id is generic = enough (regardless of the domain) to put it into the HDR section. = Furthermore, why not define some standardized correlation id types, and = apply them within a single field in the HDR section?=20 =20 For instance, you called it instanceid, but that could mean anything. Why = not have a field in the HDR section called <correlation> whose format is = comma separated <idname>=3D<idvalue> pairs. For instance: =20 sessionid=3D096v432lkna9er8h42okn,processid=3D12345,threadid=3D27 =20 That way, we can add id types as we see the need - the field is extensible,= like the event data field, but it is specialized enough, and globally = important enough to warrant its own field, and is generic enough in nature = to events in general to warrant a place in the HDR section. =20 >From an API perspective, header information is VERY controlled - most of = it is self generated. That is, not specified by the caller, but rather by = the XDAS client library. This is not always true, but where it's not true = - as in the cases of (eg) event number and outcome code - the client API = provides well-defined functions to set those values and ensures that they = conform to the XDAS standard. We would want to provide similar additions = to the API to set correlation information, and we would want to auto-genera= te some of the more obvious id values such as process and thread. The = auto-generated values could be policy controlled by configuration file = entries. =20 Whereas event data is very free form and user-defined/specified, correlatio= n information is very controlled. =20 I believe correlation information is important enough to warrant this sort = of management. What do you think? =20 John >>> On 4/12/2007 at 7:04 PM, in message <461...@no...>, = David Corlette <dco...@no...> wrote: Hi John, I debated about this - I think the Instance ID will be wildly useful = outside the EVT structure (NVP) as a way of connecting multiple events = together into a stream of related events. So I *absolutely* think that it = needs to have its own field, and I think it can be domain-specific as to = the meaning of the ID (NAM, for instance, creates some sort of connection = ID which is opaque, but would serve this purpose). As for putting it in EVT, I don't actually care - HDR seemed to be more = information about the structure of this event, not actually any event = data. But I could see pulling it up to that level as well. > May I ask why you've decided to add this value here? Event Data has a = very=20 > well-defined format: comma separated name=3Dvalue pairs. You could = have=20 > specified that instanceid be added as a well-known name/value pair. = Better=20 > still, if it's supposed to be a process id, then simply call it=20 > processid=3Dxxx, as a well known name/value pair. The standard doesn't = define=20 > any well-known name/value pairs today. If it's something that is really = useful=20 > in all cases, perhaps we should consider adding it to the HDR section. |
From: David C. <dco...@no...> - 2007-04-13 01:04:35
|
Hi John, I debated about this - I think the Instance ID will be wildly useful outside the EVT structure (NVP) as a way of connecting multiple events together into a stream of related events. So I *absolutely* think that it needs to have its own field, and I think it can be domain-specific as to the meaning of the ID (NAM, for instance, creates some sort of connection ID which is opaque, but would serve this purpose). As for putting it in EVT, I don't actually care - HDR seemed to be more information about the structure of this event, not actually any event data. But I could see pulling it up to that level as well. > May I ask why you've decided to add this value here? Event Data has a very > well-defined format: comma separated name=value pairs. You could have > specified that instanceid be added as a well-known name/value pair. Better > still, if it's supposed to be a process id, then simply call it > processid=xxx, as a well known name/value pair. The standard doesn't define > any well-known name/value pairs today. If it's something that is really useful > in all cases, perhaps we should consider adding it to the HDR section. |
From: John C. <jca...@no...> - 2007-04-12 19:39:13
|
David, Continuing our discussion about changes to the spec on a new thread... I see you added workflow events (copied to this text for discussion): Workflow Events More and more security domains use the concept of workflow as part of validating the correct operation of a system. Granting privileges or account creation, for instance, may require an approval process, or important events may cause notifications to occur that automatically escalate. The events below help track the events that occur within a workflow for auditing purposes. It will of course be critical to be able to connect workflow events back to the original trigger event * for this reason workflow events are expected to make heavy use of the instance ID within the OpenXDAS event structure. OpenXDAS Workflow Event Numbers XDAS_AE_NOTIFICATION_SENT 0x0000108E This event should be reported when some other event triggers a workflow, and notification is sent to some receiving party that the original event occurred. XDAS_AE_APPROVAL_REQUESTED 0x0000208E This event should be reported when some other event triggers an approval process, and the approval request is sent to some receiving party. XDAS_AE_APPROVAL_RECEIVED 0x0000308E This event should be reported the approval is received back from the approving party. XDAS_AE_REQUEST_ESCALATED 0x0000408E This event should be reported when a previous notification or request is sent, but not responded to or acknowledged within a defined timeout period. Excellent. I'm soliciting feedback from the community regarding the completeness of this set - anyone? I see you've also added the audit startup and shutdown events we talked about. Again - perfect (IMHO). I see you've also added an instanceid field to the event data section: There are two fields for event-specific data: Instance ID Event Specific Information The Instance ID is a tag used to keep track of multiple events that are related in some way; the ID should match across all such events. For instance: When a service is invoked, the process ID could be placed here so that the corresponding process termination can be matched to it. When a user initiates a session with some end system, a session ID can be placed here to track the user's activities within that session. When an approval workflow is initiated, a request ID can be placed here so the workflow can be tracked through to completion. The Event Specific Informationcontains other domain-specific information that can be parsed to further understand the event. May I ask why you've decided to add this value here? Event Data has a very well-defined format: comma separated name=value pairs. You could have specified that instanceid be added as a well-known name/value pair. Better still, if it's supposed to be a process id, then simply call it processid=xxx, as a well known name/value pair. The standard doesn't define any well-known name/value pairs today. If it's something that is really useful in all cases, perhaps we should consider adding it to the HDR section. John |
From: John C. <jca...@no...> - 2007-04-12 17:38:35
|
(Forwarding to developer list) David, I see you are a step ahead of me. :) I've only just started to read your = proposed changes doc, and I see that you've already done what I asked you = to in your last note - send a list of proposed changes. Sorry for not = paying more attention. I've begun to read through your modified OpenXDAS user's manual, and I = have a few initial comments to make: 1. I like your deferral codes. Good addition. Do you find Sentinel uses = such codes, or sees such types of outcome codes in the event repositories = that it dredges? 2. I see you've changed the format of the event code. This has to be done = with care because the bit pattern of the event code follows a formatting = specification in the preliminary spec: 6.10.2 Event Numbers An event number encodes the identification of an event set as well as the = identification of the unique event. A set of event numbers is assigned by the OpenGroup (upon = request) to an organization or a vendor. The organization or vendor then has the = authority to use event numbers within that set. Conceptually, each event number is a pair (set-id, event-id), where set-id = identifies an event set, and the event-id identifies an event within the event set. In practice, = each event number must have one of the formats illustrated in Figure 6-2 (on page 50). I don't know if you'll get the graphic on the mailing list, but since this = note is also sent to you privately, you should be able to see it. More later... John >>> On 4/11/2007 at 5:18 PM, in message <461...@no...>, = David Corlette <dco...@no...> wrote: Hi guys, I've incorporated some of my own thoughts along with some of Wayne's = comments to come up with some proposed changes to OpenXDAS. Since they = are somewhat extensive, I've edited the user guide with "Record Changes" = on. The changes fall into these categories: 1) Add instance IDs to the event structure, so we can track multiple = related events 2) Add "deferral" outcome codes 3) Add "workflow" event codes 4) Add role/group management events 5) Add some other miscellany Let me know what you think of all this, and if we can all come to some = sort of agreement I'd like to propose these for addition to the standard - = but I have no idea how to go about that.... |
From: Pat F. <PFE...@no...> - 2007-04-12 16:14:47
|
I agree John. Lets follow it the best we can but at this point we are the = WG. So if we need some changes lets just push them through into openXDAS = and just clean them up in the spec as we can. We can't wait for the WG. =20 Pat >>> On 4/12/2007 at 10:05 AM, in message <461...@no...>,= "John Calcote" <jca...@no...> wrote: There is - right now (at this moment) the standards body working group = doesn't exist any more. The way to get the change through, is to get the = working group back together and then suggest the change to them. While = this may seem complicated, we are in the process of working with the WG = through Alan Clark, our standards body liaison at Novell. He's working = with the Open Group's Ian Dobson - head of the OG Security Forum.=20 =20 The short of it is this: It's a bit of a long involved process - not that = we shouldn't do it, just that it takes time. If we have a really really = good reason for making a change, we probably should go ahead and make the = change, and document what we did and why we did it, for presentation at = the next (first) working group meeting. =20 My original tack on this project was to stick with the standard to the = degree that I could. There've been a few places where I simply had to = deviate because the spec was simply unimplementable - in these places, = I've documented carefully where I deviated and why. Most of these are in = the API, where the compiler would not allow me to do what they said I = should. :) After all, it IS just a preliminary specification. =20 List your desired changes, and let's discuss them on the developer mailing = list (adding to the distribution list). =20 John =20 ----- John Calcote (jca...@no...) Sr. Software Engineeer Novell, Inc. >>> On 4/12/2007 at 9:45 AM, in message <461...@no...>, = David Corlette <dco...@no...> wrote: Ah, OK, I see I've been wondering what belonged in what domain. What's the mechanism for suggesting changes? I thought you had said there = was some possibility for a rework? >>> On Thu, Apr 12, 2007 at 11:42 PM, in message <461DFEF0.37FF.0081.0@nove= ll.com>, John Calcote wrote:=20 > Anything related to the format of the record, the event taxonomy and = outcome=20 > codes, or the XDAS API (with minor exceptions), are defined by the = XDAS=20 > specification. I didn't define it that way, I just implemented it. > =20 > --john >=20 >>>> On 4/11/2007 at 5:37 PM, in message <461...@no...>,= David Corlette <dco...@no...> wrote: > Hi John, >=20 > BTW, is there any particular reason you chose the low byte to classify=20= > outcome events? It seems backwards to me, and prevents one from = doing=20 > something like: >=20 > if ($code > x && $code < y); then "This is a failure"; >=20 > Would you support flopping the low and high bytes and shifting down = the=20 > increments? >=20 > ---------------- > David Corlette > Senior Technical Consultant >=20 > Novell, Inc. > Secure Your Enterprise > Sentinel from Novell > http://www.novell.com/products/sentinel/ |
From: John C. <jca...@no...> - 2007-04-12 16:05:34
|
BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:John Calcote TEL;WORK:1-801-861-7517 ORG:;Unified Identity System Eng TE TEL;PREF;FAX:801/861-2292 EMAIL;WORK;PREF;NGW:JCA...@no... N:Calcote;John;;Sr. Software Engineer TITLE:Sr. Software Engineer ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:John Calcote=3D0A= =3D PRV-H-511=3D0A=3D Provo END:VCARD |
From: John C. <jca...@no...> - 2007-04-06 19:01:46
|
BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:John Calcote TEL;WORK:1-801-861-7517 ORG:;Unified Identity System Eng TE TEL;PREF;FAX:801/861-2292 EMAIL;WORK;PREF;NGW:JCA...@no... N:Calcote;John;;Sr. Software Engineer TITLE:Sr. Software Engineer ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:John Calcote=3D0A= =3D PRV-H-511=3D0A=3D Provo END:VCARD |
From: John C. <jca...@no...> - 2007-04-05 19:53:57
|
BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:John Calcote TEL;WORK:1-801-861-7517 ORG:;Unified Identity System Eng TE TEL;PREF;FAX:801/861-2292 EMAIL;WORK;PREF;NGW:JCA...@no... N:Calcote;John;;Sr. Software Engineer TITLE:Sr. Software Engineer ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:John Calcote=3D0A= =3D PRV-H-511=3D0A=3D Provo END:VCARD |
From: John C. <jca...@no...> - 2007-03-26 22:07:54
|
It's been pointed out to me (today in fact) that "make install" has been = broken on openxdas for local installations (configure --prefix=3D<something= besides />; make install). This is because the xdasd daemon was ignoring = the installation configuration and just using global default locations = (like /usr, /etc, and /var). =20 This problem has been remedied (thanks to a little help from Jaimon Jose). = The openxdas autotools build scripts now properly build an executable that = understands local installations. (svn revision 231 contains these fixes). =20 --john |
From: John C. <jca...@no...> - 2007-02-23 16:38:25
|
Good points - this is exactly the direction we started with. Ultimately, XDAS would like to provide a set of work flow events just like those you mention. --john >>> On Thu, Feb 22, 2007 at 7:34 PM, in message <45D...@no...>, "David Corlette" <dco...@no...> wrote: Hello all, While we're talking about extensions to OpenXDAS, what's the history of discussions around IDM workflow? For example, I imagine that in any enterprise that cares about e.g. SOX compliance, they would want to see a chain of events like: Account Create Request Account Create Approval Account Create My sense is that OpenXDAS currently handles only the last one. Has there been talk about adding the others? Are any IDM folks part of this community? ---------------- David Corlette Senior Technical Consultant DCo...@no... 703.663.5517 Novell, Inc. Novell BrainShare 2007 This is Your Open Enterprise Register at http://www.novell.com/brainshare ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ openxdas-devel mailing list ope...@li... https://lists.sourceforge.net/lists/listinfo/openxdas-devel |
From: David C. <dco...@no...> - 2007-02-23 02:34:33
|
Hello all, While we're talking about extensions to OpenXDAS, what's the history of discussions around IDM workflow? For example, I imagine that in any enterprise that cares about e.g. SOX compliance, they would want to see a chain of events like: Account Create Request Account Create Approval Account Create My sense is that OpenXDAS currently handles only the last one. Has there been talk about adding the others? Are any IDM folks part of this community? ---------------- David Corlette Senior Technical Consultant DCo...@no... 703.663.5517 Novell, Inc. Novell BrainShare 2007 This is Your Open Enterprise Register at http://www.novell.com/brainshare |
From: Pat F. <PFE...@no...> - 2007-02-21 02:48:36
|
Other aspects of the Bandit project are common identity and authorization. Common identity is normalizing what an identity is and how to exchange this information. The authorization aspects relates to the Bandit Role Engine were XACML policy is used to represent what roles a common identity is in. XACML can also be used to represent permissions. However, when it comes to roles or permission, what exactly an identity can do is application specific, like John was saying. Without a common taxonomy for identity and roles or permissions it is very difficult to represent identities across applications and what that identity can do. If we can achieve a common taxonomy for representing identities and its roles or permissions within a specific domain then we could provide proper mapping to the XDAS taxonomy, however, this introduces issues with allowing an outside system to view what roles or permissions a specific identity has in a specific application. So basically what does the ADMIN role mean? To some applications one thing and to others another. What we really need is at a certain time, within a specific domain an identity and its roles or permissions mapped to the XDAS taxonomy. For now the data that is important is: Timestamp: time of event domain: eDirectory version X: XYZ Tree, XYZ Server user: cn=admin, o=novell role: some groupmembership XDAS can't tell if its an admin identity, but eDirectory could. Thoughts? Pat >>> On 2/20/2007 at 5:51 PM, in message <45D...@no...>, "David Corlette" <dco...@no...> wrote: Thanks for your comments, John. > 2) XDAS_AE_CREATE_ADMIN_SESSION - I'm not sure I do agree with the need for > a special case here. I suppose the reason I say this is primarily due to the > fact that I worked so long on the eDirectory team. In directories, there is > really no special account called "admin", "root", or "Administrator". Often, > there is an account called "admin", but this account is not special in any > specific way, other than that it happens to have most or all rights to a node > at the top of the tree, and these rights are not generally masked off below > that node. In other words, on some systems, it's very difficult to tell if an > "admin" user is being modified - because it's difficult to tell which > accounts are "admin" accounts. Although I definitely see your point, I also feel that there are many systems that have a concept of a "privileged user" or some sort of "privileged mode" - e.g. root accounts, Administrator under Windows, etc. In fact, under these OSs there are special commands to allow you to "su" to that user account; there's also single-user mode, which is special in many ways. And don't forget SUPERVISOR under Netware! But you're right, it may come down to local policy as to what a "privileged" account actually is - at one big customer all sysadmins have a regular account (dcorlette) and a Domain Admin account (zzdcorlette). So perhaps it is more the responsibility of the interpreter to determine who is privileged and who is not. As I mentioned, my thought was that there could be a flag that indicates "this account is somehow special", but this could be set by some receiving system rather than the low-level audit tool, perhaps just by matching against a list of accounts. Are there others that choose to comment? ---------------- David Corlette Senior Technical Consultant DCo...@no... 703.663.5517 Novell, Inc. Novell BrainShare 2007 This is Your Open Enterprise Register at http://www.novell.com/brainshare ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ openxdas-devel mailing list ope...@li... https://lists.sourceforge.net/lists/listinfo/openxdas-devel |
From: David C. <dco...@no...> - 2007-02-21 00:51:43
|
Thanks for your comments, John. > 2) XDAS_AE_CREATE_ADMIN_SESSION - I'm not sure I do agree with the need for > a special case here. I suppose the reason I say this is primarily due to the > fact that I worked so long on the eDirectory team. In directories, there is > really no special account called "admin", "root", or "Administrator". Often, > there is an account called "admin", but this account is not special in any > specific way, other than that it happens to have most or all rights to a node > at the top of the tree, and these rights are not generally masked off below > that node. In other words, on some systems, it's very difficult to tell if an > "admin" user is being modified - because it's difficult to tell which > accounts are "admin" accounts. Although I definitely see your point, I also feel that there are many systems that have a concept of a "privileged user" or some sort of "privileged mode" - e.g. root accounts, Administrator under Windows, etc. In fact, under these OSs there are special commands to allow you to "su" to that user account; there's also single-user mode, which is special in many ways. And don't forget SUPERVISOR under Netware! But you're right, it may come down to local policy as to what a "privileged" account actually is - at one big customer all sysadmins have a regular account (dcorlette) and a Domain Admin account (zzdcorlette). So perhaps it is more the responsibility of the interpreter to determine who is privileged and who is not. As I mentioned, my thought was that there could be a flag that indicates "this account is somehow special", but this could be set by some receiving system rather than the low-level audit tool, perhaps just by matching against a list of accounts. Are there others that choose to comment? ---------------- David Corlette Senior Technical Consultant DCo...@no... 703.663.5517 Novell, Inc. Novell BrainShare 2007 This is Your Open Enterprise Register at http://www.novell.com/brainshare |
From: John C. <jca...@no...> - 2007-02-20 20:41:17
|
BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:John Calcote TEL;WORK:1-801-861-7517 ORG:;Unified Identity System Eng TE TEL;PREF;FAX:801/861-2292 EMAIL;WORK;PREF;NGW:JCA...@no... N:Calcote;John;;Sr. Software Engineer TITLE:Sr. Software Engineer ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:John Calcote=3D0A= =3D PRV-H-511=3D0A=3D Provo END:VCARD |
From: John C. <jca...@no...> - 2007-02-20 19:40:37
|
BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:John Calcote TEL;WORK:1-801-861-7517 ORG:;Unified Identity System Eng TE TEL;PREF;FAX:801/861-2292 EMAIL;WORK;PREF;NGW:JCA...@no... N:Calcote;John;;Sr. Software Engineer TITLE:Sr. Software Engineer ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:John Calcote=3D0A= =3D PRV-H-511=3D0A=3D Provo END:VCARD |
From: David C. <dco...@no...> - 2007-02-19 16:00:38
|
Hello all, In the OpenXDAS user manual, it talks about submitting possible extensions to the existing taxonomy. It's not real clear on how to do this, but I figure this is a pretty good place to start. I recently faced the problem of mapping events generated by operating systems, databases, and applications into the OpenXDAS schema (sort of). I felt needed to extend the schema in the following ways: 1) Added XDAS_AE_SETPASS_ACCOUNT - to me, an account password should be treated as a special attribute, and deserves its own slot. Thoughts? 2) Added XDAS_AE_CREATE_ADMIN_SESSION (and similar for all SESSION-type codes) - again, the administrative (root, Administrator) accounts probably should be called out for special treatment, although this may be specific to the application I'm working with - I'm basically setting an "ADMIN" flag rather than creating a whole new code. 3) Added XDAS_AE_ROLE_CREATE (and so on) - here I'm using ROLE to refer to things like groups, roles, and containers in a directory - e.g. things that can have rights associated with them and be associated with accounts (or vice versa, maybe), but are not properly accounts themselves. 4) Added XDAS_AE_START_AUDIT_SYS (same for SHUTDOWN) - In databases at least, you can start and stop the AUDIT system itself - this could probably be just the generic START_SYS, but I felt that since we're dealing with Audit apps here this could be treated specially. I'd appreciate any and all thoughts regarding the extensions I made above - do you feel they might be necessary, would you map them differently, etc etc. Thanks! ---------------- David Corlette Senior Technical Consultant DCo...@no... 703.663.5517 Novell, Inc. Novell BrainShare 2007 This is Your Open Enterprise Register at http://www.novell.com/brainshare |
From: David C. <dco...@no...> - 2007-02-19 15:49:16
|
Hello all, We are working on event taxonomy for IDS devices (Intrusion Detection Systems). I have become somewhat familiar with the OpenXDAS spec for events over the last week or so, as I am trying to push our developers towards using that as their standard. IDSs present a set of problems which don't seem to map well to the standard OpenXDAS taxonomy. Obviously any *internal* IDS events work fine -user logins, config change, etc - but *external* events do not (and yet they are definitely security events). To me, this can be solved by extending some of the existing ideas, e.g. alongside: XDAS_AE_CREATE_SESSION we have XDAS_AE_ATTACK_SESSION Or some such. What are your thoughts on this sort of thing, where a system observes activity that is: 1) External to that system (traffic between two other systems) 2) The outcome is unknown 3) The "category" of attack is probably important, e.g. is it a buffer overflow, trojan, worm, etc Do you think this can naturally be worked into the XDAS taxonomy, or no? ---------------- David Corlette Senior Technical Consultant DCo...@no... 703.663.5517 Novell, Inc. Novell BrainShare 2007 This is Your Open Enterprise Register at http://www.novell.com/brainshare |
From: John C. <jca...@no...> - 2006-11-28 19:28:37
|
Everyone, It's recently come to my attention that the OpenXDAS .msi installer package for windows depends on the Visual C++ 8 C-language runtime library - part of the so-called redistributable package provided by Microsoft for programs built using Visual Studio 2005 (VC8). The reason I didn't notice this earlier is that these runtime libraries are already installed on machines where the development environment is installed (including all of my development machines). It wasn't until a user without visual studio tried to install the openxdas msi and found the service wouldn't launch that I became aware of this issue. In response, I've published a self-contained executable installer called vcredist_x86.exe as part of the OpenXDAS downloadable package set on sourceforge.net. Please download both vcredist_x86.exe and the current openxdas msi installer, then run the vcredist package first before attempting to install the msi package. We'll integrate the vc8 redistributable package with the openxdas msi installer in a future release. Thanks for your patience, John ----- John Calcote (jca...@no...) Sr. Software Engineeer Novell, Inc. |
From: Dale O. <do...@no...> - 2006-10-13 16:40:38
|
Hi John, I finally got around to checking out the openxdas code today -- nice clean site, nicely structured code, documentation, great stuff! -- but I do have one nit about this page: http://openxdas.sourceforge.net/source_code.html The anon SVN access didn't work using the example command line. First, it must be https, not http. Then if svn.sf.net is the host name the SSL certificate doesn't match and you get a warning. This works fine: svn co https://svn.sourceforge.net/svnroot/openxdas/trunk openxdas I suspect the developer command line has the same problem. --Dale |
From: John C. <jca...@no...> - 2006-10-11 18:49:00
|
Daniel Sanders and I were adding some code to the xdasd server this morning in preparation for testing the Java client, and he noticed that when the daemon was started, his linux box would switch into high gear (hard disk activity, processor fan, etc - everything got noisy all of a sudden). We ran top and noticed that xdasd was at 99 percent processor utilization. The short story is that after debugging the problem, we discovered that the select timeout was initialized to two seconds outside the run loop, and then the first call to select was clearing it to zero. So every time thereafter select was returning immediately. We moved the initialization of the timeval structure to inside the while loop and the processor utilization returned to normal (xdasd wasn't even in the top list!). I'm putting out a new release to fix this issue - it'll probably be 0.2.122 or so - depending on how many minor check-ins I have to do to get the packages all built correctly. Just thought you might find this interesting... John |