devopsy.kinsta.cloud

Tag: trust

  • Security Should Be the Top Driver for DevOps

    Security Should Be the Top Driver for DevOps

    I’ve often said that the driving factor for many companies in adopting a comprehensive information security program are the dreaded “F” and “A” words – FUD and Audit. Technically FUD is an acronym for fear, uncertainty and doubt. And it might be better said that audit is the action used to hopefully demonstrate compliance and trust.

    Just a few years ago, the predominant drivers for security spending were regulatory and compliance requirements. While compliance remains a driver today, the primary moving force for many is the concern of cybercrime. Fear of being the next Sony, Target, Chase or countless other victims is driving information security budgets to be readdressed.

    In a recent CA survey the top obstacle (28%) to DevOps in their organization were security or compliance concerns. Yet, in the same study, a huge percentage (88%) already have or plan to adopt DevOps in the next 5 years. The dichotomy of the situation has not escaped me. Organizations are in a situation where they are actively spending money on DevOps and information security, but at the same time view these two initiatives as counter.

    The answer is simple, information security teams need to adopt DevOps principles.

    While a widely agreed upon definition of DevOps is still up for grabs, its safe to say that DevOps is generally inclusive of a few core tools and principles. First, DevOps promotes a culture of cooperation and sharing among different groups in an organization. Second, DevOps promotes the use of heavy automation, decreasing time to market and agile development.

    Information security’s goals are the CIA triad – confidentiality, integrity and availability. Security teams argue that DevOps is the antithesis of good security. Constant change, open culture and automation smack directly in the face of security’s tactics of compartmentalization and tight process control.

    Here is a little secret – DevOps is winning, information security is losing.

    DevOps teams are deploying code faster and faster. They are reducing time to market and increasing revenue. Information security teams, well, lets just say that they continue to be in the news for the wrong reasons.

    The second little secret – the companies which are really winning are using DevOps tools and principles everywhere in their organization. Even in information security. Imagine overseeing infrastructure configurations with code that ensures compliance 24×7 across an entire organization. Or picture being able to instrument thousands of data points to benchmark security performance over time. Conceptualize being in charge of an automatic closed-loop security system which automatically takes action to mitigate attacks based on shared threat intelligence. These are possible with DevOps.

    For all that DevOps provides, security should not be a hinderance to DevOps adoption. Instead, security should be a top driver for adopting DevOps. Using DevOps to create the next generation information security program might just be your only hope in combating the next cyber threat.

  • A Culture of Trust

    A Culture of Trust

    Trust is by far the most critical element of a DevOps culture.  It is also the most difficult to achieve.  IT was not built for trust.  The silo structure that is common in most IT organizations was built for specialization and territorial ownership.  The silo walls are thick.

    While DevOps may not be able to break down the silos, but it can encourage and groom a culture of trust.

    Trust is difficult to define.  We know when we feel it, we know when we don’t.   In 1993, Dr. Duane C. Tway, Jr. published a dissertation called “A Construct of Trust”.  In it, Dr. Tway defines trust as

    “The state of readiness for unguarded interaction with someone or something.”

    Dr. Tway believes that trust is actually “constructed” from three basic elements:

    • The capacity for trusting
    • The perception of competence
    • The perception of intentions

    The capacity for trusting is how your total life experiences have developed your current capacity and willingness to risk trusting others.

    The perception of competence is your perception of your ability and the ability of others with whom you work to perform competently at whatever is needed in the current situation.

    The perception of intentions is your perception that the actions, words, direction, mission and decisions are motivated by mutually-serving rather than self-serving motives.

    While trust is individual, a culture of trust is organizational.   Both are earned.  DevOps is a great opportunity to look at Dr. Tway’s construct of trust and identify small but meaningful opportunities to steadily increase the trust between Dev and Ops including

    • Improved and honest communications
    • Increased personal interaction
    • Honored commitments
    • More listening than talking
    • Frequent knowledge sharing
    • Welcomed input and feedback
    • Admitted mistakes
    • Intolerance of blame
    • Mutual respect
    • A celebration of mutual achievements

    What else could you do to increase the capacity for trusting, perception of competence and perception of intentions in your organization?   Perhaps you can start with an honest dialog with and between your Dev and Ops teams.  The answers may be surprising and insightful.

  • Trust & the trusted image

    Trust & the trusted image

    Graphic No BGWhat is Your Trust Model?

    Information security conversations often start with the question “What is your threat model?” This blog asks: “What is your trust model?”.  Trust is a complex subject and an integral part of managing DevOps-oriented organizations and highly automated IT infrastructures. Who (developers, ops) or what (code, process) is trusted to accomplish specific tasks in the infrastructure can sometimes be difficult to characterize to management, auditors, or in operational/incident reviews. The goal is to describe relationships among people and systems at work in the DevOps world and discuss approaches to making systems more transparent (to coders and non-coders!).  

    The Trusted Image

    Organizations like Amazon, Canonical, and Red Hat provide virtual machine images of popular operating system distributions. It’s common to launch these images directly “as-is” and install software onto them after launch.

    However, there are advantages to specializing one (or several) of these images and using it instead of the base OS image. A base image which has been supplemented with configuration and installed packages that suit the needs of your application is referred to as a “Trusted Image”.  And there is definitely value to putting your trust in a purpose-built and well-characterized image.   

    Why Make a Trusted Image?

    The reasons are several:

    Reliability: The more downloads that a VM requires in order to provision and configure, the more likely that something will go wrong. Network errors, outages at package repositories, and random download errors can render your VM unusable or unstable.  Building base packages into a trusted image minimizes problems.

    Secure Configuration: If there are configuration options that you want to ensure on every VM, you can build these settings into your trusted image. For example, you can configure firewall (iptables) in a trusted image to protect every VM that you launch.

    Secure Communication: If you want to use SSL or TLS inside your application, you can establish trust in a root certificate via a trusted image.

    Built-in Service “Wiring”: Do you want to ensure that the syslog of every VM you launch is sent to your logging server? Or to ensure that a specific version of Python, Ruby, Java, Node.js, etc is pre-installed on every VM that you launch? How about client libraries? A configuration management agent?  Build these into your trusted image.

    Speed: No more waiting for package installations; build them into your trusted image, and launch the end product faster.

    VM Identity and Authorization: You can build trusted images that will create an identity for each VM, and help the VM to get permissions to operate accordingly in your infrastructure. Bootstrap credentials can be used to access resources that the VM needs to join the application, such as database credentials, system passwords, API tokens, and other sensitive information.

    The Counterpoint..

    The use of trusted images can have drawbacks, for example:

    Security Patching:  Security updates from vendors are frequent. Any new image that you build will have all the latest security patches built into it; but your images will quickly get out of date as patches are released by your OS vendor.  One approach is to configure VMs to patch themselves on a schedule, for example, nightly during a “quiet period”. [ Note: Patching is tough. Please share your experiences with this problem! ]

    Management: Once you have built a trusted image, you will need a way to manage them. Image tags and other metadata features provided by your cloud can be helpful here. Treat your images like any other product of your build system: version them strictly and keep track of the provenance (history). Lastly, be sure that the system you use to build trusted images is itself trustworthy!

    Weighing the pros and cons

    Overall, for many organizations the security, performance and reliability benefits of the trusted images outweigh the drawbacks.  Would love to hear more experiences from those of you who use trusted images and who’ve considered trusted images but taken another path.