devopsy.kinsta.cloud

Tag: security

Murphy’s DevOps: Is Security Causing Things to Go Wrong?

“Rugged DevOps,” “DevSecOps”—am I missing any? About the only thing more abundant than the volume of terms emerging to describe different facets of how security supports DevOps are the number of vendors now claiming to provide products and services that “solve” related security problems.

There have been some interesting offerings we’ve seen emerge at this point and most of them probably have merit, in that they likely can accomplish the job they claim to do. Regardless of whether that “job” is actually something that needs to be done to solve a DevOps-related security issue, that is something for the professionals in the developer, operations and security worlds to determine—and hopefully something they will be interested in discussing here.

This new column’s point is to go looking for problems and solutions. Specifically, it’s focused on how and if DevOps is causing things to go wrong in security (and from time to time in other spots) and what DevOps-focused organizations are doing to correct course.

Security Questions to Ponder

Is it true that security can’t keep pace with “continuous?” Will “agile” and security always be oil and water? Will DevOps and security never achieve a harmonious “peanut butter and chocolate”-like relationship? Or, is the talk about how DevOps is the best thing that has ever happened to security and a great opportunity, actually the new reality?

Another great question this column seeks to answer is whether any of the “so-called” security problems DevOps is creating are anything new, or if they are the same old challenges that have existed since the first bit of sensitive data was exposed to the Internet decades ago.

There are times when I may mention specific vendor solutions in this column, but only if an actual end user or practitioner is attached to the reference. If that happens, I will always point out if any are clients of mine at my day job.

It’s no coincidence that this column is being launched just ahead of RSA 2016, as DevOps Connect: Rugged DevOps @ RSA Conference is a major part of the big show, and, that is where the world will be talking DevOps and security after all. Here’s hoping the event will expose problems and provide solutions.

February 29, 2016
How To Maintain Open Source Code Hygiene
To maintain good open source code hygiene in the development process, you must first establish what you mean by open source code hygiene, including good and bad hygiene. “By hygiene, we just mean is it appropriate? Is it clean for the intended use?” says Mike Pittenger, VP of Strategy at Black Duck Software.

Black Duck suggests three metrics it uses to determine whether it is appropriate to apply a given open source code project to a certain development endeavor:
- For software that will be distributed at large, avoid open source code that the development community has made available through a GPL license.
- For secure software, check your potential open source code for vulnerabilities in general and make sure to use the most secure version available.
- Monitor the code periodically to check for new vulnerabilities or other concerns.
As an example of the third point, Pittenger notes OpenSSL is no longer a viable option because of the vulnerabilities that have come to light in the form of Heartbleed.

Checking Source Code for Open Source Concerns

While the InfoSec Institute recommends at least 14 different open source vulnerability scanners for web applications alone, offerings such as Black Duck’s can serve as a shortcut to discovery of known bad open source components. “Instead of having to load Nessus, Metasploit or Nexpose with a Heartbleed rule and scanning every application, every server that they’ve got, they can just go into their Black Duck console, type in OpenSSL, and it would immediately show them every version they used in their software applications,” says Pittenger. Of course, you should always do your own due diligence to determine whether any scanning product is the best choice for your organization and aligns with your needs and requirements.

Due to the many open source code reuse scenarios active in enterprise DevOps shops, you will want to continually monitor code for newly registered vulnerabilities. Enterprises can view reusing existing assets as a built-in savings by not having to purchase or create new assets. In the case of reusing legacy source code, there is also a time savings, as developers want to shrink time to market for code-based projects.

“Let’s say you have a company that is pulling information from a database to display in pie charts. You have a rendering component that you will reuse. When you’re starting on a new product, do you build a new rendering library from scratch or do you use the existing one?” asks Pittenger.

Even if those components are open source, there can be great savings in reusing the library.

The fact that enterprises do this underlines the importance of continuing to check any code that leverages open source code, as this is how vulnerabilities can spread over time. It’s also important to check open source code, because it may be a form of low-hanging fruit for attackers. Open source code is fully viewable by attackers who build malware and launch attacks, whereas proprietary code is closed.

Since people constantly discover new vulnerabilities in open source code components that previously had tested free of such holes, it’s important to monitor those components for newly uncovered weaknesses, even as you reuse open software in new projects.

