Encrypted messages
Where are the plans of implementing encrypted messaging/logging?
I would like to see them as well. T. ----- Original Message ----- From: "Forrest Aldrich" <forrie@navipath.com> To: <syslog-ng@lists.balabit.hu> Sent: Monday, October 08, 2001 10:48 AM Subject: [syslog-ng]Encrypted messages
Where are the plans of implementing encrypted messaging/logging?
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
On Mon, Oct 08, 2001 at 11:49:20AM -0700, todd glassey wrote:
I would like to see them as well.
T. ----- Original Message ----- From: "Forrest Aldrich" <forrie@navipath.com> To: <syslog-ng@lists.balabit.hu> Sent: Monday, October 08, 2001 10:48 AM Subject: [syslog-ng]Encrypted messages
Where are the plans of implementing encrypted messaging/logging?
I think most of us just forward over stunnel with TCP logging and don't reallly worry about it. -- Nate Campi <nate@campin.net> GnuPG key: 0xC17AEF79 http://www.campin.net It is easy to find fault, if one has that disposition. There was once a man who, not being able to find any other fault with his coal, complained that there were too many prehistoric toads in it. -- Mark Twain, "Pudd'nhead Wilson's Calendar"
At 12:34 PM 10/8/2001 -0700, Nate Campi wrote:
I think most of us just forward over stunnel with TCP logging and don't reallly worry about it. [ ... ]
Sure, that works. But since it's listed as a "feature-to-be" and with other scenarios where stunnel might be overkill, this feature would be worthwhile to have. I presume it would have some form of digital signature (and verification) capability?
The real issue is in building a timestamping regimen and PKI based crypto service so that the log can be claimed to be "non-repudiated" and can later for forensic reasons be taken apart. This is way more than just tunneling and BTW, if you need a reason why this would be a good feature set to add, are you folks aware that under GLB and the privacy acts of a number of countries we all as systems admins can go to jail over what our logs contain. Todd ----- Original Message ----- From: "Forrest Aldrich" <forrie@navipath.com> To: <syslog-ng@lists.balabit.hu> Sent: Monday, October 08, 2001 4:30 PM Subject: Re: [syslog-ng] Encrypted messages
At 12:34 PM 10/8/2001 -0700, Nate Campi wrote:
I think most of us just forward over stunnel with TCP logging and don't reallly worry about it. [ ... ]
Sure, that works. But since it's listed as a "feature-to-be" and with other scenarios where stunnel might be overkill, this feature would be worthwhile to have. I presume it would have some form of digital signature (and verification) capability?
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
On Mon, Oct 08, 2001 at 05:27:57PM -0700, todd glassey wrote:
The real issue is in building a timestamping regimen and PKI based crypto service so that the log can be claimed to be "non-repudiated" and can later for forensic reasons be taken apart.
Then you need to look at products which have already begun to address these issues: http://kubarb.phsx.ukans.edu/~tbird/log-analysis.html#replacements -- Nate Campi <nate@campin.net> GnuPG key: 0xC17AEF79 http://www.campin.net ... A solemn, unsmiling, sanctimonious old iceberg who looked like he was waiting for a vacancy in the Trinity. -- Mark Twain
Nate, you may not get it yet, but globally it is the Systems Admins and DBA's that are going to first feel the pain of HIPAA/GLB and other global privacy acts like the EU's. The fact that there are not these services mean that the only testimony that is valid (or possibly valid) is that of the systems admin's operating the platforms and I assure you that the first time some police officer shows up with a DoJ warrant against the operations of a such-impacted system that everything will change. As to the OS manufacturers, they will not change until someone at a standards group gets a mandate to put in place a secured logging infrastructure, or until the UNIX Spec is updated, They are like banks and unless you can show them the money they are not interested. As to tools for replacing Syslog, what is Syslog-NG supposed to be? Todd ----- Original Message ----- From: "Nate Campi" <nate@campin.net> To: <syslog-ng@lists.balabit.hu> Sent: Monday, October 08, 2001 6:10 PM Subject: Re: [syslog-ng] Encrypted messages
On Mon, Oct 08, 2001 at 05:27:57PM -0700, todd glassey wrote:
The real issue is in building a timestamping regimen and PKI based crypto service so that the log can be claimed to be "non-repudiated" and can later for forensic reasons be taken apart.
Then you need to look at products which have already begun to address these issues:
http://kubarb.phsx.ukans.edu/~tbird/log-analysis.html#replacements -- Nate Campi <nate@campin.net> GnuPG key: 0xC17AEF79 http://www.campin.net
... A solemn, unsmiling, sanctimonious old iceberg who looked like he was waiting for a vacancy in the Trinity. -- Mark Twain
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
todd glassey on Mon, Oct 08, 2001 at 05:27:57PM -0700: Hi,
The real issue is in building a timestamping regimen and PKI based crypto service so that the log can be claimed to be "non-repudiated" and can later for forensic reasons be taken apart.
I think it is going to take a while until it gets there. Until then, there are various options you have to make a system as syslogd as tamper- proof and secure as it can be. Consider creating logfiles with append only flags and the like, an besides limiting access to the syslog server physically and over the network (using firewalling and client certifi- cates), encrypt and sign logs as they are being rotated. You can also automate comparison of logs on client/server-side, etc.
This is way more than just tunneling and BTW, if you need a reason why this would be a good feature set to add, are you folks aware that under GLB and the privacy acts of a number of countries we all as systems admins can go to jail over what our logs contain.
For one of our customers, we were able to get an agreement with the union in charge that we could keep plaintext-logs for five days for de- bugging reasons, and instead of just compressing the old logs, they are also encrypted and signed with a key that needs a four-eyes passphrase to unlock. This is somewhat odd, since I would think that logically the process of recording the information in the first place matters, and not the storage of this information. Besides that, I think it is possible to build a somewhat reliable (in all aspects of security) setup with UNIX/syslog-ng/stunnel, and signing and integrity checking tools. If "UNIX" is not BSD or Linux, I'd have a strong tendency to go compartmented, meaning B1, since there are some features that didn't make it into commercial vanilla UNIX yet. Even though a very stripped down Solaris properly hardened is good enough for all but the most paranoid. Caps and MAC are definitely nice to have though. I know that what I'm describing is far away from a completely neutral audit trail. But after all this is just about securing syslog, which by itself cannot be called a reliable source of information, since the actual source (the process logging at a certain facility/priority) can always be faked very easily given you have local access. So the main goal must be preventing local access to client and server, and authenticating and securing the communication between them (which is done beautifully by stunnel). I'll think about PKI when the networks are able to cope with full C2 audit trails going through :) Greetings, -- ____ ____ / _/| - > Gregor Binder <gb@(rootnexus.net|sysfive.com)> | / || _\ \ \__ Id: 0xE2F31C4B Fp: 8B8A 5CE3 B79B FBF1 5518 8871 0EFB AFA3 E2F3 1C4B
----- Original Message ----- From: "Gregor Binder" <gb@rootnexus.net> To: <syslog-ng@lists.balabit.hu> Sent: Monday, October 08, 2001 6:37 PM Subject: Re: [syslog-ng] Encrypted messages
todd glassey on Mon, Oct 08, 2001 at 05:27:57PM -0700:
Hi,
The real issue is in building a timestamping regimen and PKI based crypto service so that the log can be claimed to be "non-repudiated" and can later for forensic reasons be taken apart.
I think it is going to take a while until it gets there.
I disagree.
Until then, there are various options you have to make a system as syslogd as tamper- proof and secure as it can be. Consider creating logfiles with append only flags and the like, an besides limiting access to the syslog server physically and over the network (using firewalling and client certifi- cates), encrypt and sign logs as they are being rotated. You can also automate comparison of logs on client/server-side, etc.
Then you are stuck with the underlying FS of the hosting system as part of the security/access control model and local access can defeat this readily.
This is way more than just tunneling and BTW, if you need a reason why
this
would be a good feature set to add, are you folks aware that under GLB and the privacy acts of a number of countries we all as systems admins can go to jail over what our logs contain.
For one of our customers, we were able to get an agreement with the union in charge that we could keep plaintext-logs for five days for de- bugging reasons, and instead of just compressing the old logs, they are also encrypted and signed with a key that needs a four-eyes passphrase to unlock. This is somewhat odd, since I would think that logically the process of recording the information in the first place matters, and not the storage of this information.
Hmmmm - Still sounds like the System's Admin's were culpable for the OS Audit Trails...
Besides that, I think it is possible to build a somewhat reliable (in all aspects of security) setup with UNIX/syslog-ng/stunnel, and signing and integrity checking tools.
Only if synchronous messaging is used to insure delivery of the client's data to the logging server.
If "UNIX" is not BSD or Linux, I'd have a strong tendency to go compartmented, meaning B1, since there are some features that didn't make it into commercial vanilla UNIX yet. Even though a very stripped down Solaris properly hardened is good enough for all but the most paranoid. Caps and MAC are definitely nice to have though.
B1 is no longer a recognized standard. It is a part of the Orange Books (see: http://www.dynamoo.com/orange/fulltext.htm for a pointer to the Orange Book itself. The current methodology is the Common Criteria (See: http://www.commoncriteria.org).
I know that what I'm describing is far away from a completely neutral audit trail. But after all this is just about securing syslog, which by itself cannot be called a reliable source of information, since the actual source (the process logging at a certain facility/priority) can always be faked very easily given you have local access.
Given that you have local systems level access. Then you as the Systems Admin are the weak point in this Audit Model.
So the main goal must be preventing local access to client and server, and authenticating and securing the communication between them (which is done beautifully by stunnel).
And only accepting information from known sources.
I'll think about PKI when the networks are able to cope with full C2 audit trails going through :)
hey Partner C2 is old hat. Most if not all commercially available OS's will support C2 and most have a hardened mode that approaches what was known as B1 as well.
Greetings,
-- ____ ____ / _/| - > Gregor Binder <gb@(rootnexus.net|sysfive.com)> | / || _\ \ \__ Id: 0xE2F31C4B Fp: 8B8A 5CE3 B79B FBF1 5518 8871 0EFB AFA3 E2F3 1C4B
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
todd glassey on Tue, Oct 09, 2001 at 07:55:46AM -0700: Todd,
I think it is going to take a while until it gets there.
I disagree.
I think everybody is excited to hear about readily available solutions that satisfy all your needs?
Hmmmm - Still sounds like the System's Admin's were culpable for the OS Audit Trails...
Well, having in the union involved and on your side helps a lot I would guess, besides that, going to court with the slightest complaint is not to common in my country :)
B1 is no longer a recognized standard. It is a part of the Orange Books (see: http://www.dynamoo.com/orange/fulltext.htm for a pointer to the Orange Book itself. The current methodology is the Common Criteria (See: http://www.commoncriteria.org).
I know that, but the features I was talking about have been outlined in the Orange Book first and happen to be defined in the no-longer-a-stan- dard B1 standard (and B2 or 3 for compartments, I don't remember). I am not talking about certification, just features required.
Given that you have local systems level access. Then you as the Systems Admin are the weak point in this Audit Model.
I'm getting more and more curious to see above mentionned readily available solutions that can still work with vanilla applications and address this sort of problem :)
hey Partner C2 is old hat. Most if not all commercially available OS's will support C2 and most have a hardened mode that approaches what was known as B1 as well.
C2 might be an old hat, and obviously every commercial OS supports it, because C2 compliance used to be the minimum requirement for government computers. Still though, can you tell me ONE commercial OS (in it's non trusted version) that supports useful remote audit-logging? And no, NFS doesn't count. I am not even going to start asking about encryption :) And old hat or not, configurable call-level-logs are probably the best you can get in terms of audit trails. Ideally of course, providing the means of security you desire. Regards, -- ____ ____ / _/| - > Gregor Binder <gb@(rootnexus.net|sysfive.com)> | / || _\ \ \__ Id: 0xE2F31C4B Fp: 8B8A 5CE3 B79B FBF1 5518 8871 0EFB AFA3 E2F3 1C4B
The project "Samhain" has implemented a signatory process in its "Yule" server/logging subsystem. This might provide some ideas.
You have a pointer? T. ----- Original Message ----- From: "Forrest Aldrich" <forrie@navipath.com> To: <syslog-ng@lists.balabit.hu> Sent: Tuesday, October 09, 2001 10:36 AM Subject: Re: [syslog-ng] Encrypted messages
The project "Samhain" has implemented a signatory process in its "Yule" server/logging subsystem. This might provide some ideas.
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
----- Original Message ----- From: "Gregor Binder" <gb@rootnexus.net> To: <syslog-ng@lists.balabit.hu> Sent: Tuesday, October 09, 2001 8:54 AM Subject: Re: [syslog-ng] Encrypted messages
todd glassey on Tue, Oct 09, 2001 at 07:55:46AM -0700:
Todd,
I think it is going to take a while until it gets there.
I disagree.
I think everybody is excited to hear about readily available solutions that satisfy all your needs?
No a union will not stop law enforcement from arresting you for breaking the law around privacy issues.
Hmmmm - Still sounds like the System's Admin's were culpable for the OS Audit Trails...
Well, having in the union involved and on your side helps a lot I would guess, besides that, going to court with the slightest complaint is not to common in my country :)
No but is the enactment of privacy legislation? - I bet it is and whether you are living in te land of the US where people get sued for the slighest provacation, that has little to do with the criminal statute that the privacy acts put in place.
B1 is no longer a recognized standard. It is a part of the Orange Books (see: http://www.dynamoo.com/orange/fulltext.htm for a pointer to the
Orange
Book itself. The current methodology is the Common Criteria (See: http://www.commoncriteria.org).
I know that, but the features I was talking about have been outlined in the Orange Book first and happen to be defined in the no-longer-a-stan- dard B1 standard (and B2 or 3 for compartments, I don't remember). I am not talking about certification, just features required.
Given that you have local systems level access. Then you as the Systems Admin are the weak point in this Audit Model.
I'm getting more and more curious to see above mentionned readily available solutions that can still work with vanilla applications and address this sort of problem :)
I agree that there are a number of solutions proposed but most of them still rely on the operating environment being phiysically secure. I.e. if you have direct access to the machine then all bets are off and that also is an issue. How to turn the audit model into an appliance so that Sys Admin's cannot poke their fingers into it.
hey Partner C2 is old hat. Most if not all commercially available OS's
will
support C2 and most have a hardened mode that approaches what was known as B1 as well.
C2 might be an old hat, and obviously every commercial OS supports it, because C2 compliance used to be the minimum requirement for government computers.
In what country? In the US thebasic requirements are spelled out in FIPS and other documents specific to the organization that will be using the systems. In the UK its BS7799/PD5000 and in Europe its more of OSI/IEC 17799 I understand.
Still though, can you tell me ONE commercial OS (in it's non trusted version) that supports useful remote audit-logging? And no, NFS doesn't count. I am not even going to start asking about encryption :)
And old hat or not, configurable call-level-logs are probably the best you can get in terms of audit trails. Ideally of course, providing the means of security you desire.
Maybe, but the issue is how to run them securely embedded inside of other systems.
Regards,
-- ____ ____ / _/| - > Gregor Binder <gb@(rootnexus.net|sysfive.com)> | / || _\ \ \__ Id: 0xE2F31C4B Fp: 8B8A 5CE3 B79B FBF1 5518 8871 0EFB AFA3 E2F3 1C4B
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
On Mon, Oct 08, 2001 at 07:30:04PM -0400, Forrest Aldrich wrote:
At 12:34 PM 10/8/2001 -0700, Nate Campi wrote:
I think most of us just forward over stunnel with TCP logging and don't reallly worry about it. [ ... ]
Sure, that works. But since it's listed as a "feature-to-be" and with other scenarios where stunnel might be overkill, this feature would be worthwhile to have. I presume it would have some form of digital signature (and verification) capability?
There are two ways: - use simply SSL/TLS - use the new drafted syslog-sign protocol I'd go for both options with syslog-ng, ASAP whatever this means. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
----- Original Message ----- From: "Balazs Scheidler" <bazsi@balabit.hu> To: <syslog-ng@lists.balabit.hu> Sent: Tuesday, October 09, 2001 2:39 AM Subject: Re: [syslog-ng] Encrypted messages
On Mon, Oct 08, 2001 at 07:30:04PM -0400, Forrest Aldrich wrote:
At 12:34 PM 10/8/2001 -0700, Nate Campi wrote:
I think most of us just forward over stunnel with TCP logging and don't reallly worry about it. [ ... ]
Sure, that works. But since it's listed as a "feature-to-be" and with other scenarios where stunnel might be overkill, this feature would be worthwhile to have. I presume it would have some form of digital signature (and verification) capability?
There are two ways:
- use simply SSL/TLS - use the new drafted syslog-sign protocol
neither of these address the necessity to prove receipt of the message from the Server however. They are at best external methods of fortifying the outside of the communications process, but TCP/IP especially over Ethernet is an issue from being able to prove anything. T.
I'd go for both options with syslog-ng, ASAP whatever this means.
Bazsi - I would suggest that there needs to be a receipt manager as an optional portion of NG. What it would do is compare the signatures from client's it knows clients to a message prior to marking it as "official". This would entail some form of "discovery process" as well though, but it could be done!
-- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C
8EB1
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
participants (5)
-
Balazs Scheidler
-
Forrest Aldrich
-
Gregor Binder
-
Nate Campi
-
todd glassey