AWS Community Day CPH - Three problems of Terraform
DevSecCon Seattle 2019: Liquid Software as the real solution for the Sec in DevSecOps
1. Seattle | September 16-17, 2019
Liquid Software as the Security
solution for DevSecOps delivery
OFIR AZOULAY-ROZANES
2. Seattle | September 16-17, 2019
Have you been there?
• Identified a vulnerability in your product and it took you a long time to
test before delivering to customers?
• Customers are pressing to have a fix but you don’t want to risk them with
an unstable version?
• You have provided a patch that included not only the vulnerability fix but
also other fixes – making the patch much bigger?
• And then it took the customer ages to deploy – waiting for a change
window?
• And then you found a bug at your patch that required another one?
5. Seattle | September 16-17, 2019
Whoami 2
• Started learning to code in the mid 80s (Basic, Fortran, Pascal, Cobol)
• Joined the work force at the beginning of the 90s (PowerBuilder)
• Unix Admin
• C (Linux Kernel) and C++ developer, team and group manager
• Using Open Source
• 2009 joined the Cyber Securiry industry
• Product Manager in Cyber companies (Imperva, Exabeam)
• @JFrog - Product Manager for Xray
6. Seattle | September 16-17, 2019
The 3 phases in the life cycle of a vulnerability
• Identifying
• Fixing
• Getting the fix to customers
8. Seattle | September 16-17, 2019
Fixing the vulnerability
• Fixing our code
• Updating 3rd party/OSS
9. Seattle | September 16-17, 2019
Fixing and testing can take time
• Updating a dependency can break your code
• How many of you are updating their libraries/dependencies that
often?
• If it works don’t touch it
• Long testing cycle
• To make sure nothing breaks
10.
11.
12.
13. Seattle | September 16-17, 2019
And then starts the journey of
getting the fix to customers…
14. Seattle | September 16-17, 2019
Customers do not trust your patches
• How many of you witnessed a bug in prod that was not identified in
• In house testing?
• Beta testing?
• Acceptance testing at a customer?
• My DB2 story
15. Seattle | September 16-17, 2019
Big patches with too many changes
• Facetime vulnerability in iPhone
• Why did it took so much time to get released?
• Why was it released only as part of a bigger patch?
• Windows Service Packs
• And then there is the issue of downloading big patches
• For IoT devices with low bandwidth
17. Seattle | September 16-17, 2019
Sometimes the customer need to be proactive to find that
there is a patch available
• How many of you updated their router FW/SW?
18. Seattle | September 16-17, 2019
Patches require downtime
• Need to wait for a change window
• Can take a long time to get there in an enterprise
• Virtual patching…
19. Seattle | September 16-17, 2019
Testing in pre-prod can take days/weeks/months
20. Seattle | September 16-17, 2019
Not using the latest patch
• Because of the fear it will break
• Keep on being vulnerable
• NHS WannaCry – using Windows XP in 2018
21. Do we want
it?
Let’s
update!
Are there
any high
risks?
Can we verify
the update?
How about no
Do we trust
the update?
Update
available
No
Yes
Yes
Yes
Yes
NoNoNo
Time
consuming
verification
26. Seattle | September 16-17, 2019
What is it?
• Constantly update your prod env with small chunks
• Software updates like water - constantly flowing
• A vision, as well as a mindset shift
• Not everything is baked
• How can we get there? Some ideas/thoughts in the next slides
• Only DevSecOps can make the revolution
27.
28. Seattle | September 16-17, 2019
Already being done today
• Elite teams are doing it – especially in the SaaS environment
• Not all SaaS solutions are there
• And for non-SaaS solutions
• We don’t have control on the machines in which our SW runs
• Servers, mobile devices, IoT, etc
29. Seattle | September 16-17, 2019
Continuous updates pattern - Frequent Updates
• Problems
• Seldom deployments generate anxiety and stress, leading to errors
• In batch updates important features wait for non-important features
• Batch updates are large in size
• The solution - update frequently in small chunks
30. Seattle | September 16-17, 2019
Continuous updates pattern - Canary Releases
• The problem
• Releasing a patch with a bug affects ALL users
• The solution
• Release to a small number of users
• Such that we have visibility into their environment
31. Seattle | September 16-17, 2019
Continuous updates pattern – Observability
• The problem
• Some problems are hard to trace relying on user feedback only
• The solution
• Implement tracing, monitoring and logging to identify problems
32. Seattle | September 16-17, 2019
Continuous updates pattern - Local rollback
• The problem
• Updates can fail
• The solution
• Have a previous version saved on the device prior to update
• Rollback automatically in the case of a problem
• Dynamic DB formats (NoSQL) to support going back while keeping the
data
• Parallel systems in critical cases
33. Seattle | September 16-17, 2019
Continuous updates pattern - Zero Downtime Updates
• The problem
• Some systems cannot be brought down
• The solution
• Upgrade the SW in phases
• Rolling updates of DB content based on the new DB schema
34. Seattle | September 16-17, 2019
Continuous updates pattern – Automate Everything
• Eliminate any chance of human errors
• Automatic testing and Security scanning as a gate
35. Seattle | September 16-17, 2019
Other patterns/thoughts
• Automatic updates – not asking the customer for approval
• Mindset change all way long - think of the need to support
upgrade/rollback/zero downtime when developing the feature
• Constantly update to newer versions of third party internally
• Use wrapper APIs
36. Seattle | September 16-17, 2019
Other patterns/thoughts
• Updating libs to end targets
• Automating acceptance tests on the customer side
• Collect back info from deployments to improve testing
• Collect meta data on the processes done
• AI to identify problems, to help in the go-no-go decisions
37. Do we want
it?
Let’s update!
Are there
any high
risks?
Do we trust
the update?
Update
available
No
Yes
Yes
Yes
Sure, why not?
(auto update)