Security, Auditability, and Threats: The VVSG2007 Security - - PowerPoint PPT Presentation

security auditability and threats the vvsg2007 security
SMART_READER_LITE
LIVE PREVIEW

Security, Auditability, and Threats: The VVSG2007 Security - - PowerPoint PPT Presentation

Technical Guidelines Development Committee Meeting December 4 and 5, 2006 Security, Auditability, and Threats: The VVSG2007 Security Architecture Presentation for the Technical Guidelines Development Committee (TGDC) John Kelsey Dec 4/ 5,


slide-1
SLIDE 1

Dec 4/ 5, 2006 - Page 1 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

Security, Auditability, and Threats: The VVSG2007 Security Architecture

Presentation for the Technical Guidelines Development Committee (TGDC) John Kelsey Dec 4/ 5, 2006 National I nstitute of Standards and Technology

slide-2
SLIDE 2

Dec 4/ 5, 2006 - Page 2 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

Security Requirements

Goal: Write a standard that leads to secure

voting systems!

We need to understand:

Security requirements and attacker goals/resources Voting system architectures Threats to voting systems

Write requirements to block attacks

Ensure those requirements are testable!

Looking at the big picture

slide-3
SLIDE 3

Dec 4/ 5, 2006 - Page 3 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

Roadmap: Attackers-> Threats-> Standard

Understand attacker goals and resources Determine how attacker might accomplish

those goals

  • -> Threats

Determine defenses to block threats Write testable requirements to ensure

presence and effectiveness of these defenses

slide-4
SLIDE 4

Dec 4/ 5, 2006 - Page 4 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

How Does VVSG2007 Address Threats?

For each voting system architecture:

Identify significant threats Block threats (ideally, block whole classes of

threat)

Blocking = Prevention or Detection

Example: paper ballots in ballot box

Prevention: Padlock on ballot box Detection: Tamper-evident seal on box

slide-5
SLIDE 5

Dec 4/ 5, 2006 - Page 5 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

Current Voting System Architectures

Precinct Count Optical Scan

Hand-marked Ballot marking devices/ ballot printing devices

DRE+ VVPAT

Paper-roll Cut-sheet

DRE

slide-6
SLIDE 6

Dec 4/ 5, 2006 - Page 6 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

What are the attacker’s goals?

Change outcome of election

This is where we spend most of our

analysis!

Defeat ballot secrecy

With or without voter’s help

Disrupt election

Force election to be re-run or decided in

courts

slide-7
SLIDE 7

Dec 4/ 5, 2006 - Page 7 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

How Do We Know About Threats?

History and folklore about voting systems

Harris book, election officials, voting people

Current information on computer attacks

Computer security literature, CERT, security people

Analysis of voting system components in the

lab

Hopkins, RABA, Hursti, Princeton, Compuware,…

Analysis of voting systems w/ procedures

Brennan Center, NIST Threats Workshops

slide-8
SLIDE 8

Dec 4/ 5, 2006 - Page 8 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

Threat Methodology

Wrong question: Can I tamper with a voting machine? Right question: Can I tamper with an election?

Consider a close statewide election: Look for

ways to tamper with outcome!

Parameters like # voting machines, # polling places,

how big change can be before noticed

Consider procedural defenses! Evaluate attacks based on attack team size

slide-9
SLIDE 9

Dec 4/ 5, 2006 - Page 9 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

Roadmap: Attackers-> Threats-> Standard

Understand attacker goals and resources Determine how attacker might accomplish

those goals

  • -> Threats

Determine defenses to block threats Write testable requirements to ensure

presence and effectiveness of these defenses

slide-10
SLIDE 10

Dec 4/ 5, 2006 - Page 10 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

Requiring Security Controls

Some threats can be prevented or

detected by specific security controls

Event logs Access control Software distribtution System configuration management Digital signatures on electronic records

slide-11
SLIDE 11

Dec 4/ 5, 2006 - Page 11 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

Procedural Defenses

Some threats blocked by procedural

defenses:

Example Threat: Tampering PCOS scanner

software

Procedural Defense: Random auditing

recount of ballots from a few precincts

slide-12
SLIDE 12

Dec 4/ 5, 2006 - Page 12 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

Procedures in an Equipment Standard?

Require equipment to support the procedures

it needs to address threats for its architecture:

Specific hardware/software requirements to ensure

that procedure can function effectively.

Documentation requirements: user documentation

must show how to do procedure.

Technical documentation must show lab why

procedure accomplishes desired security goals.

slide-13
SLIDE 13

Dec 4/ 5, 2006 - Page 13 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

Example: Parallel Testing

Determine if the voting machines are

misbehaving on election day.

Procedure: Isolate a few random voting

machines, run an all-day test on them.

Requirement: The voting machine must

never be able to find out it’s being tested.

slide-14
SLIDE 14

Dec 4/ 5, 2006 - Page 14 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

This Leads to Equipment Req’ts

Voting machines….

Must not receive signals during voting. Must not learn they are being tested by

authorizations to vote.

Must not have any observable change

between test and voting environment

These are equipment requirements,

needed to support parallel testing!

slide-15
SLIDE 15

Dec 4/ 5, 2006 - Page 15 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

And to Other Requirements

The voting machine documentation must

explain how to carry out a parallel test

VSTL verifies that documentation gives a good

parallel test--accomplishes security goals.

In open-ended testing, VSTL attempts to find:

Ways for voting machine to notice test environment Ways for anyone to get message into voting

machine

slide-16
SLIDE 16

Dec 4/ 5, 2006 - Page 16 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

How Are Requirements Enforced?

Checklist -> Documentation -> OEVT

VSTL checks to make sure required security

controls are present and correctly used.

Documentation requirements--VSTL reads and

verifies correctness of documentation

OEVT--open-ended testing, VSTL attempts to

find ways in which security of voting system can be violated.

slide-17
SLIDE 17

Dec 4/ 5, 2006 - Page 17 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006

Conclusions

VVSG2007 security standards based heavily

  • n threat analysis

Drawn from extensive literature review, historical

data, and internal and external analysis, and workshops

Procedural requirements -> equipment and

documentation requirements

Equipment, Documentation, and OEVT

requirements fit together to improve chances

  • f getting secure voting systems.
slide-18
SLIDE 18

Dec 4/ 5, 2006 - Page 18 VVSG Security Architecture--Kelsey

Technical Guidelines Development Committee Meeting December 4 and 5, 2006