Stories of the Journey

With NIST SP 800-160 Volume 1 Revision 1 Engineering Trustworthy Secure Systems coming out on Wednesday the 16th, thought sharing some anecdotes of the journey was in order. I think these are "authorized" to tell or maybe more accurately not unauthorized, so Ron Ross 's forgiveness won't be needed. Plenty of stories to tell, so maybe others will come out at later dates.

Kind of randomly ... if this isn't that interesting, please at least don't skip a kind of best saved for last story IMO ... jump to the end if you get bored.

In the beginning

If you're curious how I came to be involved, short version here. If not ... jump to the next section.

I came to MITRE in 2014, and my first assignment was with an Air Force project run out of the Life Cycle Management Center - roughly speaking dealing with improving the Air Force's systems security engineering practice (the effort was a precursor to what is now known as "Air Force CROWS"). First week I virtually meet Michael McEvilley, who was working the off and on effort of what became NIST SP 800-160 (later retitled "Volume 1"). Fast forwarding past how, Michael and I found a synergy together that has led to many collaborations, and Michael would often "borrow" some time to talk through elements he was writing and asked me to do some reviews of pages - some his, some other authors (Janet or Ron) as Michael sometimes had a feeling things weren't quite right but figured I could help him get the finger on the issues. Michael did pass on about our engagements, so Ron knew of me.

To simplify things quite a bit, fast forward to about two years ago, Wanting Michael again if he could get him, Ron submitted a SOW to MITRE to bid to (using existing IDIQ like contract NIST has with MITRE) which came to Michael to help write the response ... writing those sorts of things and that kind of "management" work pushed redirected to me ot led the MITRE response.

Rinse and Repeat

One not so fun task that fell to me on the team was to monitor changes in references. We pulled and cited a number of references with periodic changes, some predictable, some not. These happened before the January IPD, June FPD, and done in August as well (let us know if something changed between August and November). When heard or stumbled across one that changed a search and set of changes would occur as well.

One kind of fun one was when a new CNSSI 4009 came out in March. The IA Glossary changed all but one term we cited from it in drafts - and all were shifts not fitting our engineering needs and equities perspectives, so had to find or create new definitions suitable for our engineering context.

What was fun about it you ask? I checked what definitions CNSSI 4009 cited from NIST SP 800-160 Volume 1 and if we had changed them ... and of about 7 or 8 terms - all but one we had changed to satisfy our revision objectives or to move to citing international standards definitions. An unintentional tit for tat.

So, we cite from CNSSI 4009 only their definition of anti-tamper, and the only definition cited from Vol 1 by CNSSI 4009 that they don't have to address a change for is body of evidence. I did send an e-mail about the result to Michael and Ron and asked tongue-in-cheek if we should change our definition of body of evidence to mess with them - appropriately answered with the sound of crickets.

Wait, maybe that was a good idea after all

About 13 months ago, we had a "friends and family" review of an almost complete draft while we worked revising chapter 3 (that was long and laborious!). We got this one comment from the family review about splitting up chapter 2 - which we dismissed at the time quickly.

With the January IPD comments, standing back and looking at it, we realized that while we had made some quite major revisions in content, from the comments it was clear we should have made more adjustments to the outline/structure than we had done. To use a biblical analogy, we had poured new wine into an old wineskin. the old suggestion about splitting the IPD's chapter 2 was pulled out from the back of the virtual drawer.

Interesting validation

So in our storming and norming, Ron, Michael, and I came up with some objectives, goals, aims, formalized vision, etc. for Volume 1. Really informal, we did do a kind of writing down for the friends and family review and Ron reused that in the "notes to reviewers" in the Initial Public Draft.

About six weeks in, well before the formal documentation for external parties but after we had our meeting notes and e-mails on the vision, I got a hold of a paper at #INCOSE IS 2021 on roadmap concepts for Security in the Future of Systems Engineering (Security in the Future of Systems Engineering (FuSE), a Roadmap of Foundation Concepts - Dove - 2021 - INCOSE International Symposium - Wiley Online Library). About 11 concepts and a documentation of six objectives, aligned to much of what would come out in INCOSE Systems Engineering Vision 2035 months later. And ... no conflicts.

We ended up citing the roadmap paper just a couple of times. What kept us from citing it more is it is more forward looking than we aimed for with the special publication, but if you look closely, you see we're aligned to the implicit roadmap of that paper. I've since become active in the INCOSE Security in FuSE project being invited in - a core tenet in the group is "the future is now, it is just not evenly distributed". Much of the SP captures some of that unevenly distributed thinking.

FYI - the roadmap article is behind a firewall - a reflection of NIST standards in citing. INCOSE doesn't hold exclusive rights to the article, however. I have a copy with permission to freely share, and the principal author has it posted to his website - I'll dig it up and post the link in comments.

Unless otherwise stated, all views expressed are mine and don’t necessarily reflect those of my employer.