Showing posts with label CEE. Show all posts
Showing posts with label CEE. Show all posts

Tuesday, July 26, 2011

NIST EMAP Workshop–Aug 2011

A lot of good work on logging standards as well as standards for the “surrounding areas” (correlation rules, parsing rules, etc) will happen at this first-ever NIST workshop on EMAP.

Please mark your calendars to save the date for an EMAP Developer Workshop to be held August 29-30, 2011 at the NIST Campus in Gaithersburg, Maryland.  We are still formalizing the agenda, but topics to be covered will include:

· Discussion of target use cases and requirements as identified by EMAP working group.

· CEE Overview and in-depth discussion of current issues.

· Discussion of EMAP component specifications and issues/questions for the community.

· Discussion of EMAP roadmap and connections with other efforts within security automation.

We are in the process of standing up a registration page and creating the agenda.  A teleconference line will be provided for those who cannot attend in person.  More details to come in the near future, we hope to see you there.

If you are dealing with logs and SIEM (such as building, or even using the tools) and care about standards, please consider attending – but only if you will contribute!

Possibly related posts:

Wednesday, June 08, 2011

NIST EMAP Out

As those in the know already know, NIST has officially released some EMAP materials the other day (see scap.nist.gov/emap/). EMAP stands for “Event Management Automation Protocol” and has the goal of “standardizing the communication of digital event data.” You can think of it as future “SCAP for logs/events” (the SCAP itself is for configurations and vulnerabilities). Obviously, both twin standards will be “Siamese twins” and will have multiple connection points (such as through CVE, CPE and others).

In reality, SCAP and EMAP are more like “standard umbrellas” and cover multiple constituent security data standards – such as CPE, CVE, CVSS, XCCDF, etc for SCAP and CEE for EMAP. As the new EMAP site states:

The Event Management Automation Protocol (EMAP) is a suite of interoperable specifications designed to standardize the communication of event management data. EMAP is an emerging protocol within the NIST Security Automation Program, and is a peer to similar automation protocols such as the Security Content Automation Protocol (SCAP). Where SCAP standardizes the data models of configuration and vulnerability management domains, EMAP will focus on standardizing the data models relating to event and audit management. At a high-level, the goal of EMAP is to enable standardized content, representation, exchange, correlation, searching, storing, prioritization, and auditing of event records within an organizational IT environment.

[emphasis by me]

While CEE team is continuing its work on the log formats, taxonomy, profiles and other fun details of logging events, the broader EMAP effort creates a framework around it as well as proposes a set of additional standards related to correlation, parsing rules, event log filtering, event log storage, etc. The released deck [PDF] has these details as well as some use cases for EMAP such as Audit Management, Regulatory Compliance, Incident Handling, Filtered Event Record Sharing, Forensics, etc.

In the future, I expect EMAP to include event log signing, maybe its own event transport (run under CEE component standard) as well as a bunch of standardized representation for correlation (via CERE component standard) and parsing rules (via OEEL) to simplify SIEM interoperability as well as migration.

Everything public to read on EMAP is linked here (2009), here (2010), here, etc [links are PDFs], if you are into that sort of reading. SIEM/log management vendors, please pay attention Smile - some of you have already started implementation of this stuff….

Monday, November 22, 2010

CEE Log Standard for Dummies!

We wrote a very clear and concise note about Common Event Expression (CEE) approach to log standards. Even marketing people can read it Smile

Quoted from here:

“I'd like to make you aware that the CEE editorial board has published a short overview white paper describing the overall CEE effort including the problems and approaches that CEE is taking.

If you want a quick summary of what CEE is and how the different parts of the effort work, we'd encourage you to take a look at this paper.
The document is available for download in PDF form on the CEE web site: http://cee.mitre.org/documents.html.

And as always, we'd encourage your feedback- please feel free to post any comments to the CEE discussion mailing list at cee-discussion-list@lists.mitre.org. “

P.S. Posted by a scheduler. I am away from the computers – responses to comments will be delayed.

Friday, August 27, 2010

CEE Architecture Overview FINALLY Out!

