Putting the Sec into DevOps

54
PUTTING THE SEC INTO DEVOPS Prof. Avishai Wool

Transcript of Putting the Sec into DevOps

PUTTING THE SEC INTO DEVOPS

Prof. Avishai Wool

AGENDA

• Introduction: DevOps and Network Security

• Ops + Security scenarios: Pitfalls and Tips

• Dev + Security scenarios

• DevOps with AlgoSec

• Continuous integration with AlgoSec

2

WHAT’S THE MOTIVATION

• Network connectivity and security is a painful bottleneck in the application delivery pipeline

• Accelerate application delivery by automating network connectivity processing• Human intervention only when required

• Visibility into application connectivity requirements is important for Network and Security teams

• Security, full audit trail and continuous compliance must be built into the process

3

DEVOPS CYCLE

• Develop (Programmers in R&D)• New application

• New functionalities in an existing application

• Test

• Deploy (Ops)• Add capacity to an existing application

• New deployment targets

• Production

4

NO APPLICATION IS AN ISLAND

Applications have connectivity requirements

• Human users• Insiders• Remote sites and road warriors• Outsourcers• Business partners• Outsiders

• Internal resources (DB, API to other applications, …)

• Infrastructure resources (DNS, backup, authentication, …)

• Business partner resources

• Internet resource

5

NETWORK SEGMENTATION

• Separate environments for Dev/Test/Pre-production/Production

• Network security policies must allow the necessary traffic

• Changes to applications that modify connectivity requirements must be implemented in network security policies

• … so you need DevSecOps

6

TIGHTER SECURITY IN PROD

DevelopmentTest

ProductionFront

ProductionBackend

Pre-Production

Test & Pre-Production environments: servers all in one security zone

Production servers in several security zones

7

OPS + SECURITY SCENARIOS: PITFALLS AND TIPS

ADDING CAPACITY

• Typically only Ops involved

• Typically only relevant to Production environment

• Add another• Web server to the web farm

• Compute engine to the Compute cluster

• Etc.

• New clone has the same role as existing clones

• No need for another security review – all pre-approved

9

SOUTHBOUND TRAFFIC: LOAD BALANCER

• Load balancer in front of the web farm

• Upstream security policies written using “Virtual IP” / “Virtual Server name”

Result:

• Add new server to the farm

• Update load balancer configuration to use the new resource

• No need to touch security policiesLoad

Balancer

DevTest

Prod Front

Prod Back

Pre-Prod

10

EAST/WEST TRAFFIC

• Need to connect to/accept connection from/other systems• Management connections

• Access to internal/partner/Internet resources

• Resources in other network segments

• Connections flow across security zones

• Load balancer does not help: need to differentiate between clones

DevTest

Prod Front

Prod Back

Pre-Prod

Firewall

11

EAST/WEST TRAFFIC – SOLUTION A

• Careful IP address allocation!

• Discipline:• All clones have IP addresses in the same Subnet / Range / VLAN / VPC

• Security policy rules allow traffic to/from whole Subnet

Result:

• Add new server to the farm

• Ensure its IP address is in the correct Subnet / Range

• No need to touch Security Policies

12

ADDRESS ALLOCATION – PROPERTIES

Pro: works with all filtering technologies

Con:

• Pre-allocate IP addresses for each server class

• Need to predict maximal capacity

13

EAST/WEST TRAFFIC – SOLUTION B

• Use object groups!

• Discipline:• Filtering devices have a network object group for each server class

• Security policy rules allow traffic to/from object group

Result:

• Add new server to the farm

• Add its IP address to the correct object group

• No need to touch security policies rules – object change is sufficient

14

OBJECT GROUPS – PROPERTIES

Pros:

• Clones can have arbitrary IP addresses

• No address pre-allocation

• No need to predict maximal capacity

Cons:

• Need to touch object definitions on security devices• Goal: zero-touch orchestration, with audit trail

• Requires filtering devices that support object groups• Router ACLs and cloud providers “Security Groups” have limitations

15

DEV + SECURITY SCENARIOS

DEVOPS WITHOUT “SEC” FAILURES

• Developers add new functionality to an application

• Everything works in Test and Pre-Production environments

• Push new version to Production Fail!

17

WHAT WENT WRONG?

• Remember “No application is an island”

• New functionality includes new connectivity flows

• Dev didn’t document the new flows• Possibly didn’t realize new connectivity was required

• Relaxed security policy in Dev, Test, Pre-Production environments allows connectivity• Maybe the resource replica/placeholder is inside the same zone?

• Application works in Test: no need for Sec involvement – wrong!

18

DOCUMENT THE APPLICATION FLOWS

• Maintain a repository recording all the flows required by each application

• For each flow record, at least:• Source and Destination IP addresses

• Services and network-applications in use

• Automation Tools:• Modify the application record whenever new functionality adds flows

• Add security review and approval for new flows during Dev cycle

19

TIP: TIGHTEN SECURITY AROUND TEST

• Place filtering devices around the Pre-Production environment

• Apply the tight security policy of Production• Not the loose policy of Dev!