Containers are a great example. You may want to dismantle an image in varying degrees to build a new application. “If I have a base image and it’s built using a LAMP stack (i.e., a Linux OS, an Apache HTTP server, a MySQL RDBMS and PHP), I can strip down my base image, take away the existing app and take it all the way down to the Linux component, then build it up for the new application,” Pittenger said. “That is a typical, consistent reuse of open source components.”

During the process, recheck every component for vulnerabilities. Even if everything checks out doesn’t mean you have the best assurance of security for those components going forward. By monitoring those components, you can stay on top of updates to fix any newly discovered security holes.
February 24, 2016
Flash Mob Inflection: Rugged DevOps Revolution

Truthfully, I was never a huge fan of the HBO series “The Sopranos.” It’s not that it wasn’t entertaining; I just didn’t agree with the “best ever” label that so many espoused during the show’s halcyon days.

This had something to do with living in Hoboken, N.J., at the time and feeling the show was a heavily glamorized caricature of the real-life Mafioso I still perceived to be in my midst. More specifically, it’s hard for anything mob-related to stand up next to “Goodfellas” and “The Godfather”—among my favorite films, ever.

Either way, I currently find myself identifying with the series’ defining sentiment (copped directly from The Godfather, but hammered home as The Sopranos main theme): “Just when I thought I was out … they pull me back in.”

It wasn’t that I assumed that I’d never delve back into the domain of IT security after transitioning into the DevOps market last year; leveraging DevOps methodologies to improve security, policy compliance and related workflows stands as a core element of the overall movement.

But, in recent months and weeks it has become increasingly obvious that the security facet of the larger DevOps revolution appears poised for explosion as the buzz around emerging best practices, business models and solutions providers grows from a low hum into a steady roar.

After spending a few days talking DevOps security with Derek Weeks of Sonatype at CA World ’15 (we were booth neighbors and dinner mates) and giving more consideration to his company’s angle on securing the systems development life cycle (SDLC) supply chain, the internal gears really got spinning.

Regardless of whether you buy into Sonatype’s security-heavy approach, the concept of aggressively and proactively addressing security across the DevOps spectrum makes infinite sense. The ultimate downfall of applications security has always been the challenge of securing all the underlying layers of code (and today, microservices), especially as applications are assembled using heavier doses of shared, open source componentry.

As further evidence, nearly every major solutions vendor focused on the DevOps space—whether oriented toward the vibrant application performance management (APM), configuration management and continuous testing segments, among many others—seems to have launched some initiative aimed at integrating security into their products.

The rise of security capabilities adjacent to—and supporting inclusion into—the DevOps world, such as container giant Docker’s Content Trust initiative, along with the advancement of related startups including Twistlock, Scalock and StackRoxs, offers more proof of this growing momentum. And that’s only the container security piece of the puzzle.

Of course, there are also a number of emerging startups aimed at addressing the DevOps security opportunity, backed by well-known venture capitalists. A shortlist might include providers such as Immunio, Prevoty and UpGuard (formerly known as ScriptRock, which recently rebranded itself under the guise of a “DevOps security” provider), and we’re sure to see many more. And don’t forget the growing emphasis on DevOps security among established security industry stalwarts such as CyberArk, Snort and Tripwire, among others.

For a comprehensive list of the various types of DevOps security best practices and tools that we should expect to see gain wider adoption, this October 2015 blog by noted security analyst Adrian Lane of Securosis serves as a basic framework. Each of the areas of focus that he cites clearly offers significant opportunity for both new and existing methodologies.

Finally, one need look no further than this year’s RSA Security Conference, to be held in San Francisco at this end of this month, as tacit proof of the continued growth of what people now varyingly refer to as DevSecOps or Rugged DevOps (I prefer the latter as it just sounds cooler).

In addition to multiple conference sessions, notably a “DevOps Throwdown” between security industry veterans Caleb Sima, Chris Wysopal and Gary McGraw, there’s also the 2nd Annual DevOps Connect: Rugged DevOps Edition. If last year’s event is any indication (standing room only, venue literally at max capacity), this daylong DevOps security track at RSA will be an even more high-profile element of the entire week.

Further, if DevOps security—or, at the very least, the growing focus on adjacent segments such as container security—isn’t the unofficial theme of this year’s entire RSA show, I’d be extremely surprised.