The future of logging is finally here! Common Event Expression (CEE) team releases CEE Architecture Overview [PDF] for public comments. HUGE thanks to MITRE side of team for finally clearing all the hurdles and releasing “our baby.”

The Common Event Expression (CEE™) Architecture Overview document defines the structure and components that comprise the CEE event log standard. This architecture was developed by MITRE, in collaboration with industry and government, and builds upon the Common Event Expression Whitepaper. This document defines the CEE Architecture for an open, practical, and industry-accepted event log standard. It provides a high-level overview of CEE along with details on the overall architecture and introduces each of the CEE components including the data dictionary, event taxonomies, syntax encodings, and profiles. The CEE Architecture is the first in a collection of documents and specifications, whose combination provides the necessary pieces to create the complete CEE event log standard. 

We encourage community members to offer feedback on this document on the CEE
Email Discussion list. You may also contact us directly at cee@mitre.org.

Again, the document is at: http://cee.mitre.org/docs/CEE_Architecture_Overview-v0.5.pdf

The day we were working towards for nearly five years (!) has finally come and more of CEE is revealed to the world! Of course, detailed specifications are still in development and we will release them when they are ready for public review.

Possibly related posts:

Sunday, August 22, 2010

CEE Update – Aug 2010

Reposted (from here) for those who don’t monitor public Common Event Expression (CEE) log standard effort.

“First of all, let me answer the question that is in all of your heads: No, CEE is not dead... After a slow start, the work pace has picked up over the past couple of months. I apologize for the extremely long delay in posting any details regarding the state of CEE.


The CEE Board [that’s us – A.C. :-)] has been working on bringing the CEE Dictionary, Taxonomy, and Syntax requirements together. We have drafted specification documents detailing the CEE Architecture as well as the initial Dictionary and Taxonomy specifications. These documents are the first of the CEE v0.5 (previous versions were internal) document series and have already been shared with some of you for your feedback. We are waiting for the final authorization before they are posted to the CEE website for your review.

This authorization is expected to be granted next week. A follow-up e-mail will be sent to this discussion list as well as the CEE Announce list notifying you that the documents were posted along with the URL where said documents may be obtained. It is important to note that these are only the first iterations of many. We need your help in improving CEE.
 

In addition to helping critique and improve the CEE documents, we are also requesting your help in building and improving the CEE Use Cases. Within the next week or two, you will also receive the beginnings of a list of CEE Use Cases for review.”

Sign up for the public CEE list to see more. Meanwhile, the effort for log standardization makes another step!

Wednesday, October 28, 2009

Presentation from NIST SCAP

As mentioned before, here is my presentation from 5th Annual IT Security Automation Conference in Baltimore, MD on Oct 26-29, 2009.

Onto CSI2009 tomorrow; my PCI presentation there is going to be totally awesome :-) It will feature … The Devil!!!

Also, events notes from the NIST event will follow later.

See you there!

Friday, August 14, 2009

Log Standards Make A HUGE Step

Quietly, sometimes with tiny steps and sometimes with long delays for deep meditation :-), the case for log standardization moves forward. Recently, at RSA2009 and BlackHat2009 meetings, the CEE team has managed to achieve a breakthrough and actually resolve many of the highly debated issues of taxonomy, definitions, formats and even of the future CEE compliance program. Of course, not all of the trouble spots are resolved – the log standardization remains as devilishly hard as it always has been!

For example, here is how far the Common Event Expression has progressed:

“Status
------
MITRE is continuing work on the Common Event Expression (CEE) standard
in conjunction with the Editorial Board and various organizations.
The past months have been spent on the drafting and validation of a
proposal for the initial CEE Specification.

This specification was submitted to the Editorial Board last month.
MITRE is currently working at rolling in the comments received from
the Board, and expect to have a new draft for their review in the next
couple of weeks.
Once the Board has approved the specification, the specification will
be posted to the CEE Community for feedback. We expect this to occur
within the next month. Our goal is to have final proposal that the
community can agree to by the end of 2009
. “

and

“Proposed Specification
----------------------
MITRE in collaboration with industry and government offer the Common
Event Expression (CEET) Architectural Proposal for the Core
Components as the basis to standardize event logs from electronic
systems. This paper builds on the CEE proposal summarized in the
Common Event Expression Whitepaper by defining the core components'
architecture needed to enable collaborative efforts in the creation
of an open, practical, and industry-accepted event interoperability
standard for electronic systems.
This specification summarizes CEE and provides details on the
architecture of the core components including the data dictionary,
syntax specifications, and event taxonomies.
This proposal is the
first in a collection of documents and specifications. The
combination of the documents and specifications provides the
necessary pieces to create a complete event log standard, which can
be mapped against the four components of CEE: Transport, Syntax,
Taxonomy, and Log Recommendations. “

Finally, CEE and the - previously thought to be lost - cause for log standardization now have a secret weapon: the EMAP, SCAP’s evil twin.

You thought government will mandate which health insurance you’d have? Ha-ha-ha, how about what logs you’d have? ;-) [but unlike health insurance, that would be a good thing!![

Possibly related posts:

  • TBA
  • All posts about CEE

Wednesday, April 29, 2009

RSA 2009 Impressions, Part IV or The Rest of RSA 2009

This is my final RSA 2009 impressions post; check out the previous ones here. Check out other coverage of RSA 2009 on security blogs here.

First, I did go to a few sessions; way less than I wanted. One on SIEM (which was a little sad), one on PCI (which was very exciting) and a few others mentioned below. As many other, I was shocked about how poorly the sessions were scheduled: I had situations where 4 sessions (!) running at the same time were interesting and then there were two time slots where none were (OK, maybe it is just me :-)), Also, I was amazed to see flashes of TweetDeck everywhere in the audience; amazing change from last year when Twitter was virtually unheard of.

Next, I went to Jericho Forum mini-conference, which was kinda fun in its own detached way ;-) There were a few presentations about “cloud security”, cloud cube, etc. And, which was more fun, Philippe gave his pre-keynote presentation to the Jericho club (this is where he first mentioned cloud as a possible way to “invisible/ implicit/ unavoidable”  security), which was then followed by a good discussion. Then Rich Mogul, Gunnar Peterson and Chris Hoff beat up on the Jericho folks a tiny bit ("COA is unimplementable”, “no practical examples in documents”, ”confuses data centricity”, etc). Obviously, the common sense conclusion that ‘"the cloud" is no more/no less secure’ was the pink elephant in the room; it’s what you do with it counts.

Another pinky was the idea that “security is either baked in or none" for consumers; current move to cloud computing is our second chance to bake security in. How can we not miss that chance? Since power of large end user organizations is what often drives security (e.g. trustworthy computing at MS), unless and until large organizations say “I won't use XYZ cloud vendor unless secure up to ABC standards” this second chance will not be taken advantage of [this BTW needs said ABC standard as well a few metrics to boot].

On Thursday, our log standards panel was held; it was lots of fun too and we had almost 100 people (!). Dan Blum, our moderator, has a good account of it here. However, what matters is what happened before the panel: we had a three hour working meeting and made a lot of progress on Common Event Expression (CEE) effort in particular and log standards in general (more details in the future)

On Friday I went to RSA just to see Chris Hoff and Rich Mogul do their “Disruptive Innovation and Security” session, which exuded pure awesomeness! Key items I caught:

  • Business innovation vs technology innovation vs security innovation – all 3 often seem out of sync, but security innovation is usually MORE behind.
  • Threat innovation IS business innovation – just for the criminal businesses.
  • Chris and Rich suggest that the motion from network->host-> data is not linear, but part of a cyclic circular progress; a fun idea.
  • I realized that an idea that I recently “suffered” from (“intrusion tolerance”) is the same as what Chris calls “information survivability
  • Also, I liked their technology assessment methodology: security impact vs business impact chart (with IDS is in left bottom corner with both being “low”)

Finally, the most important part: the vendor hall impressions. Every year I am trying to “soak the vendor hall in” – and then produce insight while seating in an armchair (that last part is key for being called “an armchair analyst” :-)). This year I got a bizarre sensation: a whole hall-full of vendors TOTALLY missing both a) security of cloud applications (broadly defined) and b) ability to provide security services via SaaS/cloud (yes, I know these are not the same). No, this is not some Qualys PR talk – just think about it: 23 (!) RSA sessions that mention “SaaS” or “cloud computing” combined with almost NO vendors providing either a) or b) above (apart from blatantly idiotic “cloud gods send us the virus definitions” already ridiculed here). If I were to launch a security company today, I would NEVER even think of doing software, maybe an appliance – but most likely SaaS… I bet in a few years the whole concept of “buying servers to run security on them” will be grounds for being put into asylum (I do remember the time when my employer of 2002-2006 sometimes required 17 servers to run well…)

