openxdas-devel Mailing List for OpenXDAS - Distributed Auditing Service
Brought to you by:
dsandersorem,
jcalcote
Menu
▾
▴
openxdas-devel — Developer discussions regarding OpenXDAS
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: John C. <joh...@gm...> - 2009-08-21 05:45:03
|
I'm pleased to announce the release of version 0.8.351 of the OpenXDAS auditing project. Please see the SourceForge.net site to download the latest source and binary archives: http://sourceforge.net/projects/openxdas And check the web site for information on this latest release: http://openxdas.sourceforge.net This version contains the following new features: * Implemented import API in preparation for platform import agents! * Removed arbitrary 4k limit on store-and-forward cache message size. * Modified the test program to understand a command line argument as a file containing log lines. The test program scans the file for lines output by xdasd during event parsing. These lines contain complete XDAS log-line formatted events. These are then fed back into xdasd via the import API, allowing defective log lines to be tested and debugged. * Added modifications to openxdas.spec file to allow openxdas to be built properly on older Linux distros such as SLES 10. Removed all Java 1.5 dependencies from code base by targeting 1.4 for both source and class files. Enjoy! |
|
From: John C. <joh...@gm...> - 2009-08-05 20:27:02
|
Everyone,
I'm happy to announce the release of OpenXDAS version 0.8.345.
This version contains a couple of bug fixes in the Java and C clients
related to timezone string formatting and escaping in the XDAS record
header.
The defect caused unescaped strings to be generated into the timezone
field of the XDAS record header. The fixes also allow the timezone
string to be generated more accurately now (as per the OpenGroup Single
Unix Specification).
Additionally, we've added debug logging code, and some instrumentation
to log inbound unparsed and parsed messages to the xdasd service.
Additional debug log instrumentation will be added over time. For now,
if you're interested in seeing more verbose xdasd.log information, try
adding "-e 15" to the xdasd command line, or set the XDASD_LOG_LEVEL
environment variable to 15. You can use any value between 0 and MAX_INT
(zero is the default value), but currently the code is only instrumented
to level 15, with instrumentation at levels 1, 2, 10 and 15.
(NOTE: Please don't leave debug logging on. It will fill up your
xdasd.log file with useless garbage if you're not interested in
collecting that information for debugging purposes.)
Check out the new version on the openxdas web site:
http://openxdas.sourceforge.net/downloads.html
Check out the sourceforge project site at:
http://sourceforge.net/projects/openxdas
Enjoy!
John
|
|
From: John C. <joh...@gm...> - 2009-07-30 03:59:01
|
I'm happy to announce the release of version 0.8.333 of the OpenXDAS project. This version has several key Java client library enhancements, plus others: 1. The Java client library has been upgraded to use Java NIO from raw sockets. This gives the Java client the ability to write native I/O buffers directly to underlying OS sockets. The result is a much faster Java client. 2. We've fixed a long-standing bug in the Java client wherein UTF-8 strings were not getting processed correctly when using extended character set strings such as those found in languages like Chinese and Japanese. 3. We've added a doc package to the rpm build. 4. We've enhanced the build system in minor ways. Please visit the OpenXDAS web site at http://openxdas.sourceforge.net for more information. The files may be downloaded from the project web site on sourceforge.net at http://sourceforge.net/projects/openxdas. Future enhancements include the addition of platform agents to capture system events and route them through the xdasd service. Watch for this major feature in a soon-to-be-released version of OpenXDAS. Enjoy! John |
|
From: John C. <joh...@gm...> - 2009-07-08 06:40:24
|
I'm pleased to announce the release of OpenXDAS version 0.7.320. Due to a massive upgrade to sourceforge.net that took place on July 1, 2009, there are several U/I defects in the sf.net project page for OpenXDAS (and many other projects). The version that is displayed for download on the summary page is the 0.6.294 version, but this is NOT the latest. For quality download links, please visit the openxdas web site download page at: http://openxdas.sourceforge.net/downloads.html Well, with each new release, we're that much closer to a functionally complete 1.0 release of the reference XDAS v1.0 specification. In this new release, we've done the following: * We've finished the netstream logger's SSL/TLS functionality. You can now configure (on both Windows and Unix platforms) the netstream logger to use an SSL/TLS connection to a log server. You can optionally configure server and client authentication, as well as a desired cipher suite. For details, see the updated documentation for the netstream logger, which can be found in the newly released 0.7.320 version of the openxdas user and developer document. Detailed instructions are also provided for generating keys and certificates. * We've also fixed a few defects that some of our newer users found in the filter trigger code. (Thanks Domenico!) * We've added code to the C and Java client libraries to convert all control characters to spaces in XDAS field strings passed into the client interface. Control characters are not allowed in XDAS v1.0 input strings, as they cause wrapping issues, etc. * We've enhanced the Unix build system a bit. The eXpat library was not being strictly required in configure.ac, so systems without eXpat or eXpat-devel installed would fail in make, rather than configure. * Finally, we've converted the Visual Studio project and solutions files from VS 2008 to VS 2005 for compatibility with that older version. This shouldn't cause anyone problems, as VS 2008 will upgrade these older solution and project files automatically when they're opened in VS 2008. This allows our VS 2005 users to play also. _*Still to be done:*_ Please note that the code is extremely clean, due to good integrated unit tests. The reason for the pre-1.0 version number is simply that we're still short a few features. The features we're still considering before 1.0 are: * Import agents for (at least) Linux/Unix and Windows. * The management API needs to be finished. We need to complete implementation for the filter management portion of the XDAS API. As usually, please send feedback to the openxdas-devel or openxdas-users mailing lists. Enjoy! John |
|
From: David C. <DCo...@no...> - 2009-03-03 02:11:36
|
Hi Pascal, I might be wrong, but I was under the impression that the openxdas library had some sample clients and such. On the other hand, you should know that we are hard at work on the next rev to XDAS, so you might want to hold off until that's done. One of the list members has already written a sample log4x appender that might meet your needs, for example, but until the standard is complete it might not be appropriate to use it. >>> On 27.02.2009 at 14:07, in message <49A...@si...>, "Pascal Vantrepote" <Pas...@no...> wrote: > Hi, > > I am working on an integration server and I need an audit solution. > I am trying to setup a server and just write a simple client application > without success. > > Does anybody knows where to find a sample Java client and a sample server > configuration file? > > Thanks > Pascal. |
|
From: Pascal V. <Pas...@no...> - 2009-02-27 19:07:22
|
Hi, I am working on an integration server and I need an audit solution. I am trying to setup a server and just write a simple client application without success. Does anybody knows where to find a sample Java client and a sample server configuration file? Thanks Pascal. |
|
From: John C. <joh...@gm...> - 2009-02-26 22:41:39
|
Joël, I just wanted to make sure that you are aware of the existing openxdas java code base. Please examine the openxdas/java directory in the openxdas SVN repository. This directory currently houses an existing xdas 1.0-like java interface (full client, actually), and a log4j appender (trivial implementation). I dont think its wise to have multiple implementations of xdas java interfaces and log4j appenders. I would very much appreciate it if you would take whatever concepts from ours that seem worthy to you, and add them to your implementations. Once you feel as though your code base is at least on the same functional level as the existing openxdas java code, then I would like to deprecate our versions in favor of yours. Please note that its not really critical that you maintain interface compatibility with the existing java xdas client. The interface more or less falls out of the spec, so I presume that youll have something LIKE what we have, but binary compatibility is not an issue. We simply dont have that many customers yet. J Regards, John |
|
From: John C. <jca...@no...> - 2008-07-30 17:46:12
|
David,
I've been thinking about what to do with openxdas relative to the future XDAS 2.0 specification.
As we've discussed in the past, XDAS 2.0 will probably NOT specify any API's. I believe this is a good move, but it makes it more difficult in some ways, and yet simpler in other ways to implement a library to the new spec.
It's simpler because there's much less standard to implement. That is, implementing the standard is simpler.
It's more difficult because the openxdas maintainer now has to do the work of coming up with a reasonable API, where "reasonable" is very subjective.
Regardless, I still think removing the API from the standard is the right approach. Focusing on the record format and taxonomy is much more important for a modern auditing standard.
Here are my thoughts on the OpenXDAS 2.0 code base:
1. Provide client libraries that are both statically and dynamically linkable.
2. Break the client library into at least two parts:
A. A library that accepts audit data and returns a well-formatted XDAS record.
B. An optional library that accepts an XDAS record, and submits to the OpenXDAS service.
3. Provide an optional auditing service.
OpenXDAS will then define "reasonable" C, C-Sharp and Java language bindings within the client libraries - both the record creation library and the submission library. Neither client library will depend on the other.
The submission library will have to perform well-formedness checks on records before submitting them. While this increases overhead a bit on the client side, I believe the benefits of a split client library outweigh the increase in overhead. Furthermore, since the client-side will now be managing such checks, the back-end code for such checks can be removed (or at least reduced).
Users of OpenXDAS 2.0 will have the option of using just the formatter library, and submitting records in their own way - perhaps simply write them to a local file, the syslog system, or the Windows event manager.
Users will also have the option of submitting the record to the OpenXDAS service submission library, which will communicate with the more functional OpenXDAS back-end service. The back-end service will do the same thing it's always done: provide a pluggable logger framework, and submit all unfiltered events to each of the configured back-end loggers.
I believe the separation of client duties between two separate libraries - a formatter and a submitter - will make most people happy, and provide a set of code that is most usable by most people.
Comments?
Regards,
John
|
|
From: John C. <joh...@gm...> - 2008-05-29 17:55:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Everyone, I'm happy to announce that version 0.6.294 of the OpenXDAS project has been released today. This version includes the following changes: * An enhanced netstream logger, that has the beginnings of SSL code in order to handle encrypted data streams. While this change doesn't affect users directly, it does show our direction with the netstream logger. The next release will have full encryption. * Documentation has been enhanced for this release. * The Win32 side of the system logger has been much enhanced to properly submit the XDAS record as the text log entry, rather than the associated binary data, as has been done in previous releases. This should make auto-parsers much happier with XDAS records found in the the Win32 event logs. * The java client class is now in the correct name space. * Both the C and Java clients now support the extended OpenXDAS events (currently being added to the new XDAS standard as part of the Update-XDAS initiative sponsored by Novell and the Open Group Security Forum. These events include authentication material modification, workflow and role management events. * We're now taking full advantage of the OpenSuSE Build Service (OBS) at http://software.opensuse.org/search Enter "openxdas" in the search dialog and select your desired platform, or select "all" to find out which platforms are currently available. We're working every day to get new platforms added, so don't be discouraged if you don't find your's in the list. Where to get it... ================== Please visit the openxdas web site download and documentation pages at http://openxdas.sourceforge.net/download.html http://openxdas.sourceforge.net/documentation.html to find links for downloading this new version and it's associated documentation. Enjoy! John -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIPu6OdcgqmRY/OH8RAma6AKCX0gI/lvMUNHmDQSJ4is4/kJgu9gCbBThI 5eQ8ZHfNfXvnSTMwJUcL/ns= =S1UN -----END PGP SIGNATURE----- |
|
From: Wayne H. <wh...@no...> - 2007-08-15 20:49:05
|
All, I checked in a log4J appender to the OpenXDAS project. It was used in IDM = User Application to insulate developers from the low level details of = getting audit events routed. Developers can send audit event to OpenXDAS = through the popular log4j API and also take advantage of other log4j = features. For example, the auditing output can be configured to go to the = console, and/or OpenXDAS client by editing the log4j configuration file. Hopefully this can be leveraged by other community members of the OpenXDAS = project. Regards, Wayne Hsu Senior Software Engineer, eXtend Engineering (703) 967-4980 |
|
From: John C. <jca...@no...> - 2007-05-01 16:17:45
|
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: Wayne H. <wh...@no...> - 2007-04-27 18:38:56
|
Thanks David for your quick response. It makes sense. The term "Location" confused me. John, can you confirm David's comment? Now let me ask another question: I understand that OpenXDAS only uses generic event number like XDAS_AE_MODIFY_DATA_ITEM_ATT but from application's perspective many differnt events could use that same one. For example, application updates a column in a database table or an entity in eDirectory uses the same event number, XDAS_AE_MODIFY_DATA_ITEM_ATT. How could the Analysis softwre distinguish between these two events? I know that we could store this information in the EVT section, but it seems to me this information is important enough to warrant a field in the header section. It would be quite useful if it also conforms to the OpenXDAS name. For example, I could call this field component and stores "IDM/UserApp/Entity/DeleteEntity" in there. In this way, I can create many useful reports based on the hierarchy. Wayne Hsu Senior Software Engineer, eXtend Engineering (703) 967-4980 Novell, Inc., the leading provider of Net Business Solutions. www.novell.com >>> David Corlette 04/27/07 1:31 PM >>> Hi Wayne, I've included what I think below: >>> On Fri, Apr 27, 2007 at 1:06 PM, Wayne Hsu wrote: > An IDM User application runs in a Linux server but the user identity is > stored and authenticated through eDirectory in another Linux server. One > event is generated when the administrator whose DN in eDirectory is > “cn=admin,ou=idmsample,o=novell” changed the password of a user “whsu” whose > DN is “cn=whsu,ou=idmsample,o=novell”. Let’s say user “whsu” is the target. > What will be the data being stored in those target fields? I filled up the > XDAS fields with the following data based on my understanding of the field > definition. As you can see, I am missing the most important data: the name of > the user whose password has been changed. Also, can we say that user whsu is > located in the <host name>/IdmUserApp but is authenticated by the <host > name>/eDirectory? > > Event Number: XDAS_AE_MODIFY_AUTH_TOKEN > Initiator Authentication Authority: <host name>/eDirectory > Initiator Domain-Specific Name: cn=admin,ou=idmsample,o=novell > Initiator Domain-Specific ID: cn=admin,ou=idmsample,o=novell > Target Location Name: <host name>/eDirectory > Target location address: url to the eDirectory > Target Service Type: ldap > Target Authentication Authority: host name>/eDirectory > Target Princial Name: don’t know (User name under which eDirectory is > running) No, I think the target in this case is the user, not eDirectory. So I would put the username in this field. I imagine there will actually be a couple events generated here, one by the User App and one when eDir receives the password change (the attempt and the result, so to speak). > Target Principal ID: don’t know (User ID under which app server is running) > I also have the following questions: > > 1. What’s the value of Target Princial Name/ID? In most cases, we don’t know > or care about that information. That's why I think in this case the target is the username. > 2. Like wise, what’s the value of the Originator/Initiator/TargetPrincipal > ID? Can’t the Original/Initiator/TargetPrincipal Name be enough? In most > cases, we don’t know or care about the ID. I know we can hard-code root ID to > 0, but what's the value of it? For user other than root, it is difficult to > obtain the ID without the administor privilege in the authentication service. I somewhat agree, but in some cases events I have seen include both pieces of information. Also consider the case where the target is a network port - in this case the name/ID of the port can be trivially retrieved from the services file. HTH |
|
From: David C. <dco...@no...> - 2007-04-27 17:32:00
|
Hi Wayne, I've included what I think below: >>> On Fri, Apr 27, 2007 at 1:06 PM, Wayne Hsu wrote:=20 > An IDM User application runs in a Linux server but the user identity = is=20 > stored and authenticated through eDirectory in another Linux server. = One=20 > event is generated when the administrator whose DN in eDirectory is=20 > *cn=3Dadmin,ou=3Didmsample,o=3Dnovell* changed the password of a user = *whsu* whose=20 > DN is *cn=3Dwhsu,ou=3Didmsample,o=3Dnovell*. Let*s say user *whsu* is = the target.=20 > What will be the data being stored in those target fields? I filled up = the=20 > XDAS fields with the following data based on my understanding of the = field=20 > definition. As you can see, I am missing the most important data: the = name of=20 > the user whose password has been changed. Also, can we say that user = whsu is=20 > located in the <host name>/IdmUserApp but is authenticated by the = <host=20 > name>/eDirectory? >=20 > Event Number: XDAS_AE_MODIFY_AUTH_TOKEN > Initiator Authentication Authority: <host name>/eDirectory > Initiator Domain-Specific Name: cn=3Dadmin,ou=3Didmsample,o=3Dnovell > Initiator Domain-Specific ID: cn=3Dadmin,ou=3Didmsample,o=3Dnovell > Target Location Name: <host name>/eDirectory > Target location address: url to the eDirectory > Target Service Type: ldap > Target Authentication Authority: host name>/eDirectory > Target Princial Name: don*t know (User name under which eDirectory = is=20 > running) No, I think the target in this case is the user, not eDirectory. So I = would put the username in this field. I imagine there will actually be a = couple events generated here, one by the User App and one when eDir = receives the password change (the attempt and the result, so to speak). > Target Principal ID: don*t know (User ID under which app server is = running) > I also have the following questions: >=20 > 1. What*s the value of Target Princial Name/ID? In most cases, we = don*t know=20 > or care about that information.=20 That's why I think in this case the target is the username. > 2. Like wise, what*s the value of the Originator/Initiator/TargetPrinc= ipal=20 > ID? Can*t the Original/Initiator/TargetPrincipal Name be enough? In = most=20 > cases, we don*t know or care about the ID. I know we can hard-code root = ID to=20 > 0, but what's the value of it? For user other than root, it is difficult = to=20 > obtain the ID without the administor privilege in the authentication = service.=20 I somewhat agree, but in some cases events I have seen include both pieces = of information. Also consider the case where the target is a network port = - in this case the name/ID of the port can be trivially retrieved from the = services file. HTH |
|
From: Wayne H. <wh...@no...> - 2007-04-27 17:06:25
|
Hi John, I have questions regarding where to put data in the respective Target fields. Specifically, I don’t know where to store the “name” of the target. Let me give you an example: An IDM User application runs in a Linux server but the user identity is stored and authenticated through eDirectory in another Linux server. One event is generated when the administrator whose DN in eDirectory is “cn=admin,ou=idmsample,o=novell” changed the password of a user “whsu” whose DN is “cn=whsu,ou=idmsample,o=novell”. Let’s say user “whsu” is the target. What will be the data being stored in those target fields? I filled up the XDAS fields with the following data based on my understanding of the field definition. As you can see, I am missing the most important data: the name of the user whose password has been changed. Also, can we say that user whsu is located in the <host name>/IdmUserApp but is authenticated by the <host name>/eDirectory? Event Number: XDAS_AE_MODIFY_AUTH_TOKEN Initiator Authentication Authority: <host name>/eDirectory Initiator Domain-Specific Name: cn=admin,ou=idmsample,o=novell Initiator Domain-Specific ID: cn=admin,ou=idmsample,o=novell Target Location Name: <host name>/eDirectory Target location address: url to the eDirectory Target Service Type: ldap Target Authentication Authority: host name>/eDirectory Target Princial Name: don’t know (User name under which eDirectory is running) Target Principal ID: don’t know (User ID under which app server is running) I also have the following questions: 1. What’s the value of Target Princial Name/ID? In most cases, we don’t know or care about that information. 2. Like wise, what’s the value of the Originator/Initiator/TargetPrincipal ID? Can’t the Original/Initiator/TargetPrincipal Name be enough? In most cases, we don’t know or care about the ID. I know we can hard-code root ID to 0, but what's the value of it? For user other than root, it is difficult to obtain the ID without the administor privilege in the authentication service. Wayne Hsu Senior Software Engineer, eXtend Engineering (703) 967-4980 Novell, Inc., the leading provider of Net Business Solutions. www.novell.com >>> "John Calcote" <jca...@no...> 04/21/07 1:15 PM >>> Dave, I'd say that the Admins group is the target - really it depends on the kind of event that the "originator" is generating. The initial event in this event chain is an account (user or group) modification event. For the account modification event, the initiator is definitely Joe, as he is the user attempting to perform the account modification, but the system recording the event is the originator, and that system is probably the one doing the modification to the user/group database - usually a Unix box, or a Windows domain server. The object being modified is the target - the Admins group in this case. The user Dave is the data being added to the Admins group, so it technically doesn't have a formal place in the event, except that it's fairly important data, so it should be in the record somewhere. This sort of data goes into the event data field as a specific name/value pair. Event data (or edata) is a place to store information that is important and relevant, but not critically defined for the XDAS event format. Regarding peer associations - these were intended originally (per page 25 of the XDAS spec) to manage communication channels between peers, not user/group database associations. The modification of user/group database attributes belongs to the set of events called "Account management events" (page 23). What we really should do if we want to specify the association of users to groups more formally is to enhance this set of events (Account Management) to incorporate such a specific event. The original taxonomy is so generic that the best you can do is indicate that a specific group (target) has been modified by a specific user (initiator). John >>> On 4/20/2007 at 3:26 AM, i<462...@no...>, "David Corlette" <dco...@no...> wrote: Hi all, I just realized that I don't know how to specify peer association events in XDAS. I feel like the person making the association (e.g. the person logged in and editing the directory) is the initiator; but where do the two objects being associated go? Let's say: "User joe adds user dave to group Admins" So, Initiator is probably 'joe', but where do 'dave' and 'Admins' go? Which one (if any) is the target? Opinions? ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ openxdas-devel mailing list ope...@li... https://lists.sourceforge.net/lists/listinfo/openxdas-devel |
|
From: John C. <jca...@no...> - 2007-04-21 17:15:15
|
Dave, =20 I'd say that the Admins group is the target - really it depends on the = kind of event that the "originator" is generating. The initial event in = this event chain is an account (user or group) modification event. =20 For the account modification event, the initiator is definitely Joe, as he = is the user attempting to perform the account modification, but the system = recording the event is the originator, and that system is probably the one = doing the modification to the user/group database - usually a Unix box, or = a Windows domain server. The object being modified is the target - the = Admins group in this case.=20 =20 The user Dave is the data being added to the Admins group, so it technicall= y doesn't have a formal place in the event, except that it's fairly = important data, so it should be in the record somewhere. This sort of data = goes into the event data field as a specific name/value pair. Event data = (or edata) is a place to store information that is important and relevant, = but not critically defined for the XDAS event format. =20 Regarding peer associations - these were intended originally (per page 25 = of the XDAS spec) to manage communication channels between peers, not = user/group database associations. The modification of user/group database = attributes belongs to the set of events called "Account management events" = (page 23). What we really should do if we want to specify the association = of users to groups more formally is to enhance this set of events (Account = Management) to incorporate such a specific event. The original taxonomy is = so generic that the best you can do is indicate that a specific group = (target) has been modified by a specific user (initiator). =20 John >>> On 4/20/2007 at 3:26 AM, in message <462...@no...>, = "David Corlette" <dco...@no...> wrote: Hi all, I just realized that I don't know how to specify peer association events = in XDAS. I feel like the person making the association (e.g. the person = logged in and editing the directory) is the initiator; but where do the = two objects being associated go? Let's say: "User joe adds user dave to group Admins" So, Initiator is probably 'joe', but where do 'dave' and 'Admins' go? = Which one (if any) is the target? Opinions? ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/=20 _______________________________________________ openxdas-devel mailing list ope...@li...=20 https://lists.sourceforge.net/lists/listinfo/openxdas-devel |
|
From: David C. <dco...@no...> - 2007-04-20 09:26:36
|
Hi all, I just realized that I don't know how to specify peer association events in XDAS. I feel like the person making the association (e.g. the person logged in and editing the directory) is the initiator; but where do the two objects being associated go? Let's say: "User joe adds user dave to group Admins" So, Initiator is probably 'joe', but where do 'dave' and 'Admins' go? Which one (if any) is the target? Opinions? |
|
From: John C. <jca...@no...> - 2007-04-20 04:38:48
|
Also, my original thought here was that it's very convenient to have a = fixed number of fields in the record. By using a single field for = correlation data, but allowing an open number of name=3Dvalue pairs in = this field, we can allow the field count to be fixed, but allow extensible = correlation data. I believe this was the original intent behind making the = event data field a free-form name=3Dvalue pair field. It allows flexibility= where it's required, but still provides for a fixed number of fields in = the event record. =20 --john >>> On 4/19/2007 at 12:01 PM, in message <46275A320200004C000132C0@lucius.p= rovo.novell.com>, "Wayne Hsu" <wh...@no...> wrote: Although having comma separated <idname>=3D<idvalue> pairs in the = correlation id field is more flexible, it adds complexity when parsing or = analyzing the data. I suspect one string value for the correlation id will = be fine for most of the applications. In a database's term, every record = has only one primary key that serves to correlate the records within = tables, even though there may be other unique keys that identifies the = same record. Application can create a compound correlation id with the = xdas naming format or store other unique keys in the EVT section for this = type of scenario. They can even stores the <idname>=3D<idvalue> pairs. My = point is not to impose any rule on this field.=20 In the database logger, this will make querying the data tables easier. = For example, if I want to find a series of actions of a perticular = workflow request, I can just do "select * from table_name where correlation= _id =3D '<request_id_value>'. A free form, <idname>=3D<idvalue> pairs in the correlation if field will = make this type of query harder to write. Wayne Hsu Senior Software Engineer, eXtend Engineering (703) 967-4980 Novell, Inc., the leading provider of Net Business Solutions. www.novell.com=20 >>> "David Corlette" <dco...@no...> 04/19/07 12:38 PM >>> Hi Wayne, Yes, that's fine, but mostly I'm curious what kind of event interrelationsh= ips people expect to see. This in part is because on the backend Sentinel = would split the data off into separate fields for easy filtering, most = likely. >>> On Thu, Apr 19, 2007 at 10:01 PM, Wayne Hsu wrote:=20 > Are we confined to these names for the Correlation only? I thought the = field=20 > is extensible, therefore, instrumenation application can use whatever = names=20 > that make sense within its domain, be it sessionid or auid, as long as = it=20 > follows the name=3Dvalue format. >=20 > Wayne Hsu > Senior Software Engineer, > eXtend Engineering > (703) 967-4980 > Novell, Inc., the leading provider of Net Business Solutions. > www.novell.com=20 >=20 >=20 >>>> "David Corlette" <dco...@no...> 04/13/07 7:43 PM >>> > John, >=20 > I agree with what you are saying, exactly. Correlation has a slightly=20= > broader meaning in the context of Sentinel, but the use of that word = here -=20 > e.g. to help us correlate between several related events - is perfect. >=20 > As for the field format, that also works for me. >=20 > So far we seem to have come up with: > sessionid > processid > threadid > requestid >=20 > I notice that the LAF (SuSE Linux audit framework) uses "auid" - but=20 > perhaps this could be considered a "sessionid" or "requestid"? > Anyone else care to comment? >=20 >>>> On Sat, Apr 14, 2007 at 12:58 AM, in message=20 > <461...@no...>, > 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=20 > 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 >=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=20 > 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=20 > 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 >=20 >> could be policy controlled by configuration file entries. >> =20 >> Whereas event data is very free form and user-defined/specified, = correlation=20 >=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=20 > Corlette <dco...@no...> wrote: >>=20 >> Hi John, >>=20 >> I debated about this - I think the Instance ID will be wildly useful = outside=20 >=20 >> the EVT structure (NVP) as a way of connecting multiple events together = into=20 >=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=20 > 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 >=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 >=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=3D= DEVDEV=20 > _______________________________________________ > openxdas-devel mailing list > ope...@li...=20 > https://lists.sourceforge.net/lists/listinfo/openxdas-devel=20 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/=20 _______________________________________________ openxdas-devel mailing list ope...@li...=20 https://lists.sourceforge.net/lists/listinfo/openxdas-devel=20 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/=20 _______________________________________________ openxdas-devel mailing list ope...@li...=20 https://lists.sourceforge.net/lists/listinfo/openxdas-devel |
|
From: John C. <jca...@no...> - 2007-04-20 04:34:07
|
Sorry Wayne, I should have checked the list mail before reading xdas mail = in my person folder. I didn't realize you'd copied the devel list on this = message, so I forwarded my response. I'll do it again here for completeness= : =20 I agree, this is a good change to bring the spec up to date in this area, = and URI is probably the right construct to use here. I'll add these = changes to my list of changes. =20 Thanks, John >>> On 4/19/2007 at 10:38 AM, in message <462746A00200004C000132A9@lucius.p= rovo.novell.com>, "Wayne Hsu" <wh...@no...> wrote: John, In the Novell Audit Instrumentation Converstion Manual you mentioned that = "A future version of the XDAS specification will undoubtedly combine these = two fields into one, indicating that the format should be standard URL = format." Since we are changing the XDAS specification, such as adding = correlation ID to the header, do you think we should also make this = change? Therefore, Originator Location Address and Originator Service Type will be = combined into one field called Location URL; Target Location Address and = Target Service Type will be combined into one field called Target URL. Also, shall we use term URI, which is more generic? Wayne Hsu Senior Software Engineer, eXtend Engineering (703) 967-4980 Novell, Inc., the leading provider of Net Business Solutions. www.novell.com=20 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/=20 _______________________________________________ openxdas-devel mailing list ope...@li...=20 https://lists.sourceforge.net/lists/listinfo/openxdas-devel |
|
From: John C. <jca...@no...> - 2007-04-20 04:31: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: John C. <jca...@no...> - 2007-04-20 04:28:53
|
Forwarding this note form Wayne, as it relates to the standard we're = (re)defining. :) =20 My response was positive, and I'm adding this change to a list of spec = changes I'm keeping. =20 --john >>> On 4/19/2007 at 10:38 AM, Wayne Hsu <wh...@no...> wrote: John, In the Novell Audit Instrumentation Converstion Manual you mentioned that = "A future version of the XDAS specification will undoubtedly combine these = two fields into one, indicating that the format should be standard URL = format." Since we are changing the XDAS specification, such as adding = correlation ID to the header, do you think we should also make this = change? Therefore, Originator Location Address and Originator Service Type will be = combined into one field called Location URL; Target Location Address and = Target Service Type will be combined into one field called Target URL. Also, shall we use term URI, which is more generic? Wayne Hsu Senior Software Engineer, eXtend Engineering Novell, Inc., the leading provider of Net Business Solutions. www.novell.com=20 |
|
From: John C. <jca...@no...> - 2007-04-20 04:27:20
|
Excellent Wayne. Let's do it. I'll add it to the list of things to modify = in the spec. I'm keeping a running check-list. =20 John >>> On 4/19/2007 at 10:38 AM, Wayne Hsu <wh...@no...> wrote: John, In the Novell Audit Instrumentation Converstion Manual you mentioned that = "A future version of the XDAS specification will undoubtedly combine these = two fields into one, indicating that the format should be standard URL = format." Since we are changing the XDAS specification, such as adding = correlation ID to the header, do you think we should also make this = change? Therefore, Originator Location Address and Originator Service Type will be = combined into one field called Location URL; Target Location Address and = Target Service Type will be combined into one field called Target URL. Also, shall we use term URI, which is more generic? Wayne Hsu Senior Software Engineer, eXtend Engineering (703) 967-4980 Novell, Inc., the leading provider of Net Business Solutions. www.novell.com=20 |
|
From: David C. <dco...@no...> - 2007-04-19 18:21:17
|
I think we're saying the same thing here, basically. - I agree that we won't be specifying tags for the domain-specific event fields - Within Sentinel, most likely we'll have a single "correlation ID" field as you describe, and "pick" whatever the best option is from the available IDs in the event - Part of what I was looking for is whether there were other types of IDs that might require us to have multiple correlation IDs for "N-dimensional" correlation, e.g. maybe we need to figure out a set of events that are connected by username, and a set that's connected by source IP. These are trivial examples, but my point is that maybe there are overlapping sets that are connected by different IDs. - BTW the Sentinel language includes a "name-value pair" parser that makes breaking up the event field easy - then you just need to figure out where to stuff the results. Thanks Wayne, good feedback! >>> On Fri, Apr 20, 2007 at 2:01 AM, Wayne Hsu wrote: > Although having comma separated <idname>=<idvalue> pairs in the correlation id > field is more flexible, it adds complexity when parsing or analyzing the > data. I suspect one string value for the correlation id will be fine for most > of the applications. In a database's term, every record has only one primary > key that serves to correlate the records within tables, even though there may > be other unique keys that identifies the same record. Application can create > a compound correlation id with the xdas naming format or store other unique > keys in the EVT section for this type of scenario. They can even stores the > <idname>=<idvalue> pairs. My point is not to impose any rule on this field. > > In the database logger, this will make querying the data tables easier. For > example, if I want to find a series of actions of a perticular workflow > request, I can just do "select * from table_name where correlation_id = > '<request_id_value>'. > > A free form, <idname>=<idvalue> pairs in the correlation if field will make this > type of query harder to write. > > 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/19/07 12:38 PM >>> > Hi Wayne, > > Yes, that's fine, but mostly I'm curious what kind of event > interrelationships people expect to see. This in part is because on the > backend Sentinel would split the data off into separate fields for easy > filtering, most likely. > >>>> On Thu, Apr 19, 2007 at 10:01 PM, Wayne Hsu wrote: >> 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=value 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 >> <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. >>> >>> >>> >> >> >> ------------------------------------------------------------------------- >> 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 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > openxdas-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openxdas-devel |
|
From: Wayne H. <wh...@no...> - 2007-04-19 18:02:16
|
Although having comma separated <idname>=3D<idvalue> pairs in the = correlation id field is more flexible, it adds complexity when parsing or = analyzing the data. I suspect one string value for the correlation id will = be fine for most of the applications. In a database's term, every record = has only one primary key that serves to correlate the records within = tables, even though there may be other unique keys that identifies the = same record. Application can create a compound correlation id with the = xdas naming format or store other unique keys in the EVT section for this = type of scenario. They can even stores the <idname>=3D<idvalue> pairs. My = point is not to impose any rule on this field.=20 In the database logger, this will make querying the data tables easier. = For example, if I want to find a series of actions of a perticular = workflow request, I can just do "select * from table_name where correlation= _id =3D '<request_id_value>'. A free form, <idname>=3D<idvalue> pairs in the correlation if field will = make this type of query harder to write. 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/19/07 12:38 PM >>> Hi Wayne, Yes, that's fine, but mostly I'm curious what kind of event interrelationsh= ips people expect to see. This in part is because on the backend Sentinel = would split the data off into separate fields for easy filtering, most = likely. >>> On Thu, Apr 19, 2007 at 10:01 PM, Wayne Hsu wrote:=20 > Are we confined to these names for the Correlation only? I thought the = field=20 > is extensible, therefore, instrumenation application can use whatever = names=20 > that make sense within its domain, be it sessionid or auid, as long as = it=20 > follows the name=3Dvalue format. >=20 > Wayne Hsu > Senior Software Engineer, > eXtend Engineering > (703) 967-4980 > Novell, Inc., the leading provider of Net Business Solutions. > www.novell.com >=20 >=20 >>>> "David Corlette" <dco...@no...> 04/13/07 7:43 PM >>> > John, >=20 > I agree with what you are saying, exactly. Correlation has a slightly=20= > broader meaning in the context of Sentinel, but the use of that word = here -=20 > e.g. to help us correlate between several related events - is perfect. >=20 > As for the field format, that also works for me. >=20 > So far we seem to have come up with: > sessionid > processid > threadid > requestid >=20 > I notice that the LAF (SuSE Linux audit framework) uses "auid" - but=20 > perhaps this could be considered a "sessionid" or "requestid"? > Anyone else care to comment? >=20 >>>> On Sat, Apr 14, 2007 at 12:58 AM, in message=20 > <461...@no...>, > 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=20 > 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 >=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=20 > 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=20 > 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 >=20 >> could be policy controlled by configuration file entries. >> =20 >> Whereas event data is very free form and user-defined/specified, = correlation=20 >=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=20 > Corlette <dco...@no...> wrote: >>=20 >> Hi John, >>=20 >> I debated about this - I think the Instance ID will be wildly useful = outside=20 >=20 >> the EVT structure (NVP) as a way of connecting multiple events together = into=20 >=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=20 > 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 >=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 >=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=3D= DEVDEV > _______________________________________________ > openxdas-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openxdas-devel ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ openxdas-devel mailing list ope...@li... https://lists.sourceforge.net/lists/listinfo/openxdas-devel |
|
From: Wayne H. <wh...@no...> - 2007-04-19 16:38:40
|
John, In the Novell Audit Instrumentation Converstion Manual you mentioned that = "A future version of the XDAS specification will undoubtedly combine these = two fields into one, indicating that the format should be standard URL = format." Since we are changing the XDAS specification, such as adding = correlation ID to the header, do you think we should also make this = change? Therefore, Originator Location Address and Originator Service Type will be = combined into one field called Location URL; Target Location Address and = Target Service Type will be combined into one field called Target URL. Also, shall we use term URI, which is more generic? Wayne Hsu Senior Software Engineer, eXtend Engineering (703) 967-4980 Novell, Inc., the leading provider of Net Business Solutions. www.novell.com |
|
From: David C. <dco...@no...> - 2007-04-19 16:38:33
|
Hi Wayne, Yes, that's fine, but mostly I'm curious what kind of event interrelationships people expect to see. This in part is because on the backend Sentinel would split the data off into separate fields for easy filtering, most likely. >>> On Thu, Apr 19, 2007 at 10:01 PM, Wayne Hsu wrote: > 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=value 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 > <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. >> >> >> > > > ------------------------------------------------------------------------- > 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 |