Meanwhile (self-serving), my employer CA Technologies absolutely has a lot going on that complements and contributes to this growing DevOps Security market momentum.

For all of those reasons, here I find myself again, drawn closer back into the security space that I’ve called home for roughly the last decade. I guess that’s just how it goes, as DevOps and security are inarguably two of the most significant trends in IT these days and inextricably linked at their respective cores.

There are definitely worse fates out there. But, just when you think you’re out …

February 19, 2016
Cloud Security: Software Defined. Event Driven. Awesome.

I get it. Cloud and DevOps are disruptive and create new risks. I’m a security pro; one with decades of hard-earned experience telling me that with great chaos comes great opportunity… for the bad as much as the good. And once again it’s time to circle the wagons, make sure policies are enforced, and our organization’s are protected. Or maybe that’s just all the subliminal vendor FUD leaking past my mental firewalls.

But maybe it’s time to tell that part of my brain to shut the blank up and start looking for all the ways cloud and DevOps make things better for security. Because they do. And not merely on the surface, but in deeply fundamental changes that upend a lot of our previous conceptions. The best part is that, for once, all of this is real, practical, and achievable today.

Major cloud providers provide solid security foundations (otherwise no one can use them), typically better than most self-managed data centers. Great baseline security is all well and good, but I’m far more interesting in ways cloud enables us to do security better. Not a little better, but fundamentally improve our existing practices, processes, and capabilities. This isn’t a theoretical concept, but a practical one that some of us are using today in the real world, and I’m going to show you a concrete example.

These capabilities are thanks to Software Defined Security and Event Driven Security.

Software Defined Security is the ability to programmatically manage our security technologies, including the security capabilities of non-security technologies. For the most part it’s been an abysmal failure since security companies don’t exactly have the best track record when it comes to APIs and automation (well, outside of marketing materials). Even today the burgeoning on-premise automation tools often find themselves having to remotely log into consoles and issue command lines to manage activity. Security automation has usually been a good way to automate your rapid departure from your current employer.

Cloud computing changes that in two ways. First, the broad accessibility of robust REST-based APIs to manage security features of cloud services and, on occasion, security tools or services themselves. SOAP APIs are usually too difficult to work with for anyone short of dedicated developers, while REST is often consumable for strong scripters and admins. Second, the non-security APIs allow security professionals to integrate with the infrastructure and platforms directly. We now use the same interfaces as operations and development, except we can use them to achieve security objectives.

For example, at various conferences I demonstrate an automated incident response workflow that quarantines and instance, locks down the AWS management, images the storage, launches a forensics analysis server and connects the images, and performs a deep analysis of it’s state, connected resources, and potential exposure. An old version is up on GitHub and I have a vastly updated version I’ll be releasing soon. All of this happens in a few seconds.

Another example, in that same project, nearly instantly identifies any instance in your account not managed by Chef. Identifying unmanaged servers in a traditional network is a common audit function that takes weeks or months. In cloud computing it’s two API calls and a three line comparison function. Last year at the RSA Conference I demonstrated automatically inserting a cloud WAF in front of detected web servers in less than a minute.

The second piece of the puzzle is newer. With Event Driven Security we leverage the core instrumentation of infrastructure and platforms to detect events and initiate security automation. Until now nearly all security tools relied on polling/scanning or custom agents that have a pesky tendency to kill performance or otherwise break things. For example, instead of scanning the network to detect a change, the network tells us when it changes, and that event triggers actions. It’s a subset of Software Defined Security, yet still distinct.

In this example I posted earlier this week I leverage Amazon’s new CloudWatch events and Lambda to automatically revert any security group changes, or only changes that fail to meet certain criteria, within 10 seconds. You could use the some template to reverse nearly any change in your environment, or kick off more complex workflows like the automated incident response.

Software Defined Security allows us to build security operations that are as elastic and agile as the cloud itself. Event Driven Security further reduces the changes of manual error, bringing even greater automation and speed, especially when paired with frameworks and concepts like DevOps and immutable infrastructure. These aren’t new concepts, but unlike in the past they are viable and actively used by real organizations in real production environments.

