Firewall Configuration Errors Revisited - Securitymetrics.org

Firewall Configuration Errors Revisited Avishai Wool CTO & Co-Founder, AlgoSec and Prof., Tel Aviv University

AlgoSec Inc.

1

Agenda

ƒ ƒ ƒ ƒ ƒ

Introduction Data sources and procedures Configuration errors Highlights of 2004 study Results and discussion

AlgoSec Inc.

2

Firewalls seem to be badly configured:

ƒ

45% of companies worldwide suffered attacks from viruses and worms in the last 12 months • (this is a made up statistic, true in every year …)

ƒ

A properly configured firewall could easily block attacks such as:

• Sasser worm: attacked port 445 (Netbios) • Saphire SQL worm: attacked port 1431 • Blaster worm: attacked ports 135/137 (Netbios) ƒ

Firewall configs are deemed sensitive – why?

• Admins know they have holes… • Security by obscurity?

AlgoSec Inc.

3

Can we quantify the problem?

1.

Need firewall configuration data • Not available publicly

2.

Need to understand the configurations • Complex vendor-dependent configuration languages

3.

What is an error? • Subjective, organization-dependent

AlgoSec Inc.

4

#1 : We have the data

ƒ AlgoSec performed firewall analysis for hundreds of customers since 2000 ƒ Data is under non-disclosure agreements – but we can publish statistics

AlgoSec Inc.

5

#2 : We have the technology

ƒ Firewall Analyzer software can parse configuration languages • (Check Point, Cisco PIX, Cisco Router Access-lists)

AlgoSec Inc.

6

#3 : What is an error?

ƒ Idea: only count “obvious” errors ƒ Rely on “best practices”: • • • • •

SANS Top 20 CERT PCI DSS (Payment Card Industry) NIST 800-41 …

AlgoSec Inc.

7

Plan of action

First study (2004): • • • • •

Check Point Firewall-1 configurations Select 12 severe errors Analyze available configurations Count number of errors Statistical analysis to identify causes and trends

Current study: • • • •

AlgoSec Inc.

Both Check Point and Cisco PIX Larger - 2x number of configurations More in-depth: 36 severe errors, Check whether 2004 findings are still valid

8

Timeline of data collection

ƒ Configuration files were collected between 2000-2005 ƒ Check Point Firewall-1 versions: • 3.0, 4.0 – “end-of-life” • 4.1 – was still supported • NG – released in 2001, minor versions FP3, R54, R55 ƒ Cisco PIX • PIX versions 4.x, 5.x, 6.x, 7.0

AlgoSec Inc.

9

Highlights of the 2004 study

AlgoSec Inc.

10

54%

AlgoSec Inc.

11

Firewall-1 version helps

On average, 2 risks less

AlgoSec Inc.

12

Why did the version matter?

ƒ Some risks are the result of Check Point “implicit rules” ƒ Changed default values in v4.1 ƒ New policy wizard to create a reasonable initial configuration

AlgoSec Inc.

13

How to measure complexity

ƒ Complexity = #Rules + #Network Objects + (#interfaces choose 2)

ƒ 2 interfaces Æ 1 data path ƒ 3 interfaces Æ 3 data paths ƒ 4 interfaces Æ 6 data paths, etc

AlgoSec Inc.

14

Small is Beautiful

AlgoSec Inc.

15

Current Results

AlgoSec Inc.

16

Why should anything change?

ƒ Regulation and Compliance: • Sarbanes-Oxley • Payment Card Industry (PCI DSS) • NIST 800-41 •… ƒ Different vendors – different issues? ƒ New software versions – continue the trend?

AlgoSec Inc.

17

Differences from 2004 report

ƒ Both Check Point and PIX ƒ 2x configurations tested ƒ Newer software versions ƒ Vendor-neutral risk items • 8 of 12 properties in 2004 study were specific to Check Point ÆPick a new set of 36 risk items ÆInbound / Outbound / Internal traffic AlgoSec Inc.

18

Firewalls still badly configured

42%

AlgoSec Inc.

19

Version does not matter … (Check Point)

30

Number of Risks

25

20

15

10

5

0 4.0

AlgoSec Inc.

4.1

NG/NG FP3

NG R55

20

Version does not matter … (PIX)

30

Number of Risks

25

20

15

10

5

0 4.4

5.1-5.2

6.0-6.2

6.3-7.0

AlgoSec Inc.

21

Why? ƒ Vendor-neutral risks are controlled by basic filtering functionality ƒ Basic filtering controlled by explicit user-defined rules, rather than “check boxes” with vendor “know-how” (??) ƒ Neither vendor has changed the basic filtering capabilities in years (and it’s unlikely that they will)

AlgoSec Inc.

22

How to measure complexity of a PIX?

ƒ Check Point: • Single rule-base • Separate object database

ƒ Cisco PIX: • Separate rule-base per interface • No object database (almost)

ƒ Old RC metric not very suitable for PIX! AlgoSec Inc.

23

Issues with old RC metric (even on Check Point) ƒ Not enough weight to #interfaces: • #rules: 100s – 1000s • #objects 1000s • #interfaces 2-20 – dwarfed (even quadratically)

ƒ Example: • A firewall with 12 interfaces should be much more complex than with 3 … • RC contribution by interfaces is only 66

AlgoSec Inc.

24

A New Firewall Complexity Measure

ƒ Idea: pretend to “compile” Check Point configuration into a PIX configuration • • • •

Duplicate the rule-base, once per interface Add the object database once Count the resulting “number of lines” Compare with PIX config “number of lines” (minus some PIX boilerplate) Check Point: FC = (#rules * #interfaces) + #objects PIX: FC = #lines - 50

AlgoSec Inc.

25

Complexity distributions 8192 4096

Firewall Complexity (FC)

2048 1024 512 256 128

The range of complexity is comparable

64 32 16

AlgoSec Inc.

Check Point Firewall-1

Cisco PIX

26

Small is Still Beautiful

AlgoSec Inc.

27

Check Point vs PIX

AlgoSec Inc.

28

Questions?

ƒ E-mail: • [email protected] • [email protected] • http://www.algosec.com

ƒ 2004 study: IEEE Computer, 37(6):62-67, 2004

AlgoSec Inc.

29