Putting the Sec into DevOps
- 1. PUTTING THE SEC INTO DEVOPS Prof. Avishai Wool
- 2. AGENDA • Introduction: DevOps and Network Security • Ops + Security scenarios: Pitfalls and Tips • Dev + Security scenarios • DevOps with AlgoSec • Continuous integration with AlgoSec 2
- 3. 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
- 4. 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
- 5. 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
- 6. 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
- 7. TIGHTER SECURITY IN PROD DevelopmentTest Production Front Production Backend Pre-Production Test & Pre-Production environments: servers all in one security zone Production servers in several security zones 7
- 8. OPS + SECURITY SCENARIOS: PITFALLS AND TIPS
- 9. 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
- 10. 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 policies Load Balancer DevTest Prod Front Prod Back Pre-Prod 10
- 11. 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
- 12. 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
- 13. ADDRESS ALLOCATION – PROPERTIES Pro: works with all filtering technologies Con: • Pre-allocate IP addresses for each server class • Need to predict maximal capacity 13
- 14. 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
- 15. 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
- 16. DEV + SECURITY SCENARIOS
- 17. 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
- 18. 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
- 19. 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
- 20. 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
- 21. 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
- 22. 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
- 24. 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
- 29. 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
- 33. • Move: if application will no longer have a staging environment • Clone: retain both staging and production environments
- 34. Map Pre-Production to Production servers
- 38. #4388 BusinessFlowChangeRequestfor GameStop Central - Production
- 40. #4388 BusinessFlowChangeRequestfor GameStop Central - Production
- 41. #4388 BusinessFlowChangeRequestfor GameStop Central - Production
- 43. 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
- 44. CONTINUOUS INTEGRATION WITH ALGOSEC
- 45. Deploy DEVOPS PIPELINE Developer commits code Compile & Package Unit Tests Test environments Integration Performance Bring up test environments Connectivity Tests + Open + Document Run all tests Production45
- 46. CI: CONNECTIVITY TEST PIPELINE (ZOOM IN) Application Connectivity .json Code BusinessFlow FireFlow Changed ? Yes No Test connectivity Yes Success Check status in Business Flow No Pre-approved – automatic implementation Requires security approval Fail 46
- 47. 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
- 48. 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
- 49. 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
- 50. 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
- 51. 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
- 52. 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
- 54. Thank you! Questions can be emailed to marketing@algosec.com