The combination fundamentally changes how we can build our security programs. Yes, we can still do all the old things we’ve always done, but with a little creative thinking we gain entirely new, and practical, capabilities. It’s a ridiculously exciting time for our community and profession.

February 5, 2016
How DevOps Helps Improve Application Security

The DevOps trend is gathering pace, evolving from a niche to a mainstream strategy. Organizations are overcoming the barriers to successful implementation and finding real benefits in terms of speed and efficiency. But there are lingering issues to solve with regard to security. As companies look to push more changes to production more quickly, risks increase from multiple areas including integrating third-party software with known vulnerabilities, creating security defects in the code, not being able to fix the security issues that do arise and poor configuration.

According to the 2015 Cost of Data Breach Study from IBM and the Ponemon Institute, the average total cost of a data breach for participating companies increased 23 percent in the last two years to reach $3.79 million per breach. As DevOps presses ahead, security isn’t being considered often or early enough. Maybe a more “rugged” DevOps approach is needed.

Building in vulnerabilities

The vast majority of data breaches last year were entirely preventable. According to Verizon’s 2015 Data Breach Investigations Report, 99.9 percent of the exploited vulnerabilities were compromised more than a year after the Common Vulnerabilities and Exposures database, which lists known information security vulnerabilities and exposures, was published.

Developers frequently integrate open source code with third-party applications that have known vulnerabilities, providing would-be attackers with a way in. It’s difficult, time-consuming and expensive to close these loopholes after the fact.

Expand the DevOps mindset

We see many benefits when development and operations teams work closely together, so perhaps it’s time we applied the same logic to security and risk experts. Putting them into the DevOps mix earlier in the process could lead to an increase in empathy and understanding—and an injection of expertise at the outset that could save a lot of pain later in development.

Security and risk professionals can work directly with developers and operations to identify and remediate potential vulnerabilities. They can paint a picture of how to decrease the attack surface, set up alerts and boost response times.

Integrate automated security into your pipeline

If you can embed security goals into your continuous delivery processes, it should be possible to automate a lot of your security checks. Stick to the same principles as your wider development by making frequent, small, fast improvements to security. Automation can free up your security experts enough to find underlying weaknesses and tackle them.

The average organization receives almost 17,000 malware alerts in a typical week, but only 19 percent of those are deemed reliable, according to the Ponemon Institute, in this Malware Containment Report. This means two-thirds of security staff time is wasted because of faulty intelligence, at an average annual cost of $1.27 million. Only 41 percent of organizations have automated tools to capture intelligence and assess threats, but those that do report that 60 percent of malware containment can be handled without any human intervention.

It’s important that security professionals work directly with your developers and operations people to integrate vulnerability tests and security scans into your continuous delivery pipeline. They’re engaged in an ongoing battle with hackers, so make sure to continually review and tweak the tests that are run.

It also helps to have versioned definitions of all your systems, so you can readily and automatically scan for vulnerable systems when new vulnerabilities are announced.

Don’t forget to measure

Testing the effectiveness of your security measures is vital. Run penetration tests and employ destructive testing tools to see how well your processes stand up. Make sure you have clear remediation plans and that you can deploy quickly to roll back or forward to eliminate any vulnerabilities.

Security is too important to be an afterthought. We know there are lots of benefits to breaking down silos—let’s extend that beyond development and operations to include security. Build it into your continuous delivery pipeline and automate where possible, and you’ll get greater value from your security experts. You’ll also turn out better-quality software.

About the Author
Andrew Phillips is vice president, DevOps Strategy for XebiaLabs, a provider of automation software for DevOps and Continuous Delivery. He sits on the management team and drives product direction, positioning and planning.

January 11, 2016
Why do you need to implement a DevOpsSec team?

Just 20 years ago, organizations relied on a single wall of defense to secure their applications and networks. Fast forward to 2015 and that large fence is no longer adequate. With the proliferation of mobile, cloud and SaaS technology adding to the complexity of ever-advancing systems and networks, it becomes much more important that teams across an organization work together as one, toward a common goal. We’ve already seen enterprises adopting new methods of organizing internal structures to increase collaboration through DevOps, but as security continues to be top of mind for organizations, many are looking to further this approach by including the security team in the DevOps conversation. With a DevOpsSec team, organizations can work toward delivering software that is not just reliable, but also secure.

