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:]
> Sent: Friday, 15 June 2001 17:35
> To: Michael Zolotarev;
> 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.
