[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti-stix] STIX: Messaging Standard vs. Document Standard
Jerome - Trying to put some context around what I'm seeing in the paper - What is being proposed is really a replacement for TAXII, no? Is that what is being discussed in the TAXII group currently? -----Original Message----- From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jerome Athias Sent: Monday, December 14, 2015 1:21 AM To: Jordan, Bret Cc: Patrick Maroney; Terry MacDonald; Jason Keirstead; Richard Struse; cti-stix@lists.oasis-open.org; Wunder, John A. Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document Standard A recommended read, interesting from multiple point of views for CTI, but in the context of this thread, mainly regarding these points: Message-oriented Architecture Resource-Oriented Architecture https://tools.ietf.org/html/draft-ietf-mile-rolie-01 NB: You could also find interesting elements for TAXII 2015-12-12 9:51 GMT+03:00 Jerome Athias <athiasjerome@gmail.com>: > Attached is an OLD draft (so not updated and with errors) diagram from 2012. > (This is a good one in case it helps https://github.com/google/capirca > ) > > NB: Mitigation is not Remediation > > (PS: and really far from me to say that it matters in any way! > But, because we don't share our resumes. I would just say that I am a > 36 years old Otaku/Hacker [1] who started manipulating computers 25+ > years ago, and who probably spent in average 8 plenty hours a day > (including week-ends and vacations) on these automatons during the > past 10/15 years) > > > [1] 1. A person who enjoys exploring the details of programmable > systems and how to stretch their capabilities, as opposed to most > users, who prefer to learn only the minimum necessary. RFC1392, the > Internet Users' Glossary, usefully amplifies this as: A person who > delights in having an intimate understanding of the internal workings > of a system, computers and computer networks in particular. > 2. One who programs enthusiastically (even obsessively) or who enjoys > programming rather than just theorizing about programming. > 3. One who enjoys the intellectual challenge of creatively overcoming > or circumventing limitations. > > > 2015-12-01 3:46 GMT+03:00 Jordan, Bret <bret.jordan@bluecoat.com>: >> Nice diagram. One thing I am working on internal to BC is to get it >> so you can send your STIX indicator / CybOX object to the Solera >> Security Analytics device and do automatic retrospective analysis. >> This will allow you to see if you have seen said object before. This would fit in to this work flow >> nicely, I believe. Another area would be in automatic remediation, aka >> sent a STIX indicator / CybOX object with a Coarse of Action to your >> Proxy and tell it to block that traffic. >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 >> 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, >> however, the only thing that can not be unscrambled is an egg." >> >> On Nov 30, 2015, at 17:41, Patrick Maroney <Pmaroney@Specere.org> wrote: >> >> re: " Now lets talk about work flow and how this information is going >> to flow around the network, how it is going to flow in to vendor tools, " >> >> Here is one Reference Implementation for consideration/discussion: >> >> <6DB53CE0-AB02-4DDD-ABB7-4A2A7FCD92B2.png> >> >> Patrick Maroney >> Office: (856)983-0001 >> Cell: (609)841-5104 >> >> <C690F973-64C5-4C00-889B-C1A5BB4A2A0B[6].png> >> >> President >> Integrated Networking Technologies, Inc. >> PO Box 569 >> Marlton, NJ 08053 >> >> From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan >> <bret.jordan@bluecoat.com> >> Date: Monday, November 30, 2015 at 7:25 PM >> To: Terry MacDonald <terry@soltra.com> >> Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Richard Struse >> <Richard.Struse@HQ.DHS.GOV>, "cti-stix@lists.oasis-open.org" >> <cti-stix@lists.oasis-open.org>, John Wunder <jwunder@mitre.org> >> Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document >> Standard >> >> You are correct, some organizations will do it in-house, some will >> outsource, and I will add that some will just not care. We have an >> amazing group that does APT research and has a massive amount of >> internal data mining tools to find this sort of stuff. We help a lot >> of the biggest companies and governments solve these problem, every day. >> >> Some organizations that outsource or do things internally MAY share >> sightings or things back within their eco-systems, or they may even >> share with certain government groups. But their own legal >> departments and general councils will dictate what they can share and with whom they can share it. >> >> Remember getting a huge repo of STIX data, in your Soltra Edge device >> is NOT going to magically make you any more secure. You need vendor >> products that sit inline in your network that can actually DO something with that data. >> Those products typically only understands what we call CybOX objects. >> They do NOT understand nor care about higher level things. We humans >> and analysts and big data intelligence platforms do care about higher >> level things. It helps us figure out what is going on, and REALLY >> helps in retrospective analysis of an attack. >> >> Lets put this in real world terms... Government or vendor XYZ discovers >> that threat actor Ivan is launching an attack against executives of >> high tech companies in Silicon Valley. They believe Ivan is going to >> use Whale Phishing based on the latest Audi and BMW cars. >> >> This is great information. Now lets talk about work flow and how >> this information is going to flow around the network, how it is going >> to flow in to vendor tools, how it is going to flow in to user >> awareness programs and training programs. >> >> And maybe, just maybe, some organizations might send some data back >> or share pieces of information that they learn. We do this today. >> We have interconnections with lots of groups where we share data back and forth. >> This is not new. We have been doing this for 14 years. >> >> Lets focus on workflow and how we can make an analysts life easier >> and make vendor product use and understand the data they can. >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 >> 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, >> however, the only thing that can not be unscrambled is an egg." >> >> On Nov 30, 2015, at 17:09, Terry MacDonald <terry@soltra.com> wrote: >> >> Bret, >> >> I foresee that Organizations will share data between their own >> internal tools (to understand threats and look for indicators of that >> threats) most often. It’s not all about sharing that information with >> external parties. An Organization needs to do both in order to make >> best use of Threat Intelligence. They need to join those two >> processes together. Threat Intelligence and Incident Response. >> >> Now a lot of Organizations will not have the ability or the >> inclination to do the Threat Intelligence gathering/sifting/etc >> required to build up a picture of the threats relevant to their >> Organization profile, but that’s not a problem. They’ll just outsource it. >> >> Organizations will outsource their threat intelligence function to >> third parties who will look for threat intelligence that matches the >> Organizations risk profile on their behalf. The organizations will >> then just get feeds of Indicators customized to their Organization, >> and will then feedback sightings they see. They will also push up any >> interesting observations they notice, and the Threat Intelligence >> providers will use that data to discern any new Threat Actors/Campaigns/malware families as needed. >> >> It doesn’t matter if the threat analysis is done in house, or is >> outsourced – the deep research still needs to be done in order to >> discover new Indicators, and to track the changes that take place >> over time. Without the deep analysis, the Indicators will soon lose >> their accuracy. And without the real-world feedback, the Threat >> Intelligence modelling will become less accurate. >> >> Each process makes the other one stronger. >> >> One thing I would like to point out is the need to move away from ‘dumb’ >> Indicator feeds, where the recipient gets a hug wall of Indicators >> that contain every bad things that the world has seen over the last 3 months. >> This won’t scale, and all it does is increase the cost to >> Organizations as they have to increase infrastructure and personnel >> resources to cope with the increased workload. Higher chances of >> false positives and less understanding of what the really important indicators are. >> >> By using Threat intelligence and an understanding of our adversaries >> , we will know who is likely to target us, and we can look for the >> things they do. We have less noise to contend with, and we spend our >> precious infrastructure and personnel resources looking for things that matter to us. >> >> Cheers >> >> Terry MacDonald >> Senior STIX Subject Matter Expert >> SOLTRA | An FS-ISAC and DTCC Company >> +61 (407) 203 206 | terry@soltra.com >> >> >> From: Jordan, Bret [mailto:bret.jordan@bluecoat.com] >> Sent: Tuesday, 1 December 2015 9:45 AM >> To: Terry MacDonald <terry@soltra.com> >> Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Richard Struse >> <Richard.Struse@HQ.DHS.GOV>; cti-stix@lists.oasis-open.org; Wunder, John A. >> <jwunder@mitre.org> >> Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document >> Standard >> >> Re: It’s a symbiotic relationship! >> >> It is only a symbiotic relationship, if the two organizations are >> communicating. We make a LOT of assumptions that people and >> organizations are going to do anything more than just process >> indicators (meaning block them on their firewall or proxy). Most, >> honestly, do not care. They may share sighting information back to their own internal tools. But I doubt >> many will share sightings back to the larger community. The general >> council's of most organizations will prohibit that for many years to come. >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 >> 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, >> however, the only thing that can not be unscrambled is an egg." >> >> >> On Nov 30, 2015, at 14:02, Terry MacDonald <terry@soltra.com> wrote: >> >> “There is no actual reason that indicator or sighting messages need >> to be a layer on top of the ontology. They are for totally different >> use cases and can be developed completely independently.” >> >> There needs to be a relationship between the Indicators and sightings >> that are exchanged and the higher-order threat intelligence that is >> exchanged, or there is no way to relate the two levels together. The >> key important part in all of this is to be able to maintain relationships from one to the other. >> Without that ability then there is no way to do the analysis. >> >> Frode Hommedal put it best in his presentation to FIRST: >> http://frodehommedal.no/presentations/first-tc-oslo-2015. I implore >> you to read it if you haven’t already. Especially this slide. >> >> As I see it the two camps fall into these broad groups: >> · All of STIX: Threat Intelligence group >> o “We need to track everything otherwise we won’t be able to understand >> the bad guys” >> o “Everything is related to everything” >> · Indicators and Sightings: Incident Response group >> o “We don’t need to understand them, we just need to detect them damn it” >> o “I only care about Indicators and Sightings” >> >> The thing that not many people realize is that you need both, and you >> need a way of crossing from one to the other. I think this diagram I >> created >> (©Threatloop.com) demonstrates why: >> >> <image001.png> >> >> The Incident Response process needs to know what Indicators are the >> ones that your Organization needs to look for. At present monitoring >> and detection systems are struggling to operate with the number of >> indicators they need to be looking for. The Threat intelligence >> process knows what threats are most likely…. So wouldn’t it be >> sensible to use the Threat Intelligence process to generate/filter >> the Indicators so that the Incident Response process has a far >> smaller number of things and more important things to look for? >> >> And the Threat Intelligence process need to know what the Incident >> Response process is seeing. Maybe there is a new Threat Actor in >> town? Maybe an existing Threat Actor is starting a new campaign? >> Threat Intelligence processes need to be able to record what is >> happening to be able to generate Indicators that make sense and >> follow what the real risks to the Organization are. >> >> It’s a symbiotic relationship! Both are equally important, and in >> fact are critical to improving Organization’s abilities to protect themselves. >> >> You MUST be able to map from one process to another. >> >> Cheers >> >> Terry MacDonald >> Senior STIX Subject Matter Expert >> SOLTRA | An FS-ISAC and DTCC Company >> +61 (407) 203 206 | terry@soltra.com >> >> >> From: cti-stix@lists.oasis-open.org >> [mailto:cti-stix@lists.oasis-open.org] >> On Behalf Of Jordan, Bret >> Sent: Tuesday, 1 December 2015 4:35 AM >> To: Jason Keirstead <Jason.Keirstead@ca.ibm.com> >> Cc: Richard Struse <Richard.Struse@HQ.DHS.GOV>; >> cti-stix@lists.oasis-open.org; Wunder, John A. <jwunder@mitre.org> >> Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document >> Standard >> >> I agree with Jason. >> >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards | Office of the CTO >> Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 >> 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, >> however, the only thing that can not be unscrambled is an egg." >> >> >> On Nov 30, 2015, at 08:35, Jason Keirstead >> <Jason.Keirstead@ca.ibm.com> >> wrote: >> >> Precisely. >> >> If we can agree on the below.. then work on the standardization of >> messages can be done independently of the underlying model. >> >> RE @Sean: However, I do not view these message specifications as an >> alternative or independent thing from the model/ontology. I would >> view them as a layer on top of the model/ontology that allows focused >> and explicit representation of a small subset of information from the >> model/ontology that is relevant for a given exchange use case. >> >> I disagree here - this is why we are having such a hard time with the >> current paradigm. >> >> There is no actual reason that indicator or sighting messages need to >> be a layer on top of the ontology. They are for totally different use >> cases and can be developed completely independently. >> >> - >> Jason Keirstead >> Product Architect, Security Intelligence, IBM Security Systems >> www.ibm.com/security | www.securityintelligence.com >> >> Without data, all you are is just another person with an opinion - >> Unknown >> >> >> <graycol.gif>"Struse, Richard" ---11/30/2015 11:04:55 AM---So, what I >> think I’m hearing is that we envision a world where we define a >> serialization for STIX & >> >> From: "Struse, Richard" <Richard.Struse@HQ.DHS.GOV> >> To: Jason Keirstead/CanEast/IBM@IBMCA, "Wunder, John A." >> <jwunder@mitre.org> >> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> >> Date: 11/30/2015 11:04 AM >> Subject: RE: [cti-stix] STIX: Messaging Standard vs. Document >> Standard ________________________________ >> >> >> >> So, what I think I’m hearing is that we envision a world where we >> define a serialization for STIX & CybOX (let’s assume in JSON) and >> implementations can exchange “documents” using the serialization of >> the complete data model (e.g. for communicating a new TTP for an >> existing threat actor). However, in addition to this, we might >> define/standardized specialized message exchanges for a set of common >> use-cases such as indicator or indicator-sighting exchange. This >> would allow appliances, for example, to simply implement the >> use-case-specific message exchanges that make sense without having to implement the full STIX model. >> >> As a result, I foresee implementations asserting what exchanges they >> support, perhaps as follows: >> CTI-O-MATIC Threat Analysis Platform >> STIX Exchange: SUPPPORTED >> Indicator Exchange: SUPPORTED >> Indicator-Sighting Exchange: SUPPORTED >> Etc. >> >> ACME IDS 9000 Appliance >> STIX Exchange: NOT SUPPORTED >> Indicator Exchange: SUPPORTED >> Indicator-Sighting Exchange: SUPPORTED >> >> Does this make sense? >> From: cti-stix@lists.oasis-open.org >> [mailto:cti-stix@lists.oasis-open.org] >> On Behalf Of Jason Keirstead >> Sent: Monday, November 30, 2015 9:47 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document >> Standard "What about a new TTP for an existing threat actor? I would >> not want to have to do an RDF-based exchange to share that type of >> information (still holding out hope for a reasonable JSON-LD >> approach) but I’m also not sure we can build messages to cover those use cases." >> >> I believe you would indeed do a complex exchange for that. This is >> not a "messaging" use case, it is a "document share" use case. The >> difference in complexity between sharing TTP information to sighting >> information is similar to emailing a word document vs. engaging in an >> IM session. It's not the same. >> >> My point is that the huge amount of third party vendors who want to >> "speak STIX" to communicate and/or absorb indicators, observables, >> and sightings, are not interested in use cases like "TTP for an existing threat actor". >> They don't have that information, and they can't act on that information. >> You aren't going to get TTP information out of an IPS, and you aren't >> going to send TTP information to an IDS or Firewall. But you will get >> Indicators and sightings from an IPS, and you will want to send >> observables to an IDS or Firewall. >> >> These are the two different use cases - one that lends itself to a >> semantic model, and one that lends itself to a compact and coherent messaging format. >> >> - >> Jason Keirstead >> Product Architect, Security Intelligence, IBM Security Systems >> www.ibm.com/security | www.securityintelligence.com >> >> Without data, all you are is just another person with an opinion - >> Unknown >> >> >> <graycol.gif>"Wunder, John A." ---11/30/2015 10:04:36 AM---So to be >> honest I’m not yet as convinced on this approach as all of you >> (sorry). I can definitely se >> >> From: "Wunder, John A." <jwunder@mitre.org> >> To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> >> Date: 11/30/2015 10:04 AM >> Subject: Re: [cti-stix] STIX: Messaging Standard vs. Document >> Standard Sent by: <cti-stix@lists.oasis-open.org> >> ________________________________ >> >> >> >> >> So to be honest I’m not yet as convinced on this approach as all of >> you (sorry). I can definitely see the value of messages at the level >> of sightings and indicators but it seems to me like there’s a giant >> middle ground of use cases where we don’t want to define >> tightly-scoped messages but the document-based approach would still >> be a burden. For these cases I was hoping the JSON serialization of the full model would be used. >> >> For example, would we have a message to represent a new incident? >> What would the message semantics be? What about a new TTP for an existing threat actor? >> I would not want to have to do an RDF-based exchange to share that >> type of information (still holding out hope for a reasonable JSON-LD >> approach) but I’m also not sure we can build messages to cover those use cases. >> >> Jason, Jon, Mark…what do you all think about that? Would we define >> messages for that? Would we have third-party messages (i.e. my app >> can define a non-standard CTI message based on the data model)? Would we just use RDF? >> >> John >> On Nov 30, 2015, at 8:42 AM, Jason Keirstead >> <Jason.Keirstead@CA.IBM.COM> >> wrote: >> +1 to all below recommendations... exactly my line of thinking. >> >> It may or may not be more work to undertake these two parallel >> efforts - but I believe that it would allow both efforts to more >> forward in a faster and more coherent way than the current methodology. >> >> - >> Jason Keirstead >> Product Architect, Security Intelligence, IBM Security Systems >> www.ibm.com/security | www.securityintelligence.com >> >> Without data, all you are is just another person with an opinion - >> Unknown >> >> >> <graycol.gif>"Baker, Jon" ---11/30/2015 09:36:44 AM---+1 Thanks for >> thinking through the underlying issues that might be making it so >> hard to achieve cons >> >> From: "Baker, Jon" <bakerj@mitre.org> >> To: Jason Keirstead/CanEast/IBM@IBMCA, "cti-stix@lists.oasis-open.org" >> <cti-stix@lists.oasis-open.org> >> Date: 11/30/2015 09:36 AM >> Subject: RE: [cti-stix] STIX: Messaging Standard vs. Document >> Standard Sent by: <cti-stix@lists.oasis-open.org> >> ________________________________ >> >> >> >> >> +1 >> >> Thanks for thinking through the underlying issues that might be >> making it so hard to achieve consensus. I completely agree that by >> trying to develop a messaging standard and a document standard in one >> effort is a significant source of frustration for this group. This is >> how I have thought about this >> issue: >> >> >> STIX has two primary use cases >> • UC1: Holistic cyber threat analysis • UC2: Exchange cyber threat >> information Requirements for UC1 are not always conducive to >> effective information exchange >> >> My basic recommendation would be as follows: >> >> Differentiate analysis and sharing requirements • avoid overloading >> analysis model with exchange requirements • avoid overloading >> exchange with analysis requirements Develop a high level model of >> cyber threat intelligence for analysis • initially in UML, but a >> semantic representation can be developed Develop messages tailored to >> information exchange needs • each exchange has a formal specification >> • ensure messages are compatible with the analysis model • allow >> protocol and serialization to be dictated by information exchange >> needs • initially specify only a few well known and well defined >> messages • plan for many messages, but add messages over time as real >> needs are understood >> >> Thanks, >> >> Jon >> >> ============================================ >> Jonathan O. Baker >> J83D - Cyber Security Partnerships, Sharing, and Automation The MITRE >> Corporation >> Email: bakerj@mitre.org >> >> From: cti-stix@lists.oasis-open.org >> [mailto:cti-stix@lists.oasis-open.org] >> On Behalf Of Jason Keirstead >> Sent: Thursday, November 26, 2015 8:47 AM >> To: cti-stix@lists.oasis-open.org >> Subject: [cti-stix] STIX: Messaging Standard vs. Document Standard >> When I originally started this message, I had started it with a "here >> is why I am against JSON-LD" stance, but then decided to take a step >> FAR BACK and try to figure out / tease apart the fundamental reasons >> why people are both for and against JSON-LD. As a result of my >> analysis, I think am starting to figure out why there are two diametrically opposed camps here. >> >> The root I believe is that there is a fundamental disconnect between >> an ideal messaging standard and a document standard, yet STIX is >> trying to serve both masters. I am not sure that it can, and keep >> everyone happy. At any rate, I hope if everyone can read through the >> below, it will at least help each camp start to see the other's point of view. >> >> Things desired in a document standard: >> - Clarity of the source and meaning of the data >> - Readability by humans can sometimes be a factor depending on use >> cases >> - Byte-efficiency is a secondary or tertiary concern (disk is cheap) >> >> In a document standard, it is now the standard practice that the >> schema accompanies the document. This is the core tenant of JSON-LD >> and other related semantic technologies - that your data is annotated >> in a way such that it can be linked back to the schema that defined >> it, which then also allows you to infer the semantic meaning behind >> fields in the document. This lets people and systems cross-correlate >> and search documents of different types that contain fields that are >> related semantically, without having to have standard-specific code written for them. >> Things desired in a messaging standard: >> >> - Maximum byte efficiency (bandwidth is not cheap) >> - Absolutely zero ambiguity >> - Readability by humans is a secondary (or tertiary) concern, >> sometimes not a concern at all In a messaging standard, the schema >> has no reason to accompany the message, because anyone who implements >> it would have zero ambiguity anyway, and doing so greatly inflates >> the size of the messages. You also don't have to infer meaning of a >> field in a messaging standard, because the meaning is fixed and is >> not open to any interpretation. As such, semantic technologies are >> not required in a messaging standard, because they aren't even >> applicable to the use case. >> The root of our problem here and I believe why we can not come to >> consensus, is we are trying to come up with one standard that does >> both things, which are actually philosophically opposed to >> each-other. There is an extremely large community of people and >> systems who want to "speak STIX", but they have no plans to STORE >> STIX, and this could not care less about semantic representations. >> Similarly, there is a large community of people and systems who want >> to (and already have) systems with large STIX warehouses, and very >> much care about semantic representations, so that they can tie that data to other systems. >> >> Maybe we should take a step back and look at this more critically. If >> you look at what people care about from a "frequently messaged" >> perspective (namely of indicators and observable occurrences) maybe >> that should be moved under TAXII? Currently, TAXII is just a transit >> protocol and the standard of the messages is simply " a STIX >> document". I am starting to think that this is not enough and it's >> part of why we can't reach any consensus. There is no reason that >> there could not be a messaging format in TAXII to communicate >> indicators and observables that was an offshoot of STIX but not STIX >> itself... meanwhile there could continue to be a channel for full/complete "STIX documents" which are transmitted with much less frequency. >> - >> Jason Keirstead >> Product Architect, Security Intelligence, IBM Security Systems >> www.ibm.com/security | www.securityintelligence.com >> >> Without data, all you are is just another person with an opinion - >> Unknown >> >> >> --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]