Introducing security to DevOps provides the means to this protection by reducing the number of bugs and vulnerabilities during the build process before code hits production systems. Moving security as close as possible to the code and data will bring a large number of high value benefits to an organization.

The first benefit of introducing security to DevOps is the enablement of team collaboration through tight feedback loops. Development, operations and security teams all have different goals and are motivated by different things, which are often contrary to the other teams. To ensure that these groups don’t work as adversaries within an organization, DevOpsSec encourages them to work together, pulling from all parties’ strengths and building a collaborative and engaging environment. This collaboration offers transparency into the assorted issues that arise within each team, establishing a deeper level of understanding and respect across the board.

The second benefit is that DevOpsSec provides a wider perspective across previously siloed teams. As a result of greater team collaboration, Dev, Ops and Sec teams are able to gain more insight into how the other teams operate. This widened perspective decreases friction between them, further revealing common goals and generating more natural solutions. Overall, the assortment of perspectives results in more efficient strategies for the organization in keeping its systems secure.

Lastly, the implementation of DevOpsSec ensures faster response time to issues. As applications and systems become more distributed and complex, it becomes more difficult to identify and fix bugs and vulnerabilities. Developers are writing and pushing code faster than ever before, and what used to be monthly or longer release cycles can now be measured in hours. This is due in part to the fact that code is being used both inside and outside our networks, requiring more thorough network security. The new normal will be found in developing DevOpsSec teams and moving the security as close as possible to the code and data. Through more continuous review processes and more ownership over code in production, the merging of DevOpsSec can mean faster times in closing feedback loops and will ultimately help organizations to operate more efficiently.

So what will an organization look like after implementing DevOpsSec? As a result of the cross pollination between teams, organizations will have curated an elevated platform for innovative ideas, gained greater insights across teams and developed faster response times to help the business run smoother. With DevOpsSec in affect, organizations will better understand and anticipate security issues and the decisions required to diminish them.

December 17, 2015
Culture, Behavior and Unconventional Strategy Plays a Major Role in Secure App Development

In today’s fast-paced environment, security often plays second fiddle to deadlines. That means software development doesn’t typically get considered when building secure applications, rather it’s the innovations that can be quickly implemented which take center stage. Unfortunately, ranking short term tactical gain over long term vision is undeniably flawed. Doing so ignores the fact that attacks are more sophisticated than ever before, and applications that have security holes have become a key focal point for those attackers because once a vulnerable application is discovered it becomes easier to compromise a wide set of users at once. But change requires more than drastic measures. It requires an unconventional strategy to adjust culture and behaviors throughout the organization.

Although the tools and practices to build secure, defect-tested software are maturing, most organizations find internal hurdles to be more daunting. Organizational impediments including process, differing software development approaches, and short-term business drivers – like the need to update apps to reflect the latest must-have features and platform support – make it more difficult to effect meaningful change. Those interested in leading secure development initiatives within their organizations face myriad challenges.

Step out of your comfort zone to influence culture, process and strategy change

Often, folks who find themselves in the position to step up to the plate and change culture did not initially plan to do so. The developer who is chosen to lead the charge and establish a process that ensures applications are securely built is extraordinarily smart and devoutly technical. In order to begin changing the world, he or she will need to utilize approaches outside of their comfort zone. Success will rely on the acknowledgement that a full frontal assault on the status quo will not do. Instead, hearts and minds must be won. The skill sets that propel developers’ careers forward must take a back seat to the forces of leadership and persuasion, not coercion, which will ultimately affect the cultural shift in an organization’s application development mindset.

To effectively change the way organizations build software, an enterprise-wide initiative is required – one that accounts for organizational culture at each step. By taking a step-by-step approach, implementing a successful software security initiative does not have to be so daunting. Five proven best practices include taking a disciplined approach by characterizing the landscape, securing champions, defining standards and strategy, executing, and then sustaining the effort. These steps, as outlined below, will help ensure that your corporate-wide efforts to secure applications are as productive as possible.

Characterize the Landscape – Understand the task ahead and craft a realistic strategy for adoption within your organization. Whether that be identifying your organization’s compliance framework and cultural norms, to artifacts of the software security and what software development lifecycles you have in place. Being able to characterize your existing landscape allows you to fill the gap between policy and practice.

Secure Champions – Focus explicitly on the fact that you will need clear support of executive sponsors and other key influencers in the organization in order to be successful. While senior leaders may not understand or care about the minutia of software vulnerabilities, they will appreciate the business impact of a data breach with far-reaching cost, reputation or legal repercussions.

Define Standards and Strategy – You will only have one opportunity to successfully roll out a secure development initiative, meaning you cannot overlook this step. Conduct a risk assessment of applications owned by your organization to identify the most vulnerable applications to provide some qualitative ranking for decision-making. Having a baseline set of practices and procedures that are well thought out, realistically implemented, and reflect what is realistic in your organization is absolutely critical.

Execution – So you’ve done your homework, secured supporters throughout the chain of command and in the field, and laid out your strategy and goals. Now comes the hard part – bringing the issue of software security to the forefront through innovative awareness campaigns. Remember, it will be important to show quick wins, highlight positive behaviors, and do it over and over again; ratcheting up expectations and software security with each iteration.

Sustainment – This follows the successful execution of your software security initiative campaign, which can take between one and two years. To ensure your campaign stays fresh and does not lose momentum, a regular, disciplined update of the regulatory framework must occur. In addition, staying knowledgeable about what is occurring within your organization to determine whether there are new technology risk areas emerging in critical.

Creating a software security initiative is difficult by any measure. From organizational culture or politics to the status quo bias towards meeting deadlines for new features and functionality, there is no limit to the amount of hurdles that need to be overcome. But by demonstrating the importance of looking long term from a security standpoint and winning the hearts and minds of everyone that plays a role, success can be achieved. Organizations that focus only on the tasks ahead of them do not change the world. Long term vision is critical for organizations that endeavor to strategically move, grow and change the status quo.

December 3, 2015
Bridging the gap between DevOps and Security
Security should be baked into the DevOps process, from tools to skills to collaboration. DevOps and security are not mutually exclusive.

The problem with digital innovation is that considerations for compliance come later, after the product or service is on the market. From public cloud infrastructure to Internet of Things to mobile apps and even to DevOps, tough requirements like security aren’t built into innovators’ plans. Entrepreneurs are thinking primarily about shiny, new, fast and disruptive. Yet for the CIO and other chief executives accountable to customers, laws and financial markets, managing risk around sensitive data is top priority.

DevOps processes are at the heart of business innovation: think Netflix, Facebook, Etsy and Nordstrom, all leaders in their sectors. Yet many of the popular DevOps tools and methodologies, whether commercial or open source, haven’t been optimized for the needs of enterprise security. An application running in a container, for instance, will still require attention around configuration to ensure application security.

As well, many security professionals haven’t yet made the leap to understanding the changing best practices for security in this new world of cloud/agile/mobile IT. Some security experts have imposed barriers to DevOps, by resisting the switch to faster, more iterative development along with the public cloud.

On the surface, the speed at which DevOps teams are approving and releasing code would suggest an increase in security risks to end users by eliminating rigorous security review phases. Yet managing security, as with testing, is in fact optimal when performed side-by-side with developers as code is being written. By integrating security, people and processes tightly within the continuous delivery cycle, DevOps can do a better job of eliminating loopholes and gaps in the code before production. DevOps tools emphasize the use of frequent and automated processes to improve software quality: also an ideal model for handling security testing and fixes. Determining the best way to merge security with DevOps is a work in progress. The following concepts can provide a framework for getting started:
1. Use the best of DevOps for security: DevOps, with its focus on automation and continuous integration, provides a more holistic framework for security management. Start by considering security through every step of the development and production cycle. Security professionals can help developers root out design problems in the beginning – such as ensuring all data transport is encrypted. Integrate automated security checks into development, testing and deployment phases, and educate all team members about the importance of incorporating security thinking in their specific job roles. Security should no longer be the last process before committing the code to production.
2. Investigate new DevOps and Cloud security tools: Fortunately, the security technology industry is ramping up quickly to the needs of DevOps security. Static Application Security (SAS) tools test for security when code is being written while Dynamic Application Security (DAS) tools test for interface risks. A few of the reputable systems include Checkmarx, Veracode and Parasoft. The third area of security automation tools covers penetration vulnerability testing, such as Nessus, developed by Tenable. Other contenders in this area include Qualys and OpenVAS. These tools can integrate smoothly into the software development lifecycle, such as by plugging into Jenkins. By adding automation, security is not only built-in, but doesn’t slow down the DevOps process.
3. Getting buy-in from security teams: This might just be the hardest part. While developers are incentivized to go faster and do more, security professionals are incentivized to control, monitor and reduce risk. Meeting in the middle is definitely possible – but it will require some opinion shifting on both sides. Developers and product managers will need to understand the importance of working collaboratively with the security team, and in an accountable way. Security people can benefit from a more comprehensive understanding of security in the cloud. This should include continuous education on the new tools and services available today to manage risk and to deliver even higher levels of security than in the past – from better reporting, to API-based security and easier encryption at rest.
1. Manage tool sprawl: The concept of self-organization is an important one in DevOps, because it fosters a spirit of flexibility and rapid collaboration. Yet this same principle can also lead to environments of dozens or even hundreds of different tools in use to manage deployment, configuration, QA and orchestration. That creates risks for visibility and monitoring as well as standardizing around security controls and access. Engineering leads should help strike a balance between too much and too little governance when it comes to tools and workflows by providing guidelines for tool selection. The DevOps automation infrastructure itself can introduce risks. If a hacker gains access to a tool like Puppet or Chef, he can modify any number of configurations and add new user accounts. Configuration and change management tools must be adequately secured and governed, lest they become a new attack plane.
With the advent of DevOps, there’s an opportunity at last for security to become an integral and seamless aspect of innovation. We think it’s not only possible but critical to give security the attention it demands in the world of fast IT.

About the Author/Kris Bliesner

Kris Bliesner is CTO and co-founder of 2nd Watch, where he oversees strategic and technical development of 2nd Watch’s cloud-based products and solutions. Prior to co-founding 2nd Watch in 2010, Kris held many top IT positions with companies including Microsoft and Ambassadors Group.

Connect with Kris: LinkedIn, Twitter, 2nd Watch Blog.
December 3, 2015
All Hallows Eve in DevOps

You never know

Here are some other ROELBOB’s you might like

A Containers Angst

The Pink Slip

Systems Orchestration

Hot off the Press – Other great devopsy.kinsta.cloud content

The DevOps Dozen

DevOps Must Also Mean OpsDev

Upcoming devopsy.kinsta.cloud Events

DevOps Connect: cdSummit SoCal

Webinar: Testing Infrastructure as Code with Security: 5 Practical Tips

— ROELBOB

October 30, 2015
DevOps Leadership Series 2015: Women & Diversity

Many of the leading minds and practitioners in the DevOps movement are women. I hope that comes as no surprise to you. DevOps has always embraced a diversity of thought and contribution. Case in point, close to 50% of the presenters at this year’s DevOps Days Boston event were women.

In this episode of the DevOps Leadership Series, we caught up with Jennifer Davis, co-author of Effective DevOps (O’Reilly 2015, $31) and software engineer at Chef. Jennifer discusses a greater diversification of what DevOps means. She sees more explicit efforts to expand DevOps into QA, security, DBAs, and other functional teams across the organization. Jennifer also discuss the benefit of re-setting one’s expectations on the meaning of certain words (e.g., agile, test driven development, audit driven development) to accelerate progress and remove roadblocks:

https://www.youtube.com/watch?v=B-zONUI5KQ4

We then sat down with James Meickle, Site Reliability Engineer at Harvard and member of the organizing committee for DevOps Days Boston. James witnessed distinct growth over last year in the diversity of companies in attendance — both from a size and industry perspective. James also discusses the importance of diversity that the organizing committee insisted upon as they planned for the event. If you are organizing your own DevOps Days event, be sure to have a listen:

https://www.youtube.com/watch?v=BZZCjw9YEps

If you missed part one of our series from DevOps Days Boston, be sure to watch these interviews from Beno Chapman of Constant Contact, Anthony Spring of Yieldbot, and Jeremiah Sullivan of Puppet Labs.

Want learn more from the leading minds in DevOps? You can find the entire library of 21 videos from this series on YouTube.

Special thanks to my colleague, Mark Miller for capturing these videos for us at the event.

October 1, 2015