PuppetConf 2016: Puppet as Security Tooling – Bill Weiss, Puppet

Post on 15-Apr-2017

154 views 2 download

Transcript of PuppetConf 2016: Puppet as Security Tooling – Bill Weiss, Puppet

Puppet as Security Tooling

2

I’m Bill Weiss@BillWeiss almost everywhere bv@puppet.com Sr. Manager of SREs Former wearer of monochrome hats

Puppet as Security Tooling

Agenda

Housekeeping

Definitions Building security in

Controlling access Show that you did the thing

Patch management Compromises happen

3

Housekeeping

4

Ask questions whenever

5

Really, please ask

This isn’t a tech talkI’m talking about process, you’ll figure out the code

6

Almost all of you know some of thisBut I bet most won’t be doing all of it

7

Definitions

8

9

Security: things that keep your data safe

Compliance: things that keep you running

10

Sometimes there’s overlap, sometimes notYou still have to do both

11

Building security in

12

Get security + compliance involved early

Call your security friends and have them tell you what they need.

Invite compliance to the party as well.

Input early >> input at the end

13

Build a baselineCommon settings/tooling you want everywhere

14

Build a baselineI’m not saying you have to use this module, but they’ve put a bunch of thought into it

15

Build a baselineLogging, auditing, endpoint protection

16

Build a baselineRegulatory requirements and compliance

17

NSA STIG with SIMP

I know, that’s a lot of acronym.

NSA: National Security Agency

STIG: Secure Technical Implementation Guide

SIMP: System Integrity Management Platform

18

WHITE PAPER

Continuous STIG Enforcement with Puppet Enterprise & the NSA Modules

NSA STIG with SIMP

Covers NIST 800-53 and DISA STIG

Optionally enforces FIPS 140-2 mode

19

WHITE PAPER

Continuous STIG Enforcement with Puppet Enterprise & the NSA Modules

Build a baselineDo the things you told customers you do

20

Build a baselineTrack changes over time

21

Test like it’s production

22

Finding problems late means turning things off

Controlling access

23

Build access based on roleNot everyone needs to log in everywhere

24

Map out who needs to talk to whatFirewalls aren’t just for the edge

25

Tie security rules to environmentsEnforce controls and permissions at the same time

26

Stop knowing passwordsUse a secret management system, please

27

Get better at rotating credentialsBut don’t start expiring passwords like mad

28

Showing that you did the thingAKA why the compliance folks will like you

29

“Here’s when we patched"In aggregate, per machine, per datacenter…

30

“Here’s who can log in to this machine"And here’s when that changed

31

“Here’s evidence that all machines are logging to our SIEM"

32

“Here are the machines in PCI scope”And here’s how you know that’s the total list

33

Patch management

34

Seriously, get patching under controlYou won’t regret it

35

Get fast at triaging and rolling outID machines that are behind, get them up to date

36

The closer prod and test are, the faster you can move

You still want to test those patches, I assure you

37

I had a bad experienceWell, kind of bad. Turned out well.

38

Dealing with compromise

39

Detecting badnessRemember that unplanned change demo?

40

Detecting badnessThe tighter your controls are, the more you can detect problems

41

Assessing impactIf only you had a way to detect changes across machines…

42

Burn it all down and start overI take your persistence measure and raise it scorched earth

43

Test those backups firstMaybe I should have said this before “burn it all down”

44

Quick recap

45

1. Build more robust systems from the beginning.

2. Maintain tighter access controls.

3. Keep compliance happy by being able to show your work.

4. Keep on top of your patches.

5. Gain visibility into your running system.

6. Be able to rebuild quickly without breaking things.

46

Recap

47

I can’t drop the mic, but I’ll close my Hello Kitty phone.

Thank you