[CESG] Issues with SM&C MO Ref Model, CCSDS 520.1-P-1.1, as identified in CESG poll CESG-P-2021-04-002

Shames, Peter M (US 312B) peter.m.shames at jpl.nasa.gov
Wed Jun 30 18:00:15 UTC 2021

Dear Mehran and the SM&C WG,

Yesterday, on 29 Jun 21, you held an SM&C WG meeting where one of the topics on the agenda was the CESG Poll results on SM&C MO Ref Model, CCSDS 520.1-P-1.1, as identified in CESG poll CESG-P-2021-04-002.  Since I had voted to disapprove this document, for a set of clearly stated reasons, I did you the courtesy of coming to the meeting so that I could answer any questions and clarify any concerns you might have.  From my point of view the outcome of that meeting was quite unsatisfactory, and I wish you all to understand why.  I would not normally take the time to do this, but in this situation a clear and unambiguous response seems warranted.

I’m going to start by providing a little background about where I am coming from since there appears to be a lack of understanding of the role that I, and all other CESG members, play in CCSDS processes.  I am the CCSDS Systems Engineering Area Director (SEA AD).  As such I am responsible for the SEA and the Security WG which is within that Area.  As one of the six CCSDS Area Directors (AD) I am also a member of the CCSDS Engineering Steering Group (CESG), which has responsibility for reviewing and approving every single document that the CCSDS produces.

It seems that I must remind you that the CCSDS Organization and Processes document, CCSDS A02.1-Y-4, guides and controls all of our work.  I have taken the liberty of extracting, and underlining, the key sections that you appear to have forgotten or are unaware of: CESG Operating Principles
d)  Consistency. An important job of the CESG is to watch over the output of all of the WGs to help prevent CCSDS specifications that are at odds with each other. This is why ADs and DADs are required to review the drafts coming out of Areas other than their own as part of the consensus process leading up to their adoption into the program of work. The quality of the CCSDS Recommended Standards comes both from the review that they get in the WGs and the review that the WG products get from the CESG.
e)  Anticipation. The CESG must be able to look ahead and anticipate new standards that stakeholders will most likely require, and begin prospective planning for their development so that there is sufficient time to complete them once a hard requirement emerges. This implies working with technology and experimental communities to vector research resources into the standardization process.
And CESG Responsibilities
The CESG is specifically responsible for the following:
a)  maintaining and upholding the overall technical quality and consistency of the evolving set of CCSDS Recommended Standards and Practices;
b)  providing the CCSDS-wide forum where the work programs of the Areas may be coordinated and synchronized in the context of an overall architecture for space- mission cross support and the needs of individual customers;
i)  periodically reviewing the technical work of each Area to ensure that it is progressing toward common goals, that the process of consensus is being observed and that the needs of CCSDS stakeholders (2.2) are being satisfied in a timely manner (the ADs shall be responsible for reporting on all work items within their Area);
j)  identifying “red flag” items where technical work in a proposed CCSDS document is not of the required quality or nature, where technical work is not progressing satisfactorily, where resources are inadequate, or where significant issues exist, and raising these to the attention of the CMC for corrective action;
I am providing this as a reference because you seemed to be of the impression that having a discussion between the SM&C WG and the Sec WG three years ago was sufficient “to disposition” the security and other issues that I identified in my PID.  It is not.  And, as we shall see, the earlier interactions with the SecWG did not, in any event, “disposition” the issues that were raised three years ago (Fall 2018).  Based on my review it is clear that these issues remain and they are viewed by me, and the SecWG, as being even more serious now than they were then.

An abbreviated form of the key issues that I raised in the CESG PID were these:

There are two major issues that must be contended with, and neither of them are adequately addressed: 1) The SM&C MAL is undergoing a major revision, one of which is to remove the COM, but that is not addressed; 2) a solid security approach, for single systems, but most especially for multi-mission systems, is essential, but the mechanisms in this document remain vague, weak, and poorly articulated.

Since one of the stated desires is to use this framework for major, multi-mission, and multi-agency, deployments we also looked at it from that point of view.   The following comment, quoted from one [SecWG] reviewer, should provide further insights:

"I have read all the MO books and followed the SM&C WG for ten years now (although its meetings always conflict with my own WGs).  When I have a hard time figuring out how security fits into MO services, a non-CCSDS reader can expect even more difficulty.

JSC gave up active participation in SM&C WG due to a perceived lack of ROI for our missions.  Compared to the mature operational capabilities already implemented for ISS in custom software, MO services were viewed as redundant.  The single most important features deemed lacking, which would have recommended MO above a custom implementation, were precisely those security capabilities necessary to support multiple complex missions across multiple agencies/contractors each with their own access restriction requirements.  But work on MO security services has been deferred indefinitely by the SM&C WG (and reading the MO 2.0 list of topics, appears to be absent yet again).”

Another point to be made, in the context of CCSDS "reference model" Magenta Books is that MB are intended to be normative content.  This permits them to not be "directly implementable", but it also requires that they "provide normative, controlling, guidance rather than purely descriptive material."  While the word "normative" is used a lot, and there is liberal use made of UML diagrams, which give the appearance of concrete recommendations, on closer examination all of the figures are abstractions and there are really no concrete examples to reference and tie these abstractions to reality.  At almost every turn these very real concrete concerns are just dismissed as "implementation" or "deployment" details.  This makes the document vague and does not provide concrete examples to substantiate that the stated claims can be achieved.  This is especially true of the security sections, but it is also true throughout, particularly where multi-mission deployments are considered.
I am going to just focus on the security issues for now, but the others also remain unresolved.  During the telecon you asserted that the SM&C WG had met with the SecWG three years ago and that all of the security concerns that they had raised at that time had been resolved.  I told you that even though I do have a strong background in distributed systems architectures and secure systems I had consulted with members of the SecWG just prior to submitting my PID.  They confirmed my concerns and completely supported my analysis.
Because of your statements just after the SM&C meeting on Tuesday, 29 June, I again contacted the SecWG to determine what their knowledge was of the situation.  These are the replies I  got:

From: "Biggerstaff, Craig (JSC-CD42)[SGT, INC]" <craig.biggerstaff at nasa.gov>
Date: Tuesday, June 29, 2021 at 10:17 AM
To: Howie Weiss <Howard.Weiss at parsons.com>, Peter Shames <peter.m.shames at jpl.nasa.gov>, "Sheehe, Charles J. (GRC-LCN0)" <charles.j.sheehe at nasa.gov>
Cc: "Radulescu, Costin (US 9300)" <cradule at jpl.nasa.gov>
Subject: RE: [EXTERNAL] RE: Issues with SM&C MO Ref Model treatment of security topics

Security analysis produced by ESA, posted in the SM&C WG meeting materials from Fall 2018:

·       https://cwe.ccsds.org/moims/docs/MOIMS-SMandC/Meeting%20Materials/2018/Fall/MOS_Security_CCSDS_161018.pptx?d=w6be12e1a154d41a7b3fe4a126d59adde<https://urldefense.us/v3/__https:/cwe.ccsds.org/moims/docs/MOIMS-SMandC/Meeting*20Materials/2018/Fall/MOS_Security_CCSDS_161018.pptx?d=w6be12e1a154d41a7b3fe4a126d59adde__;JQ!!PvBDto6Hs4WbVuu7!ZASh8ARy3w73YAeFEYVr5ReOkHVZ9zONUObvTqad9T6Cd0q3CPf5BB6B9ADG18oVUXI$>

More security analysis produced by ESA, posted in the SM&C WG meeting materials from Fall 2019:

·       https://cwe.ccsds.org/moims/docs/MOIMS-SMandC/Meeting%20Materials/2019/Fall%202019/Security_Authentication%20and%20Access%20Control%20for%20MO%20Services_final.pdf<https://urldefense.us/v3/__https:/cwe.ccsds.org/moims/docs/MOIMS-SMandC/Meeting*20Materials/2019/Fall*202019/Security_Authentication*20and*20Access*20Control*20for*20MO*20Services_final.pdf__;JSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZASh8ARy3w73YAeFEYVr5ReOkHVZ9zONUObvTqad9T6Cd0q3CPf5BB6B9ADGFD2KSgo$>

