How Sec Can Convince DevOps To Believe In The Boogeyman (B-Sides SF)
Putting the Sec into DevOps
-
Upload
maytal-levi -
Category
Technology
-
view
176 -
download
0
Transcript of Putting the Sec into DevOps
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
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
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
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
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
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
Thank you!
Questions can be emailed to [email protected]