BsidesMCR_2016-what-can-infosec-learn-from-devops
Download as PPTX, PDF4 likes1,977 views
The document discusses the history and evolution of DevOps practices over time, from concepts like daily builds in the 1990s to more recent approaches like infrastructure as code and serverless architectures. It provides an overview of key figures and texts that helped establish ideas like continuous integration, continuous delivery, and site reliability engineering. The document also shares the author's perspective on what commercial security tools have been developed for DevOps workflows and mentions some open source collaboration and automation tools.
BsidesMCR_2016-what-can-infosec-learn-from-devops
- 1. What can Information Security learn from DevOps James Mckinlay – CSO Praetorian Consulting International
- 2. #whoami Electoral Role Landline Broadband Mobile Phone Gas Electric TV licence Passport Inland Revenue High Street Bank Online Retailers Online webmail Companies House Online accountant Births & Marriages Register Hospital records / GP records Husband, Father, Son IT Security <- IT Solutions <- IT Manager https://uk.linkedin.com/in/jmck4cybersecurity Shares / Child ISA Pension Car Insurance House Insurance Flight Records (ARINC) Mortgage Postcode Address File University Records Water / Utilities Council Tax Driving Licence Car registration Equifax Experian Callcredit
- 3. * Section 1: My version of devOps * Section 2: What I’ve seen recently * Section 3: Tools you should play with @CisoAdvisor
- 4. * Section 1: My version of devOps Revolution Quote 1: “You will not be able to stay home, brother. You will not be able to plug in, turn on and cop out. You will not be able to lose yourself on skag and Skip out for beer during commercials, Because the revolution will not be televised.” - Gil Scott-Heron (1949 –2011)
- 5. Disclaimer (1) Before we go any further, I feel I should first point out that everything I’m about to say is obviously just my personal opinion, which you are of course entitled to take with the appropriate pinch of salt. I would expect that if you asked someone else who was considering the same question, they might have very different things that they are looking for. (2) I am not in DevOps (3) I am not a DevOps historian
- 6. Before there was “DevOps” there was – “Visual Ops” (2004) Gene Kim Kevin Behr George Spafford
- 7. 2004 : A very simple, straight forward, easy to read book that provides a proven best practice for getting control of your data center though the implementation of high value IT service management activities. The book breaks it down into four simple steps, with examples echoing what those in the industry see in the real world: 1) Stabilize the patient 2) Catch and release, and find fragile artifacts 3) Establish repeatable build library 4) Enable continuous improvement.
- 8. 2008: When information security sufficiently integrates into IT operations, both groups can better manage risks, and meet operational commitments. Phase 1 – Stabilize the patient and get plugged into production Integrate information security into daily IT operations to more effectively manage both information security and operational risks. Both groups will stop undoing each other’s work. Phase 2 – Find business risk and fix fragile artifacts Identify the greatest business risks, discover critical IT functionality, and ensure controls are adequate. Phase 3 – Implement development and release controls Move upstream in the software lifecycle to get security involved in development, project management, and release management functions Phase 4 – Enable continual improvement For each phase and task, implement metrics that help assess the short-term progress and long-term health of the various processes and controls.
- 9. Before there was “Visual Ops” there was - “Extreme Programming” (1999) ‘Embrace Change’ Opens with sentence - ‘XP is about social change.’ Second Edition - 2004
- 10. Before “XP Programming” there was - “Daily Build & Smoke Test” (1996) By the time it was released, Microsoft Windows NT 3.0 consisted of 5.6 million lines of code spread across 40,000 source files. A complete build took as many as 19 hours on several machines, but the NT development team still managed to build every day (Zachary, 1994). Far from being a nuisance, the NT team attributed much of its success on that huge project to their daily builds.
- 11. Along came “Continuous Integration” (2006) It wasn’t new in 2006, this is just credited as a really good writeup of CI.
- 13. Then there was “10+Deploys a day” (2009)
- 14. Then there was “Continuous Delivery” (2011) They review key issues, identify best practices, and demonstrate how to mitigate risks. Coverage includes • Automating all facets of building, integrating, testing, and deploying software • Implementing deployment pipelines at team and organizational levels • Improving collaboration between developers, testers, and operations • Developing features incrementally on large and distributed teams • Implementing an effective configuration management strategy • Automating acceptance testing, from analysis to implementation • Testing capacity and other non-functional requirements • Implementing continuous deployment and zero-downtime releases • Managing infrastructure, data, components and dependencies • Navigating risk management, compliance, and auditing
- 15. Two slideshares worth a look at from 2012
- 16. Then in 2013 there was: “The Phoenix Project” “Adventures of an IT Leader”
- 17. Then there was . . . There are many books like them , but I like these
- 18. Then there was “SRE” (2016) and “IAC” (2016) You’re all my favourites
- 20. Into 2017 The next “big Thing?” Serverless Architectures Serverless architectures refer to applications that significantly depend on third-party services (knows as Backend as a Service or "BaaS") or on custom code that's run in ephemeral containers (Function as a Service or "FaaS"), the best known vendor host of which currently is AWS Lambda. By using these ideas, and by moving much behavior to the front end, such architectures remove the need for the traditional 'always on' server system sitting behind an application. Depending on the circumstances, such systems can significantly reduce operational cost and complexity at a cost of vendor dependencies and (at the moment) immaturity of supporting services. - @mikebroberts
- 21. DevOps –V- Security 2016 2012
- 22. My Timeline in Summary 1994 DB @ MS 1996 DBST Blog 1999 XP 2004 VisualOps 2006 CI blog 2008 VisualOps Security 2009 Flickr Presentation 2011 CI Book 2013 Phoenix Book 2016 SRE Book ???? DevOps Handbook
- 23. Any Questions No is a valid answer
- 24. * Section 2: What I’ve seen recently Revolution quote 2: “The first revolution is when you change your mind about how you look at things, and see there might be another way to look at it that you have not been shown. What you see later on is the results of that, but that revolution, that change that takes place will not be televised.” - Gil Scott-heron (1949 –2011)
- 27. BDD-Security does not need access to your source code to run its tests! Although the BDD tests are backed by Java, they are all executed over the network against a running instance of your app. The app under test can be written in any language and framework. If it talks HTTP/S, BDD-Security can test it.
- 28. Is it fast ? Does it scale ? Does it use python?
- 29. Is it fast ? Does it scale ? Does it use golang-go ?
- 30. Secure continuous delivery? Security Automation? Pipeline, CI, API, Monitoring?
- 31. Christer Edwards @ Adobe Gareth Rushgrove @ Puppet Labs Stephen de Vries @ Continuum Francois Raynaud @ dev sec con ltd
- 32. Any Questions No is a valid answer
- 33. * Bonus: and its not even Easter Commercial Tooling – has been tried but in my experience not widely adopted Disclaimer: I do not endorse any of these commercial products – they are here to make a point in my presentation !
- 34. There has always been a place for security operations automation tooling – this is not devOps
- 37. * Section 3: Tools you should know Classic DevOps toolbox Revolution quote 3: “There can't be any large-scale revolution until there's a personal revolution, on an individual level. It's got to happen inside first.” - Jim Morrison (1943 - 1971)
- 39. www.productname.io gitlab github bitbucket gerrit chef ansible puppet cfengine jenkins buildbot go-cd theforeman rundeck azure aws heroku openshift basecampnginx vagrant atlas virtualbox travis-ci pki.io docker swarm kubernetes quay.io mongodb couchdb ELK logly sensu pagerduty slack hipchat flowdock consul etcd confd registrator zookeeper openstack cucumber sonarqubejira bugzilla
- 40. * MAP31 : ‘obscure 1994 reference’ Couple Infosec titles worth a mention Disclaimer: I do recommend these
- 41. SecOps workflow based on bugzilla and version control Let me clarify one thing. Even Windows XP can be configured in such a way that it will become a very, very difficult target to exploit. For example: enable SRP application whitelisting and configure SRP properly. Install Browser-in-a- Box, only browse from that application, install all the latest updates, install EMET (the latest supported version for XP) and configure it properly. Install a proper AV, such as 360 Total Security (Chinese) (XP might still benefit from it), set up a Guest user account and a regular user account, set up proper passwords for all and only use the machine daily as a Guest-level account. When installing, elevate with Run-As. Regularly update the HOSTS file with blocked malicious domains (this is available from multiple sources and the task can be automated). Delete CMD.EXE, debug.exe, command.com and uninstall powershell. Delete reg.exe and regedit.exe after everything is set up and installed – use them from an external device if needed. Here you go! One paragraph, and the most “insecure” OS – Windows XP – has been secured properly. Git bitbucket heroku cloud9
- 42. Collaboration and Dashboards Faraday (pentesers) Threadfix (web app sec)
- 43. Collaboration and Dashboards Faraday (pentesers) Acunetix (REPORT) (XML) Amap (CONSOLE) Arachni (REPORT, CONSOLE) (XML) arp-scan (CONSOLE) BeEF (API) Burp, BurpPro (REPORT, API) (XML) Core Impact, Core Impact (REPORT) (XML) Dnsenum (CONSOLE) Dnsmap (CONSOLE) Dnsrecon (CONSOLE) Dnswalk (CONSOLE) evilgrade (API) Fierce (CONSOLE) Goohost (CONSOLE) Hydra (CONSOLE) (XML) Immunity Canvas (API) Maltego (REPORT) masscan (REPORT, CONSOLE) (XML) Medusa (CONSOLE) Metagoofil (CONSOLE) Metasploit, (REPORT, API) (XML) XML report Nessus, (REPORT) (XML .nessus) Netsparker (REPORT) (XML) Threadfix (web app sec) Trustwave Hailstorm Sonatype Contrast CheckMarx Black Duck IBM Security AppScan QualysGuard WAS WhiteHat Sentinel Veracode Burp Zap Acunetix Arachni Brakeman Nexpose, Nexpose Enterprise, (REPORT) (XML) Nikto (REPORT, CONSOLE) (XML) Nmap (REPORT, CONSOLE) (XML) Openvas (REPORT) (XML) PasteAnalyzer (CONSOLE) Peeping Tom (CONSOLE) propecia (CONSOLE) Qualysguard (REPORT) (XML) Retina (REPORT) (XML) Reverseraider (CONSOLE) Shodan (API) Skipfish (CONSOLE) Sqlmap (CONSOLE) SSHdefaultscan (CONSOLE) Theharvester (CONSOLE) W3af (REPORT) (XML) Wapiti (CONSOLE) Webfuzzer (CONSOLE) X1, Onapsis (REPORT) (XML) Zap (REPORT) (XML) Catnet Cenzix Clang Codeprofiler Findbugs Fortify Nessus Netsparker Skipfish Ssvl W3af webinspect
- 44. * Section 4: Learn From DevOps Revolution quote 4: “Yes, finally the tables are starting to turn. Talkin' bout a revolution, oh no Talkin' bout a revolution, oh.” - Tracy Chapman(1964 - present) And apply it to Information Security Controls
- 45. Disclaimer (1) I haven’t yet tried this next bit ;)
- 47. NSA Top 10 1. Application Whitelisting 2. Control Administrative Privileges 3. Limit Workstation-to-Workstation communication 4. Use Anti-Virus file reputation services 5. Enable Anti-Exploitation Features 6. Implement HIPS 7. Set a Secure baseline configuration 8. Use Web Domain reputation services 9. Take advantage of Software Improvements 10. Segregate Network and functions
- 48. checkout build report test deploy checkin 1. Application Whitelisting 2. Control Administrative Privileges 5. Enable Anti-Exploitation Features 6. Implement HIPS 7. Set a Secure baseline configuration 9. Take advantage of Software Improvements
- 49. CPNI Top 20 CPNI publishes v5 CIS (Benchmarks) taken up the project at v6
- 50. 1 - Inventory of Authorised and Unauthorised Devices 2 - Inventory of Authorised and Unauthorised Software 3 - Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations and Servers 4 - Continuous Vulnerability Assessment and Remediation 5 - Malware Defences 6 - Application Software Security 7 - Wireless Access Control 8 - Data Recovery Capability 9 - Security Skills Assessment and Appropriate Training to Fill Gaps 10 - Secure Configurations for Network Devices such as Firewalls, Routers and Switches 11 - Limitation and Control of Network Ports, Protocols and Services 12 - Controlled Use of Administrative Privileges 13 - Boundary Defence 14 - Maintenance, Monitoring and Analysis of Audit Logs 15 - Control Access Based on the Need to Know 16 - Account Monitoring and Control 17 - Data Protection 18 - Incident Response and Management 19 - Secure Network Engineering 20 - Penetration Tests and Red Team Exercises Did you know NSA have a project plan for the Top 20 ?
- 51. AusDSD Top 10 (of 35) Mitigation Strategy #1 – Application whitelisting Mitigation Strategy #2 – Patch applications Mitigation Strategy #3 – Patch operating system vulnerabilities Mitigation Strategy #4 – Restrict administrative privileges Mitigation Strategy #5 – User application configuration hardening Mitigation Strategy #6 – Automated dynamic analysis Mitigation Strategy #7 – Operating system generic exploit mitigation Mitigation Strategy #8 – Host‐based Intrusion Detection/Prevention System Mitigation Strategy #9 – Disable local administrator accounts Mitigation Strategy #10 – Network segmentation and segregation http://www.asd.gov.au/infosec/mitigationstr ategies.htm AusDSD version started in 2012, NSA version July 2013
- 52. AusDSD : the other 25 Mitigation Strategy #11 – Multi‐factor authentication Mitigation Strategy #12 – Software‐based application firewall, blocking incoming network traffic Mitigation Strategy #13 – Software‐based application firewall, blocking outgoing network traffic Mitigation Strategy #14 – Non‐persistent virtualised sandboxed trusted operating environment Mitigation Strategy #15 – Centralised and time‐synchronised logging of successful and failed computer events Mitigation Strategy #16 – Centralised and time‐synchronised logging of allowed and blocked network activity Mitigation Strategy #17 – Email content filtering Mitigation Strategy #18 – Web content filtering Mitigation Strategy #19 – Web domain whitelisting for all domains Mitigation Strategy #20 – Block spoofed emails Mitigation Strategy #21 – Workstation and server configuration management Mitigation Strategy #22 – Antivirus software using heuristics and automated Internet‐based reputation ratings Mitigation Strategy #23 – Deny direct Internet access from workstations Mitigation Strategy #24 – Server application configuration hardening Mitigation Strategy #25 – Enforce a strong passphrase policy Mitigation Strategy #26 – Removable and portable media control5 Mitigation Strategy #27 – Restrict access to Server Message Block (SMB) and NetBIOS Mitigation Strategy #28 – User education Mitigation Strategy #29 – Workstation inspection of Microsoft Office files Mitigation Strategy #30 – Signature‐based antivirus software Mitigation Strategy #31 – TLS encryption between email servers Mitigation Strategy #32 – Block attempts to access websites by their IP address Mitigation Strategy #33 – Network‐based Intrusion Detection/Prevention System Mitigation Strategy #34 – Gateway blacklisting Mitigation Strategy #35 – Capture network traffic http://www.asd.gov.au/infosec/mitigationstr ategies.htm
- 53. Summary There are many security controls that can benefit from checkin to SCM Basic Security template testing and deploying can benefit from DevOps mentality HIPS / FW rule tuning testing and deploying can benefit from DevOps mentality App Whitelisting rule tuning testing and deploying can benefit from DevOps mentality OS Patching testing and deploying can benefit from DevOps mentality App patching testing and deploying can benefit from DevOps mentality USB Monitor tuning testing and deploying can benefit from DevOps mentality Local admin group membership testing and deploying can benefit from DevOps mentality
- 54. Takeaways DevOps is a culture about speed, scale and automation Infosec should use the techniques of checkin / checkout / automatic deploy / report The automation has been maturing for over ten years (VisOps 2004, CI 2006) Developers with an interest in Security are driving the DevSecOps/DevSecCon movement Stephen de Vries & Gareth Rushgrove are pushing forward “Test Driven Security Controls”
- 55. Time is precious thank you for yours James
- 56. VisualOps Handbook & VisualOps Security – Gene Kim, Kevin Behr, George Spafford & Paul Love Extreme Programming Explained – Kent Beck Continuous Delivery – Jez Humble & David Farley One Minute Manager meets the Monkey – Ken Blanchard The Goal – Eliyahu M. Goldratt The Phoenix Project – Gene Kim, Kevin Behr, George Spafford Adventures of an IT Leader - Robert D. Austin, Shannon O'Donnell, Richard L Nolan Dev Ops 2.0 Toolkit - Viktor Farcic Pro Vagrant - Włodzimierz Gajda Ansible for DevOps - Jeff Geerling Ry’s GIT Tutorial - Ryan Hodson Site Reliability Engineering - Betsy Beyer and Chris Jones Infrastructure as Code - Kief Morris The Art of Monitoring – James Turnbull Logging and Log Management - by Anton Chuvakin, Kevin Schmidt, Chris Phillips Ruby on Rail s Tutorial – Michael Hartl Crafting the Infosec Playbook - Jeff Bollinger and Brandon Enright Building a cyber fortress – Alexander Sverdlov Booklist