OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [chet.ensign@oasis-open.org: [members] Security Considerations section added to OASIS standards track document templates]


This might be relevant. At least the PLATFORM_IOMMU
does affect security. Behaviour around reset might
also leak information. If anyone has the cycles, this
might be a good thing to add to the spec.


----- Forwarded message from Chet Ensign <chet.ensign@oasis-open.org> -----

Date: Tue, 26 Jun 2018 14:24:11 -0400
From: Chet Ensign <chet.ensign@oasis-open.org>
To: members@lists.oasis-open.org
Cc: Ask The TAB List <tab-askthetab@lists.oasis-open.org>
Subject: [members] Security Considerations section added to OASIS standards track document templates
Message-ID: <CAAwgnnPvq0SeF9tf-cx7L9+=93EH3sUud9ADJMxxS5DgWB1dGw@mail.gmail.com>

OASIS members, especially spec editors, 

Security is growing to be a top concern in today's decentralized and highly
intertwined networked world. Obviously, the work everyone does at OASIS can
affect how secure -- or insecure --an implementing system may be. 

In light of this and to help encourage explicit documentation of security
issues in your work, TC Admin, with the help of the OASIS Technical Advisory
Board, has added a new section titled "Security Considerations" to the
standards track working draft template. 

The section is not required but we strongly recommend giving the subject
serious thought before dismissing it! While it may not be immediately obvious
how your specification might make systems vulnerable to attack, most
specifications, because they involve communications between systems, message
formats, or system settings, open potential channels for exploit. IETF RFC3552
[1], for example,  lists “eavesdropping, replay, message insertion, deletion,
modification, and man-in-the-middle” as well as potential denial of service
attacks as threats that must be considered in their works. 

Also, depending on your downstream plans for your work, you may find this
content required. For example, you will need to address it explicitly if you
apply for IANA media-type registration.  

Note also that this is a starting point. We expect that guidance in this area
will evolve over the next year or so. 

You don't need to wait for your next work product to take this up. We encourage
TC members to review IETF RFC3552 "Guidelines for Writing RFC Text on Security
Considerations" and consider how it may apply to the work you have underway
now. 

Please let us know if you have any questions Feel free to contact me or send
email to tab-askthetab@lists.oasis-open.org. 

Our thanks to Bret Jordan of Symantec for the suggestion.  

/chet 
----------------

Looking forward to Borderless Cyber 2018, 3-5 Oct, Washington, D.C.
Organized by The World Bank, OASIS, and Georgetown University

Chet Ensign
Chief Technical Community Steward
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 

----- End forwarded message -----


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]