FYI I need to tell you folks about a patent I/we have filed for already.
200000 feet
-----------------
The idea is to create an "Evidentiary Third Party" than can be installed into any system as its testimony agent, which under eSign, can give its own testimony apart from the Humans around it - it would be the first of what I see as a new wave of "Machine Testimony" Protocols! - hell with my insured timestamps from CertifiedTime Inc, this system could be used to dole corporate insurance out at the Transaction level - so there are any number of unique applications in trust and reliable testimony at stake here...
Patent Announcement
---------------------------------
The already filed patent app is for an Integrated Testimonial Agent based on Syslog and several other protocols merged into a homogeneous executable suite - the system is both a HW/SW system and a SW alone implementation as an 'emulator' for Mainframes and OS Distributions.
The initial provisional goal was to create an Audit Agent with a single Executable Footprint for Security Purposes. The requirement for this new Integrated Logging/Time Management Agent technology rests in eliminating many covert-channel attacks or log altering processes from existing Financial Processing Systems and to provide self-substantiating testimony for people who need this for their SOX, NASD or Financial Trading, NACHA or FFIEC compliance as well as meeting VISA and MC's new Security Standards practice models, and other legislative compliance models.
To this end, I and my partner have a provisional patent already filed for a special version of an integrated suite which features an Authenticated reliable delivery Syslog with receipt and buffer control acknowledgements for assured delivery or requeue service for authenticated messages.
We have two forms of Cryptography and one adapts NTP's AutoKEY and establishes a new form which uses our rights to the Cryptography in the already issued US Patent 6,370,629 entitled "Controlling Access to Stored Information". The base patent issued in march of 2000 initially describes its favored form through use of a mechanical device for location indicator, and can under claims 28-32 use Physical, Logical, and Virtual Event-Times or ranges and Event-Locations or ranges in its policy control. The timeservice is integrated with this for evidentiary status.
BEPS
---------
The new derivative "Evidentiary Agent" and "Digital Object Control Protocol" patent addresses an authenticated Systems and Application Logging Agent with integrated Time Management service with its own built in Timestamping/Authenticator Protocol. The TSP implements both RFC3161 protocol and the BERT token protocol Michael McNeil and I came up with as well as pure NTP based AutoKEY Timestamping and Authentication.
The System also allows for Token Interaction and PKCS11 and other PKCS services. It, the newly merged protocol-suite, is referred to as the BEPS - or the "Basic Evidentiary Protocol Suite" and as noted above, has an advanced version that uses HW Tokens for its trust anchors for Government or Military Applications.
AssuranceWorks.COM
----------------------------------
This work stems from work I and others did several years ago for a startup called AssuranceWorks.COM (check the Archive.ORG) - we built an embedded 'agent module' that was based on my OpenPeer SBC PC. The Agent managed embedded Syslog and NTP Services among other things. The OpenPeer device turned a PCI based computer into a Blade-Rack for PCI-based Distributed Peering modules. This OpenPeer integrated a SBC and a NIC Card such that the NIC's PCI Bus was the interface to the Host which the Peer used as a routing GW. Both modules were installed into the backplane of the Central Node in the Star-cluster that adding these to a PC based on a PCI backplane, created.
This technology leverages location and time data for logging
--------------------------------------------------------------------------------------
This system we are patenting now is built to utilize our already patented Time and Location Cryptography and Policy Controls, and creates an integrated Evidentiary Protocol with both local and remote Agent's within an OS... I think you will like it - the system is implemented in the final filing as both an appliance or a pure SW only emulation of the HW system so this works everywhere including the mainframe or mega-grid server as well. Very cool!
Todd Glassey CISM CIFI
----- Original Message -----
From: ross.patterson@private
To: loganalysis@private
Sent: Friday, March 10, 2006 12:06 PM
Subject: [logs] Re: FW: [Syslog] WG Review: Recharter of Security Issuesin Network Event Logging (syslog)
For comparison purposes, the current charter is more focused on the existing Syslog protocol:
Description of Working Group:
Syslog is a de-facto standard for logging system events. However, the
protocol component of this event logging system has not been formally
documented. While the protocol has been very useful and scalable, it
has some known but undocumented security problems. For instance, the
messages are unauthenticated and there is no mechanism to provide
verified delivery and message integrity.
The goal of this working group is to document and address the security
and integrity problems of the existing Syslog mechanism. In order to
accomplish this task we will document the existing protocol. The
working
group will also explore and develop a standard to address the security
problems.
Beyond documenting the Syslog protocol and its problems, the working
group will work on ways to secure the Syslog protocol. At a minimum
this group will address providing authenticity, integrity and
confidentiality of Syslog messages as they traverse the network. The
belief being that we can provide mechanisms that can be utilized in
existing programs with few modifications to the protocol while
providing significant security enhancements.
Goals and Milestones:
Done Post as an Internet Draft the observed behavior of the Syslog protocol for consideration as an Informational Document.
Done Submit Syslog protocol document to IESG for consideration as an INFORMATIONAL RFC.
Done Post as an Internet Draft the specification for an authenticated Syslog for consideration as a Standards Track RFC.
Done Post an Internet Draft describing enhancements to the Syslog authentication protocol to add verification of delivery and other security services.
Done Submit Syslog Authentication Protocol Enhancement to IESG for consideration as a PROPOSED STANDARD.
Oct 2004 Submit Syslog Internationalization to IESG for consideration as a PROPOSED STANDARD.
Mar 2005 Submit Syslog Protocol to IESG for consideration as a PROPOSEDSTANDARD
Mar 2005 Submit Syslog Transport Mapping to IESG for consideration as a PROPOSED STANDARD.
Jun 2005 Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD
Jul 2005 Submit Syslog Authentication Protocol to IESG for consideration as a PROPOSED STANDARD.
Apr 2006 Revise drafts as necessary to advance these Internet-Drafts to Standards Track RFCs.
Internet-Drafts:
Signed syslog Messages (64948 bytes)
Syslog Management Information Base (51076 bytes)
The syslog Protocol (82950 bytes)
Transmission of syslog messages over UDP (21705 bytes)
Request For Comments:
The BSD Syslog Protocol (RFC 3164) (72951 bytes)
Reliable Delivery for Syslog (RFC 3195) (60960 bytes)
(http://www.ietf.org/html.charters/syslog-charter.html)
--
Ross A. Patterson
Manager of Engineering
phone: +1 703-547-3581
email: Ross.Patterson@private
Consul risk management
http://www.consul.com
2121 Cooperative Way, Suite 250
Herndon, VA 20171
USA
"Rainer Gerhards" <rgerhards@private>
Sent by: loganalysis-bounces+ross.patterson=consul.com@private
03/10/2006 01:56
To <loganalysis@private>
cc
Subject [logs] FW: [Syslog] WG Review: Recharter of Security Issues in Network Event Logging (syslog)
Hi all,
I am forwarding a syslog-related message from the IETF to this group. I
am doing so because I assume there is some interest in the evolution of
syslog. Please note that you can comment to the IESG (IETF) if you have
an opinion on the topic. For details, please see below.
Best regards,
Rainer
> -----Original Message-----
> From: IESG Secretary [mailto:iesg-secretary@private]
> Sent: Friday, March 10, 2006 12:58 AM
> To: IETF Announcement list
> Cc: syslog@private
> Subject: [Syslog] WG Review: Recharter of Security Issues in
> Network Event Logging (syslog)
>
> A modified charter has been submitted for the Security Issues
> in Network Event
> Logging (syslog)working group in the Security Area of the IETF.
> The IESG has not made any determination as yet. The modified
> charter is provided
> below for informational purposes only. Please send your
> comments to the IESG
> mailing list (iesg@private) by March 15th.
>
> The IESG solicits feedback from those considering
> implementing or deploying
> syslog on the following charter. In particular, the concern
> has been raised that
> insufficient vendors will implement a new syslog protocol and
> insufficient
> operators will deploy it. The IESG requests those who support
> this effort to
> explicitly indicate their support.
> If significant community support is not indicated, this work
> will not be
> chartered.
>
> +++
>
> Security Issues in Network Event Logging (syslog)
> ====================================
>
> Current Status: Active Working Group
>
> Chair(s):
> Chris Lonvick <clonvick@private>
>
> Security Area Director(s):
> Russ Housley <housley@private>
> Sam Hartman <hartmans-ietf@private>
>
> Security Area Advisor:
> Sam Hartman <hartmans-ietf@private>
>
> Mailing Lists:
>
> General Discussion: syslog@private
> To Subscribe: syslog-request@private
> In Body: in body: (un)subscribe
> Archive: ftp://ftp.ietf.org/ietf-mail-archive/syslog/
>
> Description of Working Group:
>
> Syslog is a de-facto standard for logging system events.
> However, the protocol
> component of this event logging system has not been formally
> documented. While
> the protocol has been very useful and scalable, it has some
> known security
> problems which were documented in the INFORMATIONAL RFC 3164.
>
> The goal of this working group is to address the security and
> integrity
> problems, and to standardize the syslog protocol, transport,
> and a select set of
> mechanisms in a manner that considers the ease of migration
> between and the
> co-existence of existing versions and the standard.
>
> Reviews have shown that there are very few similarities
> between the message
> formats generated by heterogeneous systems. In fact, the only
> consistent
> commonality between messages is that all of them contain the
> <PRI> at the start.
> Additional testing has shown that as long as the <PRI> is
> present in a syslog
> message, all tested receivers will accept any generated
> message as a valid
> syslog message. In designing a standard syslog message
> format, this Working
> Group will retain the <PRI> at the start of the message and
> will introduce
> protocol versioning. Along these same lines, many different
> charsets have been
> used in syslog messages observed in the wild but no
> indication of the charset
> has been given in any message. The Working Group also feels
> that multiple
> charsets will not be beneficial to the community; much code
> would be needed to
> distinguish and interpret different charsets.
> For compatibility with existing implementations, the Working
> Group will allow
> that messages may still be sent that do not indicate the charset used.
> However, the Working Group will recommend that messages
> contain a way to
> identify the charset used for the message, and will also
> recommend a single
> default charset.
>
> syslog has traditionally been transported over UDP and this
> WG has already
> defined RFC 3195 for the reliable transport for the syslog
> messages. The WG will
> separate the UDP transport from the protocol so that others may define
> additional transports in the future.
>
> The threats that this WG will primarily address are
> modification, disclosure,
> and masquerading. A secondary threat is message stream
> modification. Threats
> that will not be addressed by this WG are DoS and traffic
> analysis. The primary
> attacks may be thwarted by a secure transport. However, it
> must be remembered
> that a great deal of the success of syslog has been
> attributed to its ease of
> implementation and relatively low maintenance level. The
> Working Group will
> consider those factors, as well as current implementations,
> when deciding upon a
> secure transport. The secondary threat of message stream
> modification can be
> addressed by a mechanism that will verify the end-to-end
> integrity and sequence
> of messages. The Working Group feels that these aspects may
> be addressed by a
> dissociated signature upon sent messages.
>
> - A document will be produced that describes a standardized
> syslog protocol.
> A mechanism will also be defined in this document that will
> provide a means to
> convey structured data.
>
> - A document will be produced that describes a standardized
> UDP transport for
> syslog.
>
> - A document will be produced that requires a secure
> transport for the delivery
> of syslog messages.
>
> - A document will be produced to describe the MIB for syslog entities.
>
> - A document will be produced that describes a standardized
> mechanism to sign
> syslog messages to provide integrity checking and source
> authentication.
>
>
> Milestones:
>
> Nov 2006 Submit Syslog Protocol to the IESG for consideration
> as a PROPOSED
> STANDARD.
> Nov 2006 Submit Syslog UDP Transport Mapping to the IESG for
> consideration as a
> PROPOSED STANDARD.
> Nov 2006 Submit Syslog TLS Transport Mapping to the IESG for
> consideration as a
> PROPOSED STANDARD.
> Nov 2006 Submit Syslog Device MIB to IESG for consideration
> as a PROPOSED
> STANDARD.
> Nov 2006 Submit a document that defines a message signing and
> ordering mechanism
> to the IESG for consideration as a PROPOSED STANDARD
>
>
>
>
>
>
>
> _______________________________________________
> Syslog mailing list
> Syslog@private
> https://www1.ietf.org/mailman/listinfo/syslog
>
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis
------------------------------------------------------------------------------
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2.1.3 : Mon Mar 13 2006 - 09:44:51 PST