RE: Things to do - Requirement Document. Security.

[Michael Zolotarev <michael.zolotarev@baltimore.com>]

Hi,

First of all, different election scenarious, different legal regulation and
laws will necessarily present different security requirements. Therefore, I
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".

Second, to make the discussion a bit more structured, I suggest we do not
concentrate on the low-granular operations - we may not know in advance all
possible permutations within the system, and should not be trying to
anticipate finer details of it. Instead, I propose we concentrate on what we
know - the major participants and items, and associated security
expectations.

Something like that:
Voter:
	privacy/anonymity: << list of issues here >>
	authentication:<< list of issues here >>
	non-repudiation:<< list of issues here >>
	
Ballot:
	privacy:<< list of issues here >>
	integrity:<< list of issues here >>
	identification and traceability: << not quite a security issue,
though>>
Vote:
	privacy:<< list of issues here >>
	anonymity: << list of issues here >>
	integrity:<< list of issues here >>
	authenticity:<< list of issues here >>
	audit, identification and traceability: << not quite a security
issue, though>>

To give an example: "A structure of a vote SHALL NOT prevent a voter
identity to be incorporated into it, or be referenced by it."

Structuring security requirements this way will allow keeping it short and
sweet, and hopefully better associated with the overall picture.

I believe that vote-casting environment should not be included into the
security discussion. It has nothing to do with tokens/protocols. 

I expect that I could've missed something, or some of the issues do not
apply at all. Let me know about your thinking. Also, let me know if you
agree with the proposed structuring, and I'll populate the sceleton with the
requirements I can think of. I'll take all requirements put by Krishna which
seem to be relevant, of course.

Regards
Michael


> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: Thursday, 14 June 2001 16:25
> To: election-services@lists.oasis-open.org
> Subject: RE: Things to do - Requirement Document
> 
> 
> Hi,
> 
> 	Here are some thoughts on security requirements:
> 
> 	1.	Each voter should be authenticated.
> 	2.	Each voter should be authorized
> 	3.	Voters should be able to verify that their vote 
> is registered
> 	4.	There should be no linkage between the voter 
> and a vote. i.e. the votes
> themselves should be anonymous
> 		(Question : Should we also allow optional 
> linkage ? May be in many
> circumstances, we do want to know who voted for what.)
> 	5.	There should be no indirect voter to vote 
> linkage. i.e. this relation
> shouldn't be derivable based on some other factors (for example by
> correlating time in a log or a location or a serial number or 
> other similar
> pieces of information)
> 		(Note : This is true even when we allow direct 
> linkage. The point is
> direct linkage if allowed would be the ONLY way to link a 
> voter with a vote)
> 	6.	Each vote could have some location information 
> like a county or similar
> geographic location. This is used for statistical purposes
> 	7.	Transmission of results and other voting 
> related information should be
> secured
> 	8.	Transmission of voting should be secured
> 	9.	Security should be the first priority for 
> voting and related systems
> 	10.	The system should be able to generate, handle 
> and deliver time locked
> information
> 	11.	The system should be able to handle policies 
> which could be different
> at different locations - physical or logical
> 	12.	The policy admin privileges should be secures 
> and policy changes should
> be logged
> 	13.	The various systems should have logging and 
> auditing facilities - many
> of them capable of forming permanent and unalterable records with
> non-repudiation capabilities built-in
> 	14.	The logging and audit trails should not violate 
> other requirements like
> the anonymous voting.
> 	15.	The system should be able to catch security 
> in-consistencies for known
> voting models. i.e. the security policies of known voting 
> models should be
> pre-programmed and should not be altered
> 
> cheers
> 
> |-----Original Message-----
> |From: Krishna Sankar [mailto:ksankar@cisco.com]
> |Sent: Tuesday, June 12, 2001 6:37 PM
> |To: election-services@lists.oasis-open.org
> |Subject: Things to do - Requirement Document
> |
> |
> |Hi all,
> |
> |	This is a concise document which will have the
> |requirements. Sections would
> |include general, security, interfaces, presentation, ... We 
> would base this
> |document for developing the specifications. The goal is to develop a
> |specification which reflects the requirements.
> |
> |	We need an owner for this document as well. I can take a
> |first cut at this.
> |
> |	Please send me your ideas, suggestions, what you want to
> |see as a part of
> |the specifications,...
> |
> |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.