A few more observations from the expo: vendors who add themselves to all product categories probably means “FAIL due to lack of focus.” I saw a SIEM vendor listing themselves in a whole bunch of categories, including “Vulnerability Scanning” and a scanning vendor listed, among other things, in “DRM” (!) Also, I saw amazing amount of horribly confusing marketing, all the way to “not clear one bit to a certain Ph.D. ‘security insider’” :-) People, grow up! If users don’t get what you do, they will NOT buy your stuff! Among the technologies which vanished from our collective consciousness are: NAC (in a year I bet folks will ask what the letters stand for), anti-spyware and – strangely – DLP.

Overall, awesome show!

Possibly related posts:

Wednesday, March 11, 2009

RSA 2009 Panel on Log Standards

Yes, the words “log” and “standard” in one sentence; alongside each other, in fact :-)

 

Session Code: HOST-304

Session Title: Common Event and Log Standards: Leveling IT's Tower of Babel

Scheduled Date/Time:  Thursday, April 23 02:10 PM @ Purple 304

Abstract:  The IT industry suffers from a lack of standards for event, log, and audit information. Regulatory requirements to retain, protect, and destroy log data continue to increase. Organizations also need better situation awareness and cost control across complex IT security event horizons. The good news is that standards efforts are underway, which this session will detail.

Moderator:

  • Daniel Blum, Senior VP, Principal Analyst Burton Group

Panelist:

  • Anton Chuvakin, Director of PCI Compliance Solutions, Qualys
  • David Corlette, GRC Solution Architect
  • Eric Fitzgerald, Senior Program Manager, Microsoft
  • Mary Ann Davidson, Chief Security Officer, Oracle

Attendance is mandatory :-)

Monday, September 15, 2008

Fun Reading on Logs and Log Management - 2

I am amazed (no, AMAZED!) about how many people now write about logs; it is definitely not "the original logging evangelist" anymore :-) Here is a bunch of good log-related reading, useful for those struggling with logs (aka "everybody" :-))

  1. Our brilliant field engineer Dimitri McKay talks about the eternal topic of converting Windows event logs to syslog. Yes, Eric, we ALL know it is ugly, but that is the only way that actually works well across all systems ...
  2. More on Windows and syslog: "Syslog ... 20 Years Later." BTW, this is really not about syslog, but about Vista/2k8 finally getting an ability to natively centralize the event logs via event subscriptions ("It's only about twenty years behind schedule, if you're counting.")
  3. Two fun pieces on correlation: 1 and 2. What often kills "a log correlation project"? "Whoever had worked on it had not had much time available to learn the way to properly configure the software" (from this) and "correlation only really works when backed up by real data about what is the biggest problem in your environment, and how that problem manifests itself in the event logs." (from this) None of this is new, but a useful reminder nonetheless
  4. Fun LogLogic podcast is here. The topic of this high-level discussion (CEO) is related to operational use for logs. I did one with them too; on logs and virtualization (will be up soon)
  5. A couple of good posts on logging from Nemertes Research: "Sharpening Stones and Walking on Coals", "Search or Destroy"
  6. Reminder about a few useful Windows Vista and 2k8 events: 4802 (screensaver engaged) and 4803 (screensaver dismissed)
  7. One person is wondering about the usefulness of logging after "experiencing" Linux auditd logging (kernel audit): "Logs are like a warm blanket; verbose logging means you can know what's happening on your systems if you keep up with the logs. At the same time, logs become a burden very very easily, and they are easy to ignore." This post is a must read for us logging afficionados; producing too much log data is a sure way to make people hate you...
  8. This also follows the same theme: people doubting the god-like power of logs :-) "So for an administrator to not care about logs was a shock." But would I argue that "log management is NOT a pain?" Now, would I? :-)
  9. A classic about logging for application developers: "Building Secure Applications: Consistent Logging." I am noticing a lot more discussions about logging in a developer community, e.g. see this and this (the latter, BTW, contains a lot of info on "why log" for developers). Overall, "getting logging right" is important (and will get more important in the future) and people need something NOW and cannot wait for the standards. BTW, I am planning a mini-crusade on how to train application developers to include useful logging in their applications...
  10. Finally, the "Is SIEM dead?" theme is continued in this fun post "Life after SIEM. Situational Awareness is next." Indeed, context is key for logs. BTW, if somebody mentions that I have "vendor bias", I will kick your ass! :-)

Enjoy!

Possibly related posts:

Friday, June 20, 2008

CEE White Paper Out (Finally!!!!!!!!!!)

Don't you dare make fun of my "Finally!!!!!!!!!!" in the title. We've been waiting for the release to happen for a "few" months already.

In any case, Common Event Expression (CEE) standard takes a major step forward: our whitepaper is finally public (page, PDF)

"Provides a detailed introduction to the Common Event Expression (CEE) initiative to create an open community-developed event interoperability standard for electronic systems. The paper describes the scope of the problem; explains how CEE’s Common Log Transport (CLT), Common Log Syntax (CLS), Common Event Expression Taxonomy (CEET), and Common Event Log Recommendations (CELR) will provide the framework for a community consensus in log transportation, log syntax, event representation, and event logging recommendations for various log sources and scenarios; examines the benefits and illustrates them in two use cases; reviews CEE in comparison to past efforts; and offers a roadmap to creating the CEE Language Specifications."

We have been working on this baby for a long time, but it was "in approval" for loooonger....

Monday, February 25, 2008

View on CEE from Burton

Burton's Dan Blum has posted an interesting article "Prospects Brightening for a Common Event Standard," which covers CEE log standard progress as well as connections between CEE and OpenXDAS effort (which aims to standardize OS audit events - one of the most chaotic domains of the Log Realm :-))

Tuesday, February 12, 2008

CEE Log Standard Update

OMG, I forgot to blog it! :-) Here is my "CEE Logging Standard: Today and Tomorrow" presentation given at Security Forum & Identity Management Forum meeting at 17th Enterprise Architecture Practitioners Conference by OpenGroup in San Francisco (Feb 2008)

In this presentation I explained the CEE logging standard to the OpenGroup folks and also shared where the standard effort currently is.

Another CEE standard update: public mailing list archives are public and online (thanks, MITRE folks!) - now you can watch all the pillow fights we have on the list :-)

Friday, September 14, 2007

Cook Your Own Log Standard in 30 Minutes or Less

Remember the classic about underpants gnomes business plan, specifically:
  1. "Collect Underpants
  2. ???
  3. Profit!"
Here is similar guide, inspired by a recent vendor monkey activity:
  1. Register a domain, which includes "open" and "log" and something else (openlogunderpants.org - it MUST be a .org! - will do just peachy).
  2. Put some content up that explains that you will concur the world and also solve the hard problem of log standardization in the process; do NOT - I repeat, NOT! - forget to utter the dreaded "C-word" of immense power - compliance.
  3. Create a PDF document describing one of the existing log formats, such as as syslog or W3C (but do change a few minor things around, just for fun!). The key here is low embarrassment value. If you are smart, you'd also say "taxonomy" at least once.
  4. Code a convenient "show me yours and I will show you mine" page to collect the info of those who want to download the above PDF (you can't be too open, you know!)
  5. Issue a press release that claims that you have achieved god-like status and everybody in the whole worldzoo supports you and is just as excited.
  6. ???
  7. Profit?!
OK now. MITRE CEE log standard effort might be slow (make that reeeeeeally slow...), but it is here and there is active work being done on this real standard. Why embarrass yourself with a fake standard at this point is totally beyond me ...

UPDATE: one of my readers suggested that I need a picture of underpants to go with it, but - you know what? - it would be ... below me :-)