Result:

• Dev forgets to document new flows or

• Does not realize there is a new flow

• Failure will happen in Pre-Production environment – as desired

• … triggering Sec review earlier in the cycle

DevTest

Prod Front

Prod Back

Pre-Prod

20

MULTIPLE INSTANCES OF APPLICATION’S RECORD

• Application’s flows in Dev / Test / Pre-Prod / Prod have• Same services (“SQL”, “HTTPS”, …)

• Same logical structure (“Application Logic server connects to DB”)

• Different IP addresses: Test DB is different from Prod DB

• Maintain separate instances of the application’s record:• Dev (“Dev-Application-logic-server connects to Dev-DB”)

• Test (“Test-Application-logic-server connects to Test-DB”)

• Pre-Prod (“Pre-prod-Application-logic-server connects to Pre-Prod-DB”)

• Prod (“Prod-Application-logic-server connects to Prod-DB”)

21

LIFECYCLE: MIGRATE BETWEEN STAGES

• Pushing application version (e.g. from Pre-Prod to Production):• Provision workloads, deploy code, …

• … Don’t forget to update the security policies protecting the next stage!

• Not a simple copy!

• Maintain a mapping:• Dev-DB Test-DB

• When deploying security rules, replace all Pre-Prod-DB by Prod-DB

22

DEVOPS WITH ALGOSEC

APPLICATION FLOW REPOSITORY: BUSINESSFLOW

For all applications, maintain record of:

• Network flows

• Contact information

• Connectivity status

• Change history and activity log

• Risk and vulnerability information

• Initiate DevOps-led changes from UI or from API

24

SCENARIO: NEW APPLICATION ROLLOUT

Background:

• New application going live

• All testing in pre-production environment completed successfully

• Connectivity flows for pre-production documented in BusinessFlow

Current task:

• Configure security policies to allow connectivity in Production

29

• Move: if application will no longer have a staging environment• Clone: retain both staging and production environments

Map Pre-Production to Production servers

#4388 BusinessFlow Change Request for GameStop Central - Production

#4388 BusinessFlow Change Request for GameStop Central - Production

#4388 BusinessFlow Change Request for GameStop Central - Production

ZERO-TOUCH

All workflow steps can be automated (with controls & audit):

• Automatically accept security devices to update

• Automatically accept risk check (if risks below a defined threshold)

• Automatically implement on devices (“ActiveChange”)

43

CONTINUOUS INTEGRATION WITH ALGOSEC

Deploy

DEVOPS PIPELINE

Developer commitscode

Compile &Package

Unit Tests

Testenvironments

Integration

Performance

Bring up test environments

Connectivity Tests + Open + Document

Run all tests

Production45

CI: CONNECTIVITY TEST PIPELINE (ZOOM IN)

Application Connectivity .json

Code

BusinessFlow

FireFlow

Changed?

Yes

No

Test connectivity

Yes

Success

Check status in Business Flow

NoPre-approved –automatic implementation

Requires security approval

Fail

46

APP DEVELOPMENT

• Developer maintains a json file describing application connectivity requirements in test and production environments

• Commit with code

• Alternatively, json automatically derived from puppet during test environment bring-up

ConnectivityRequirements.json{“flow1”: {

“source”: “10.20.1.4”,“destination”: “8.8.8.8”,“service”: “http”,“description”: “web connectivity to Google”

},“flow2”: {

“source”: “10.20.1.4”,“destination”: “10.20.5.112”,“service”: “tcp/5432”,“description”: “connectivity to PostgreSQL DB”

}}

47

CI UPDATES ALGOSEC

• If connectivity requirements change - CI system (Jenkins, etc.) uses AlgoSec plugin to update AlgoSec

• AlgoSec BusinessFlow calculates required changes and opens a Change Request with AlgoSec FireFlow

48

CONNECTIVITY CHECK

• AlgoSec FireFlow calculates the network path and checks which security policies need to be updated (if any)

• If connectivity already allowed -> Return “Success”49

OPEN BLOCKED CONNECTIVITY

• If connectivity not allowed -> go through automatic change process• Find relevant firewalls and policies, perform “what-if” risk analysis

• If no risks (pre-approved connectivity, not breaking compliance) -> continue with zero-touch • Push changes to relevant firewalls and routers

• Multiple vendors, physical or virtual, on-prem, SDN or cloud

• -> Return “Success”

ACI

50

WHAT JUST HAPPENED HERE

• High percentage of application changes – automatically processed• Either already works, or pre-approved and immediately implemented

• When manual security approval is required – Change Request automatically opened, with relevant application context

• Application connectivity requirements – automatically updated• Full application context and visibility – for infrastructure changes, security

incidents, network or server migrations, maintenance, etc.

• Continuous compliance is retained• Security has full control over policy and approvals

• Full audit trail and documentation of changes

51

THE BOTTOM LINE

• More agile application development and delivery cycles• Security is no longer a bottleneck

• App developers, DevOps and Security all save time and work thanks to automation

52

MORE RESOURCES

53