Chefdevseccon2015
- 1. LONDON 2015Join the conversation #devseccon Transforming security from qualitative to quantitative Scott Russell
- 2. Transforming security from qualitative to quantitative Scott Russell
- 3. How many tickles does it take to make an Octopus Laugh? 10Ten-Tickles
- 4. Justin Arbuckle “If you cannot state the policy in a way that can be coded, or automated, then the policy is wrong, or worse un-enforc
- 5. Justin Arbuckle “the compliance of an organisation is in direct proportion to the extent that their policies are expressed as code." Arbuckle’s Law
- 6. Non-bullet Slide Non-bullet slide subtitle CI
- 7. Security happens in tears tiers… • At the OS, • At check-in to Source Control • Running of orchestration Jobs • Update to Chef Server • Updates to Analytics Server • Feeds to Splunk/Elastic Search • In feedback loops • At customer contact points
- 9. https://supermarket.chef.io/cookbooks/audit-cis The Audit – CIS cookbook. Real world example of quantifiable Security
- 10. Cis Audit cookbook – CIS audit rule descritption • 7.5 Lock Inactive User Accounts (Scored) Profile Applicability: Level 1 Description: User accounts that have been inactive for over a given period of time can be automatically disabled. It is recommended that accounts that are inactive for 35 or more days be disabled.
- 11. Cis Audit cookbook – Actual Security Readable output
- 12. Caveats for Quantifiable Secure Infrastructure • Information is a “human problem” • Risk assessment is an iterative process • Someone has ‘root’ • Someone has the ‘private key’ • Policy must be translatable into code, ( or already expressed as code ) • Security involved in the CD/build pipeline from Day 1 • Security able to specify tooling and coding to be run at all stages. • Security sign off on the validity of the CD/Build pipeline
- 13. No security plan survives initial contact with Continuous Deployment
- 14. The Positive side of DevSecOPS tooling • Favor tools that expose good API’s for automation • Move from one firewall per company, to one virtual firewall per app, or per protocol. Change becomes easier to manage politically. • Integrate error reporting ( of security testing )into the build process , providing instant feedback
- 15. Implementing Security with DevSecOps Challenges • Firewall ( hardware ) manufacturers tend to be “API challenged” • Security software vendors favor “static config” of their tools. The challenge is to make this more dynamic ( using chef of course ) • Tooling is moving towards friendly API’s, but slooooowly • Creation and updating of automated security tests across multiple builds is Haaaard!. • Risk assessment on single firewall, with automated changes involves the entire company, needs automated testing ( of everything ), and is unlikely to pass risk assesement. Individual firewall’s carry less risk.
- 17. LONDON 2015Join the conversation #devseccon End
Editor's Notes
- #8: At the OS, Provenance - Where did the ISO come from? How was it built? Show me the logs?, no, for this image, v1.3.2, at 09:15:23, on 21st march. 2015? Who built it? What was the version of the scripts used to build it? Show me the security test and audit results ( for that image build ) At Source Control Who checked in the code? Who has access to the code? Show me the logs?, no, for this commit, at 09:15:23, on 21st march. 2015? Integration to AD, again show me the logs Alerting on denied access, etc? Alerting on “dangerous code commits” - ‘rm- Rf /’ At Orchestration level What security tests ( and versions ) were run for this job Who initiated the job? Show me the error logs for the security tests?, no, for this run, at 11:13:12, on 22nd march. 2015? Integration to AD, again show me the logs Regular security scanning of the UX?, every patch? At Chef server update Who logged into chef? Service account or user? What was updated? – Chef analytics? Show me the error logs for the security tests?, no, for this run, at 11:13:12, on 22nd march. 2015? Integration to AD, again show me the logs Pass in a unique id for later tracking? Regular security scanning of the chef server?, every patch? At Analytics server update Who logged into chef? Service account or user? What nodes/resources were updated? Were they successful updates Feedback loop back to orchestation with a unique id to confirm update? Show me the logs for the security audit logs?, no, for this run, at 12:43:12, on 22nd march. 2015? Regular security scanning of the chef server?, every patch? At analytics feeds to splunk/ELK Do the splunk/ELK index’s match the chef environments? Why? What alerts are being implemented, are the being driven by security code? Did the updates to “Alerts” all happenen via an orchestrated code update? Show me the logs? Show me the timeline for the unique change id XXX ,for this job, starting at 12:43:12, on 22nd march. 2015?