Re: Is Open Source Enough?

From: Fred McLain <mclain_at_zipcon_dot_net>
Date: Fri Sep 07 2007 - 19:03:36 CDT

Hi Brian,

Although this isn't directed at you personally, I've been noticing
that something is missing from OSS voting systems. You just gave me
another opportunity to bring it up, thanks!

Yes, there is a formal "threat modeling" framework that we need to
apply to open voting - one that is seldom discussed. I can't couch
it in the same terms you used since I don't believe that "every
possible attack vector" can be predicted by mortals. None the less
we should consider implementing NIST Common Criteria standards to our
software. This works very well for protection of life critical
systems (think nuclear). In addition, the DOD has some pretty tight
guidelines under DOD-178B that could be applied to relativily simple
systems, (like voting), at a level A standard. In my discussions
with others in this community, applying existing and truly strict
standards based controls seems to be an under-discussed or even
missing point.

In the interests of full disclosure, I am a founding member of OVC,
former lead developer of the same and currently working on NIST CC/
DOD-178B certifiable software.

        -Fred-

On Sep 7, 2007, at 4:48 PM, Brian Behlendorf wrote:

>
> On Thu, 6 Sep 2007, Arthur Keller wrote:
>> So should we be considering threat models and alternative
>> architectures?
>> Should we be doing threat analysis on Open Voting Solutions'
>> software? Or is
>> the fact that Open Voting Solutions' software is open source
>> enough to give
>> us confidence that it is a secure and reliable system merely awaiting
>> (known-to-be flawed) certification process?
>
> For the sake of the reputation of the OVS solution, I would assume
> they have
> already and are constantly thinking of new ways to subvert the
> system. I would
> assume they have run Agitar or a similar input-fuzzing tool or
> static analysis
> tool against the software to look for exploitable memory leaks or
> logic errors.
> I would assume they have a public list, as part of the development
> process, of
> secure coding practices (such as "never trust external input" and
> "no casts
> ever in C") or are have a wishlist of same with a timeline for
> applying them.
> But time is always a limiting factor and writing secure code is
> hard, so when
> holes are found none of us should be surprised; instead of judging
> the OVS
> software by how perfect the code is, the vendors deploying it
> should be judged
> by how quickly they can fix a hole once discovered.
>
> OVS or other vendors of open source software should also be looking
> for
> non-critical environments to test their solutions out - school
> elections?
> survey kiosks? They should be looking for computer science
> professors at
> community or state schools willing to study the software as both an
> example of
> a voting system and for other potential holes that only a highly
> motivated and
> caffienated 17 year old can find. :)
>
> But never rely on the license on the code to have any significance
> prima facie
> to its security. All it can do is unleash potential.
>
>> My own suggestion is to proceed with certification of OVS' system
>> while we develop threat models and new architectures that vendors
>> (particularly OVS) can adopt.
>
> I have not looked at the OVS software so I can't comment on its
> maturity, but
> if it's something that you believe is ready for production use, and
> ideally has
> already been used for real or semi-real elections successfully,
> then go for
> certification.
>
> My worry about the use of the word "threat modelling" is that it
> makes it sound
> like there's a formal process one can go through to articulate
> every possible
> attack vector, and by blocking each you then have provably secure
> software. Or
> that there's a particular software architecture, or even language,
> that
> guarantees secure software or makes it hard to write insecure
> software. I
> would wish to disabuse you of those notions; new ways to attack
> software emerge
> all the time, and as stated before a secure elections process
> shouldn't depend
> on inexploitable software anyways.
>
>> Some on this list have advocated open test environments. How do
>> we get
>> there?
>
> It'd be great if the certification process were transparent, so it was
> understood what was being tested. That could even lead to the
> development of
> an automated test suite for some or all of the certification
> process, that
> could be run after any source code change to make sure the system
> remained in a
> certifiable state.
>
> Brian
>
> _______________________________________________
> OVC-discuss mailing list
> OVC-discuss@listman.sonic.net
> http://lists.sonic.net/mailman/listinfo/ovc-discuss
> By sending email to the OVC-discuss list, you thereby agree to
> release the content of your posts to the Public Domain--with the
> exception of copyrighted material quoted according to fair use,
> including publicly archiving at http://gnosis.python-hosting.com/
> voting-project/
>

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
By sending email to the OVC-discuss list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at http://gnosis.python-hosting.com/voting-project/
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Sun Sep 30 23:17:08 2007

This archive was generated by hypermail 2.1.8 : Sun Sep 30 2007 - 23:17:20 CDT