·       https://cwe.ccsds.org/moims/docs/MOIMS-SMandC/Meeting%20Materials/2019/Fall%202019/Security_Proposed%20modification%20of%20standards_final.pdf<https://urldefense.us/v3/__https:/cwe.ccsds.org/moims/docs/MOIMS-SMandC/Meeting*20Materials/2019/Fall*202019/Security_Proposed*20modification*20of*20standards_final.pdf__;JSUlJSU!!PvBDto6Hs4WbVuu7!ZASh8ARy3w73YAeFEYVr5ReOkHVZ9zONUObvTqad9T6Cd0q3CPf5BB6B9ADG0IOL8Yo$>

You will find many of the same issues in these documents that Howie and I identified in reply to your email.  I could not find any SM&C WG meeting minutes that mentioned that a security discussion occurred, much less listed any actions.


From: Weiss, Howard <Howard.Weiss at parsons.com>
Sent: Tuesday, June 29, 2021 10:53 AM
To: Shames, Peter M (JPL-312B)[JPL Employee] <peter.m.shames at jpl.nasa.gov>; Sheehe, Charles J. (GRC-LCN0) <charles.j.sheehe at nasa.gov>; Biggerstaff, Craig (JSC-CD42)[SGT, INC] <craig.biggerstaff at nasa.gov>
Cc: Radulescu, Costin (JPL-9300)[JPL Employee] <cradule at jpl.nasa.gov>
Subject: Re: [EXTERNAL] RE: Issues with SM&C MO Ref Model treatment of security topics



From my recollections, we last met with them at the NASA/Ames meeting a couple of years ago.  Daniel Fischer typically acted as the liaison between Security and SM&C, mostly because he worked for Mario and Mario had been the head of SM&C.  From a technical perspective, we mostly worked with Sam.  I believe we gave them a very detailed list of issues at the Ames meeting but I'd have to dig around to see if I have it.  Daniel, as the primary interface, might have more than I have.  I remember that the list of issues was lengthy and detailed.


7110 Samuel Morse Drive
Columbia, MD 21046
443-430-8089 (office) / 443-494-9087 (cell)
howard.weiss at parsons.com<mailto:howard.weiss at parsons.com>
Please consider the environment before printing this message


I downloaded the presentation and the paper that Daniel Fischer and his colleagues from ESA had provided back in Fall 2018 and again in Fall 2019.  In their analyses they identified, and carefully documented, the very same issues that I had raised.  And they described the basis of their concerns in even greater depth, pointing out that the documented SM&C security mechanisms are susceptible to even fairly primitive “man  in the middle” attacks, let alone more sophisticated approaches.  At that time, three years ago, they also proposed specific fixes and extensions that could have been adopted to fix these problems.  It appears that these issues were swept aside then, much as you chose to do yesterday.   It also seems clear, given what was in the document and SM&C plans presented in the last CESG and CMC meetings, that in the intervening three years nothing has been done, and according to you, there are no plans to fix this now.
I must conclude that the statements you made yesterday about “We met with the SecWG 3 years ago and they agreed that we did everything we needed to.” were inaccurate and rather misleading.  In point of fact these same issues remain, the limitations of not having adequate security for multi-mission systems remans, and the potential consequences of not having adequate security have increased.   I must also point out that the way that these issues were handled,  previously, and in yesterday’s meeting, are in violation of CCSDS principles for consensus operation.  There is no part of the documented CCSDS process that says “ignore issues and brush them aside”.
I do not believe that we can allow these issues to be ignored any longer,  and that the CESG, as the appointed guardians of CCSDS architecture, processes, document content, and quality, must insist that these issues are remedied before this document can be published.
Regards, Peter Shames


Peter Shames
CCSDS Systems Engineering Area Director

Jet Propulsion Laboratory, MS 301-490
California Institute of Technology
Pasadena, CA 91109 USA

Telephone: +1 818 354-5740,  Fax: +1 818 393-6871

Internet:  Peter.M.Shames at jpl.nasa.gov

We must recognize the strong and undeniable influence that our language exerts on our ways of thinking and, in fact, delimits the abstract space in which we can formulate - give form to - our thoughts.

Niklaus Wirth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20210630/91c0fab8/attachment-0001.htm>

More information about the CESG mailing list