[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Things to do - Requirement Document. Security.
Michael, Thanks - good work. I am traveling today from UDDI meeting. By next week, I will add your work to the requirements doc. As you have been thinking about it, in your mind what other sections need to be there ? cheers |-----Original Message----- |From: Michael Zolotarev [mailto:michael.zolotarev@baltimore.com] |Sent: Friday, June 22, 2001 12:45 AM |To: Krishna Sankar; Michael Zolotarev; |election-services@lists.oasis-open.org |Subject: RE: Things to do - Requirement Document. Security. | | |Hi, |The attached is [a very rough cut of] the security requirements for generic |Vote and Ballot tokens. |It doesn't mention the identification and audit - I don't consider them to |really belong there, in the security section. |Any comments are welcome. << I know that English is not perfect. Feel free |to fix it>> | |Regards |Michael | |> -----Original Message----- |> From: Krishna Sankar [mailto:ksankar@cisco.com] |> Sent: Friday, 15 June 2001 17:35 |> To: Michael Zolotarev; election-services@lists.oasis-open.org |> Subject: RE: Things to do - Requirement Document. Security. |> |> |> Michael, |> |> Good thoughts. Couple of observations: |> |> |suggest we change the pitch of the message from "SHOULD |> allow" and "SHALL |> |facilitate" to more permissive and broader "SHOULD NOT |> prevent" and "SHALL |> |NOT make impossible". |> | |> |> Sounds fine. But there would be many requirements which |> we might have to |> express in active voice. |> |> |know - the major participants and items, and associated security |> |expectations. |> |> Keep in mind that we are talking about the requirements |> of a voting system, |> not just security. So if there are non-security requirements, |> let us capture |> them and move them to another section in the requirements document. |> |> | identification and traceability: << not quite a |> security issue, though>> |> | audit, identification and traceability: << not quite a |> security issue, |> though>> |> |> We need these. Again, we are looking at all |> requirements, not just |> security. Identification, audit et al are security functions anyway. |> |> |Structuring security requirements this way will allow |> keeping it short and |> |sweet, and hopefully better associated with the overall picture. |> |> Short, may be not. Sweet, depends :-) But I have no |> problem if you want to |> restructure the points. Actually I was writing them as a |> straight list to |> stimulate thoughts and didn't mean any organization. |> |> |I believe that vote-casting environment should not be |> included into the |> |security discussion. It has nothing to do with tokens/protocols. |> |> Again, we need to touch upon the vote casting |> environment in general terms |> in the requirements section. The more generic the better, but |> still need to |> include any assumptions, requirements, ... |> |> cheers |> |> |> |> |> This footnote confirms that this email message has been swept by |> MIMEsweeper for the presence of computer viruses. |> | | | |------------------------------------------------------------------- |---------------------------------------------- |"How can I make sure the right people get access to the right resources |and business applications, with a user base that's constantly growing and |changing?" |The answer... |Baltimore SelectAccess |Next Generation Authorisation Management |http://www.baltimore.com/selectaccess/index.html |------------------------------------------------------------------- |---------------------------------------------- |The information contained in this message is confidential and is intended |for the addressee(s) only. If you have received this message in error or |there are any problems please notify the originator immediately. The |unauthorized use, disclosure, copying or alteration of this message is |strictly forbidden. Baltimore Technologies plc will not be liable |for direct, |special, indirect or consequential damages arising from alteration of the |contents of this message by a third party or as a result of any |virus being |passed on. | |In addition, certain Marketing collateral may be added from time |to time to |promote Baltimore Technologies products, services, Global e-Security or |appearance at trade shows and conferences. | |This footnote confirms that this email message has been swept by |Baltimore MIMEsweeper for Content Security threats, including |computer viruses. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC