Putting the Sec into DevOps DevOps enables companies to deliver innovations faster to market. But with multiple functional teams collaborating on development, and so many moving parts, security is often left out of the DevOps process and then tacked on at the end - delaying deployment into production and negating many of the benefits of DevOps. Presented by renowned industry expert Prof. Avishai Wool, this new technical webinar will cover best practices for incorporating security into the DevOps lifecycle. This insight will help ensure better collaboration between security and the development teams right from the start and reduce the time, cost and risk of deploying applications into production. In this webinar Professor Wool will cover how to: • Identify and map existing applications and their connectivity flows to establish a baseline • Adjust application connectivity for each stage of the DevOps lifecycle – without coding • Automatically deploy connectivity throughout the development lifecycle using templates • Proactively assess risk and compliance throughout the DevOps process • Manage and maintain security in the production environment

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

23. DEVOPS WITH ALGOSEC

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

53. MORE RESOURCES
53

54. Thank you!
Questions can be emailed to
marketing@algosec.com