IEFRA_ — Add (new) security considerations section

In general, I think it could be useful for such a document to have a security considerations section that outlines in broad terms some of the major security assumptions (and associated risks) that are applicable. For example, elsewhere in the body of the IEF RA it notes that a secure messaging bus is necessary, and that this separates the traffic from other traffic and provides protection. Another example might be how external services can be trusted, and how far vulnerabilities could propagate through the system (e.g. issues with key strength, algorithms etc, CA issues etc) and how such issues might be detected. Another item might be prevention of bypassing proxies (e.g managed in most cases via prior encryption). These high level notions are not implementation specific but are assumptions for the overall architecture, and also relate to implementation.

Proposal for IEFRA-9

This is a specification on data protection - addressing all related data, platform and network security assumptions and risks cannot be accomplished in a paragraph or two - and beyond the scope of this reference architecture.

The tolerance for risk and selection technology for each supporting service (IdM, Access Controls, Crypto, ...) is at the discretion of the user. I have a book "Information Security Management Handbook - ISBN-10: 0-8493-7495 -2" providing 3300 pages of description on the suggested topics - not sure what could be said in a couple of paragraphs that would cover the scope of these topics. Take this up in RTF - and see if someone can suggest something useful. Dozens of other books in the library as well - many with differing approaches.

I am really concerned with the scope the IEF has been asked to incorporate over the years.

------
FTF 2

This is the response from FTF1 - the issues as resolved as an FTF2 issue IEFRA-93. A discussion with the FTF AB Reviewer clarified the expected scope, which was less onerous then anticipated. Addressing this issue was central to initiating FTF -2. It was felt by the submitters that is was a key issue to address.