devopsy.kinsta.cloud

Tag: automated security

All Day DevOps: Exploring the New Ordinary
There you were. You heard about Docker, become mesmerized, floated into its new, special world … and then all chaos broke out. Things were not that easy and you scrambled for knowledge. Some folks saw the light and stepped forward, while others are still trying to figure the out the happy path home where containers will become part of their new ordinary.

This is the true story of Daniël van Gils (@foldingbeauty), a developer at Cloud 66, and the 12 steps he laid out in his Docker journey. He shared this journey during his presentation at the recent All Day DevOps conference, and I’ll share a summary of his steps here. His journey will take you full-circle, from your “ordinary IT world” to the “very special container world” and back, to where the container world is the new ordinary.

Containerization continues to be a hot topic in the software world, and one that is only going to grow and mature. As it matures, questions still abound:
- How can you implement containerization into your organization?
- Have you already started but run into roadblocks?
- How can you be the hero of your organization’s journey?
Daniël addressed this journey in his talk, “Docker Inside/Out,” at the recent All Day DevOps Conference.

Daniël’s journey started in the Ordinary World (#1), the world you might be in now. You are at a conference, you read a book, you talk to some colleagues and you want to jump into containers. You receive the Call to Adventure (#2) … but you are human, you like the safe, you fear the unknown, so you want to Refuse the Call (#3).

Thankfully, others—including Daniël—have taken the journey. They can take you under their wings, coddle you and then push you out of the nest. You Meet a Mentor (#4) and follow your heart. The heart is the good stuff—it is the core. Like most people probably would have, Daniël chose an artichoke to illustrate his point.

The heart of the artichoke is the good stuff, but the outer leaves protect the heart and make up the whole artichoke. Each aspect of an organization has something that drives them—their heart:
- Development – building elegantly performing code
- Operations – stable, performing code
- Business – delivering the right services to customers
- Customers – consuming the service they want
Your drive to satisfy the heart’s desire gives you the courage to Cross the Threshold (#5). You have a containerization machine, such as Docker. You put code in, creating nice little containers.

Now that your infrastructure is set up, you test and know where your allies and enemies are (#6). The most important lesson here is that shortcuts are your enemy. Shortcuts are evil, promising a life of ease but delivering a life of pain.

Daniël offers his Approach (#7) through the Docker journey to ensure you’re successful. You must KISSSSS:

Keep It…
- Slim – remove what you don’t need
- Secure – ensure you have the latest updates; remove all secrets
- Speedy – Follow best deployment practices and run performance tests
- Stable – Use version numbers for your Docker files
- Set – Immutable. Don’t put databases or complicated volumes into your containers. You can, but the the technology is still too new.
The next steps in his journey cover Ordeals, Death and Rebirth (#8). Once you pass this point in the journey, you’ll understand what it takes to run Docker in production and have shown the proof of concepts. You’ll then reap the Rewards (#9) and have clear visibility to your Road Back (#10) to the new ordinary.

For the successful heroes on this journey, now is your moment to shine. The next steps: your Resurrection (#11) and to Return with Elixir (#12) where containers are now the new ordinary.

If you want to learn more about Daniël’s Docker journey, be sure to watch his full All Day DevOps conference session (only 30 minutes). The other 56 presentations from the All Day DevOps Conference are available online, free-of-charge here.

This blog series is reviewing sessions from the All Day DevOps conference from November, which hosted more than 13,500 registered attendees. Last week I discussed, “One Team, 5,000 Jobs: Life in the DevOps Jungle.” Next week, look for “Launching Products at Massive Scale: The DevOps Way” presented by Kishore Jalleda and Gopal Moore.

— Derek E. Weeks
February 20, 2017
DevOps: Making the Boring Things Stay Boring
“I, For One, Welcome Our New Robot Overlords,” is the title of Mykel Alvis’ (@mykelalvis) session at the 2016 All Day DevOps Conference. He wasn’t trying to curry favor with the new robot rulers, a lá Kent Brockman, but, instead, was evangelizing on the importance of precision in DevOps.

Mykel is the DevOps Coach at Cotiviti Labs, the development arm of Cotiviti. Every day it handles healthcare data, which as you know happens to be some of the most regulated and protected data around. As Mykel said, “We don’t do cat pictures on the internet.” A mistake, breach, security flaw, etc., could mean the exposure of privacy and financial data for millions of people. But, it is a large organization, with exposure that needs to be managed. It has 200-plus repositories, three to four deployments per day, 15 developers and 0 operators (sort of). Without the right discipline and rigor, costly mistakes could happen.

Hence, Mykel’s need for the robot overlords. As he noted during the conference session, robots have, “Lower utility, but greater predictability.” They do exactly what they are told, and they do it the same way, every time. By contrast, humans are superior to responding to unpredictable events. Mykel’s goal is to leverage the strengths of each. Cotiviti Labs has systems, policies, procedures and a culture in place that supports the automation of tasks as much as possible to ensure mistakes are kept to a minimum and the humans can focus on the unpredictable. The company is striving to make the boring things stay boring. Cotiviti calls it “The Labs Way” and here is how it does it:
- Treat everything as code. Everything. Infrastructure, data, everything. As an example, it performs pull requests to get status updates for executive reports.
- Test the code.
- Perform formal releases. Cotiviti builds its code in very specific ways, with extremely rigid gatekeeping processes.
- Releases produce immutable artifacts. Once something has been released, it will never change it. It could, but it doesn’t.
- Keep everything. Not in a huge, unorganized file system. In an organized repository.
- Failing tests mean a failed build.
- Design your systems to be automated. Cotiviti doesn’t do things that can’t be done automatically.
- Deal with those systems only through automation. This is probably the most challenging thing it does since it is extremely hard to convince developers to write their code to do this.
- Operations IS developing. Operations is not a bucket for development. Operations is a development task. You treat it like it is real code.
- Because everything is code. Everything.
- All defects are defects of code.
To achieve this, Cotiviti:
1. Standardizes
2. Evaluates
3. Tests
4. Discards the useless
5. Owns it
None of this comes easy. It challenges norms. It pushes boundaries. It mandates discipline. (Pull quote – “Discipline is the bridge between goals and accomplishment.” – Jim Rohn) Your team has to understand you have a way to do things, there is a reason, and it will reduce risks and make sure everything works. It will keep the boring, boring.

You can watch Mykel’s full presentation from the All Day DevOps conference here (30 minutes). The other 56 presentations from the All Day DevOps Conference are available online, free-of-charge here.

Want more to read? This is blog series is reviewing sessions from the All Day DevOps conference from November which hosted over 13,500 registered attendees. Last week I discussed, “DevOps for Small Organizations: Lessons from Ed”. Next week, look for “Getting out of the Job Jungle with Jenkins,” a discussion by Damien Coraboeuf.

— Derek E. Weeks
January 25, 2017
SecDevOps: Security Automation By Example – The Firewall Change

Security Automation By Example

The Firewall Change

Just when you thought DevOps was the new black, along comes SecDevOps. Yes folks, like most things in life, the new cool is already here. Before I move on to trying to explain SecDevOps, please accept my mea culpa because for many people DevOps is yet to be clearly defined. I can imagine your frustration that I’m going to try and explain a new term based on a loosely defined term.

I’m not going to try and provide a complete definition of SecDevOps, but instead I’d like to provide what I believe to be important attributes of the SecDevOps movement. In this post, lets discuss security automation and use a firewall change process as an example.

One important attribute of SecDevOps is heavy use of security automation. In particular when I think security automation, I tell people to use IFTTT thinking. Stolen from the service whose tagline is “put the Internet to work for you”, I explain security automation simply as “if this, then that”. Its a highly simplistic, but poignant way to imagine ways in which one would automate workflow.

A simple act of changing a firewall has huge potential for security automation. The SecDevOps firewall change process goes beyond changing a few lines in a config, but also provides an independent and automated verification process that most organizations don’t perform today.

Consider what happens when a firewall policy is changed. First the policy change request is reviewed and approved. Then the policy change request is assigned and acted upon. Many times, but not always, the change is verified by another person through configuration review.

Security automation takes this process one step further. Imagine when a firewall is changed that a security audit event is automatically logged. Next, an automation component notices the firewall change and automatically spins up a remote scanning instance in a cloud provider. Next, that scanning instance is contacted using APIs to perform a remote network scan. The scan completes, results are exported and compared with prior scan results automatically. Finally, the automation component automatically updates the firewall change request in a ticketing system showing the scan results. We have now completed an automatic, independent and autonomous firewall change verification. That simplified yet powerful workflow is security automation and completes what many people refer to as a closed loop.

The new SecDevOps method for a firewall change not only provides a closed loop process, but does so by automating the verification steps. Joining traditional security processes with new API driven cloud services is a true force multiplier that many organizations will soon wish they had.

In upcoming posts, I’ll also discuss some of the other important components of what I believe make up the new black of SecDevOps.

April 30, 2014
What is Security Policy Orchestration and Why Should DevOps Teams Care?
After attending the DevOps day I wrote about in my last post, I wanted to take a minute to explain exactly what Security Policy Orchestration actually is so we can begin to understand how the two concepts overlap.

Simply put, Security Policy Orchestration is intelligent network change automation. It goes beyond simple task automation by truly understanding the network through simulation and analytics. It also gives security people an extra level of governance and control, which is so critical to assure security and business continuity.

Security Policy Orchestration reflects the growing relevance that managed security policies are having on IT systems. In network security lingo, security policies are firewall policies, but can also apply to Access Control Lists (ACLs), router and load balancer configurations. Managing security policies is an arduous task that requires automation, and Security Policy Orchestration has emerged in response to numerous factors happening in tandem – mainly, that:
- Business agility is gaining importance as a key competitive factor. This is creating an increased demand for automation across IT and, specifically at the network layer.
- IT organizations are pressured to match the speed, convenience and self-service provisioning the cloud environment offers for internal application deployment.
- Enterprise networks are growing larger and more complex with numerous traffic routing and shaping technologies to service multiple data centers.
- The widespread use of stateful and next-gen firewalls for external and internal network segmentation has significantly increased the size of the enterprise firewall estate, forcing security policies to morph into complex rule sets that map how business is conducted over the network.
The collective impact of these developments on network and security operations tasks is having a profound impact on people, processes and technology, including DevOps groups, who like their Security Operations (SecOps) brethren, are under pressure to roll out services faster.

Security Policy Orchestration helps to alleviate that pressure, enabling SecOps teams to keep up with the demands of the business while ensuring security and preventing an outage or a breach. Being able to automatically generate, provision and synchronize Security Policy changes across a growing set of systems – with security, compliance and governance concerns accounted for – means that security will not become a bottleneck that slows down DevOps teams.

While Security Policy Orchestration evolved out of network security operations, its benefits transcend security. Even though it will remain a SecOps function, its impact on DevOps is only going to increase, especially as Network and Security Operations continue to converge. However, the fundamental enabler of Security Policy Orchestration is automation.

As a result, there is significant common ground between DevOps and SecOps when it comes to automating application connectivity. This may not have been an issue for you yet, but my introduction to DevOps came from my experiences helping Tufin customers automate application connectivity. It’s a subject that is extremely germane to DevOps teams, and a topic that I plan to explore in depth in this blog because those of us leading the Orchestration charge within SecOps are kindred spirits with DevOps evangelists.

Contrary to popular belief, Security Policy Orchestration wasn’t created to restrict a company but to free it and help DevOps teams to accomplish its vision at the lowest IT risk level possible. After all, there is no such thing as bulletproof security where the Internet is concerned.

Instead, security folks focus on reducing risk, which puts us in a much better position to add value to the business. Plus, since so many of today’s biggest threats (i.e. APTs, for example) are network-based, introducing the tenets of Security Policy Orchestration – which literally automates best security practices into change processes – is in the mutual best interest of both SecOps and DevOps teams.

In my next post, I plan to dig into more detail on the stakes Security, Dev and Ops all share to make IT work faster, better and safer, and propose a few ways in which SecOps and DevOps teams can collaborate to gain some quick wins.
March 18, 2014