UPDATE2: if you care to see more factual analysis of this "standard," go here where a new rift of an asshole is being ripped right through its center :-)

UPDATE3: another great analysis of this so-called "standard" is here. I wish I can also quote what some smart people on the CEE mailing list said about it :-)

Thursday, July 05, 2007

Update on CEE

A quick update on CEE (official website which will be along the lines of cee.mitre.org is still not up - government, you know :-)). A working group (cee AT mitre.org) is set up and, well, working. The discussion now is about which existing log-related standards CEE should learn (and borrow from); we are tracking a large number of mostly dead standards and standard attempts/efforts.

Friday, June 08, 2007

CEE vs XDAS

By contrasting CEE with XDAS, Raffy clearly makes the point that CEE is needed.

Yes, SDEE, CEF, IDMEF, XDAS, BEEP, CIDF, CBE exist (some existed). But they have very little impact on the world! CEE will make an impact!

Wednesday, May 02, 2007

My Impressions of SANS Log Management Summit 2007

So, as I mentioned before (here and here), I attended a recent SANS Log Management Summit 2007. Here are my notes and impressions.

First, I really enjoyed the event, both from speaking and listening point of view. I did two panel presentations (one on log management implementation issues and one "vendor shootout") as well as my "award-winning" :-) Lunch and Learn presentation on choosing a log management approach: buy, build or outsource (or combine!). Vendor shootout panel also was pretty exciting (unlike one last year where one of our competitors sent a sales weenie masquerading as a "CTO" who spouted drivel for, like, 15 minutes :-)); we got some fun questions (like "name one feature that you do WORST!?") as well as fun answers. While cynics might grumble that vendors only go to such events for competitive information, the panel was genuinely interesting and thought-provoking.

Among other interesting observations, I noticed that logging for operational uses was much better represented and more frequently mentioned compared to last year; logging for security and compliance were certainly there in full force, but logging for operational uses, which is the oldest, classic use for logs, seems to be making a comeback and people really buy (or build - and then suffer :-)) log management tools to deal with the challenge.

On the market side, Summit pretty much proved that there is a log management market now with its own players, requirements, use cases, etc. At the same time, buyers are much more aware of what they are actually signing up for when they call a log management vendor. Still, I saw a share of people who made really bizarre decisions in regards to their logging...

Also, I was excited that Stephen Northcutt mentioned the MITRE CEE logging standard project, that I've been involved in (since before its name got changed from a more exciting one - guess it! :-) - to this bland "CEE"...) Log standards are definitely way overdue. Even a simple "what should be logged" recommendation (part of CEE, of course) will come incredibly handy.

Finally, somebody asked me how did the summit compare to last years? I liked this one a bit more; content was a bit more useful (even though, obviously, not new to me) and there was much less confusion about what log management actually is (e.g. much less SIEM dirt was thrown around :-)).

Other people's summit notes are here (I am sure more will be posted soon and I will update this)

Wednesday, April 18, 2007

Finally, Common Event Expression (CEE) is Out!!!

After long months of undercover work, CEE is ready to be presented to the world. Keep in mind, you read it here first!

Below is an excerpt from a brochure, to be published at MITRE's site any day now. I do think that the world is ready for another battle for the establishment of a logging standard, after a long string of miserable failures.

"Common Event Expression (CEE™): A standard log language for event interoperability in electronic systems.

CEE standardizes the way computer events are described, logged, and exchanged. By utilizing a common language and syntax, CEE takes the guesswork out of even the most menial of event- or log-related tasks. Tasks including log correlation and aggregation, enterprise-wide log management, auditing, and incident handling which once required expensive, specialized analysts or equipment can now be performed more efficiently and produce better results.

Why CEE?

If multiple systems observe the same occurrence, it should be expected that their description of that event is identical. When combined with relevant event details (time, source, destination), a computer should be able to immediately determine whether two or more logs, data logs, audit logs, alerts, alarms, or audit trails refer to the same event. In order to make this happen, there needs to be a scalable, well-defined way to express events."

I will post more stuff as well as the link to the brochure, when it is available. Next: four areas of log standardization, recommended by CEE. Stand by!

Dr Anton Chuvakin