DevSecOps

DevOps and Continuous Integration (CI) run hand in hand in helping create optimized consistent delivery of production services.  Optimal in that developers and operators become one team that addresses both functional and systems level thinking into developing a key service for the enterprise.  Thru this integrated team approach, the people who build it, operate it, and further this integrated team will manage everything from software..systems fixes and improvements.  A typicaly way of operating in these small agile teams is using a version control system [ typically git ].  Where, upon a source code change, a robot picks up the code [all of it] and the installer and then tests the component in the scope of the full system.  The interesting new piece of this is the

Star Trek Food Synthesizer

Star Trek Food Synthesizer

installer… we can think of this as a Digital Recipe which is interpreted by robot to perform a set of choreographed tasks.  Typically coded in a language like Y[a]ML, these recipes are typically modular, polymorphic, compositional and support $variable replacement and offer great ways to automate manual – often complex tasks.

So for me running IT substantially on Digital Recipes, and moving those from stacks -> services (multi-stack), provides a strong inventory capability to help understand the ingredients (and their versions).  This in and of itself assists in patching or vulnerability assessment.. think things like heartbleed which affected certain versions of OpenSSH… [Ansible configure sshd play example here ] being able to say these 40 systems are running that version is important to understanding risk and then automating response [such as disabling insecure protocol handlers].

As we move further towards orchestration with platforms like Ansible/Slam.io (csc opensource contribution ->coming) we have the ability to provide tagged aspects that are late bound to enable consistent cyber facets to be bound within the plays (hooks to monitoring systems, notifiers to vulnerability scanners, registers of systems w/ relative priority/business importance).

Further, these Digital Recipes WILL include firewalls/rules, acceptable meta-route paths (to the target upstream or downstream systems), and even API AuthZ instructions that enable the hardening / encapsulation of the workload with a set of consistent and auditable controls… (again these controls can register with GRC systems so that auditability can be guaranteed)

Then we move these patterned and orchestrated bundles into the CI frameworks, where we can begin build test strategies to validate the cyber controls, but also application vulnerabilities… one of the key insertion point these days is SQLInjection -> Privileged execution… building these tests into the CI cycle creates a more secure code base that naturally fits into a more standardized operational perspective… #DevSecOps realized.

The last step is the learning path… how do we teach operators to use Dev/InfraOps techniques via @cpswan and the folks at katacode we can document the playbooks so that the choreography becomes a description of what is done to a system to improve maintainability and audit-ability, while driving a browser based interaction model.

 

Thanks Vittal for stimulating the sharing of these ideas.

Leave a Reply