devopsy.kinsta.cloud

Tag: security

  • DevOps Leadership Series 2015: Women & Diversity – a diversity of thought and contribution

    DevOps Leadership Series 2015: Women & Diversity – a diversity of thought and contribution

    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.

    Screen Shot 2015-09-30 at 5.40.06 PM

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

  • Bring Your Own Exploit

    Bring Your Own Exploit

    Here’s a simple question: for each tool that your organization uses, have you (or someone else on your DevOps team) changed the default passwords? That should be a no-brainer, shouldn’t it? Of course you changed them! Or at least you changed them for the tools that looked like they would have default passwords. Well, OK, at least the ones that looked like they might present an obvious security risk — and where you noticed that there was a default password. Would those other tools even provide an intruder with a useable exploit?

    (more…)

  • Security at the Speed of Innovation

    Security at the Speed of Innovation

    With the advent of the cloud and platform as a service (PaaS) offerings, developers are innovating faster than ever.  But with this rapid pace comes risk. Companies quickly implement new apps to meet their business demands, but the increasing complexity of the infrastructure being used – both in the cloud, on premise, or a hybrid combination – makes it difficult to ensure vulnerabilities are not introduced or vital corporate information is not exposed. In the quest to ensure that policy and governance are in place and security risks are negated, IT often brings innovation to a screeching halt.

    Is there a happy medium that enables developers to continue accelerating innovation, but makes IT confident there’s adequate security? In this article, we’ll look at the importance of governance and policy, and outline the five fundamental security requirements that will help enterprises bridge that chasm that currently separates development and IT.

    Policy Debt – The Downside of Faster Innovation

    Security flaws are not new. Enterprises have faced serious security problems for decades. As today’s computing landscape becomes increasingly diverse and complex with increasing use of the cloud, new vulnerabilities are introduced, which exacerbate problems with existing security methods, such as simple usernames and passwords and an over-reliance on network perimeter security models.

    The rapid introduction of new developer technologies far outpaces an enterprise’s ability to vet them. As a result, enterprise IT faces a tradeoff: rapidly adopt new technologies to satiate business demands thereby accepting more risk, or slow down new technology adoption with the hope of mitigating risk. Tension between enterprise IT and the rest of the business is the inevitable outcome. More importantly, because new apps have so many dependencies, as soon as one is put into production, an enterprise almost immediately incurs policy debt.

    Policy should enable enterprises to track these dependencies, but in today’s IT environments, each piece of infrastructure or cloud resource has its own unique policy model, operational mode and lifecycle.  As a result, enterprises end up with a layered cake of dependencies, which is difficult to keep track of and ensure no security holes are left unpatched.

    Most of today’s security technologies – like gateways and firewalls – are either point-based or palliative solutions. They treat symptoms rather than root causes. And, they only work for traffic that’s routed through them, which precludes most of the server-to-server interactions that happen within the datacenter. Reliance on gateways is akin to locking the deadbolt on the front door of your house but leaving the back door open.

    These simply are not enough to address the proliferation of attacks that have paralyzed companies and exposed customer and consumer data. Consider the three major security Linux exploits – Ghost, Shellshock and Heartbleed – that came to light in the past year.  To patch their systems against these problems, companies needed to find the vulnerabilities and reset servers to activate the fix, which resulted in a cascading failure of servers, downtime and a host of other performance-related issues – simply because there’s no centralized way to apply policy and determine whether a resource in use is vulnerable.

    The Fundamental Five Security Requirements in the Brave New IT World

    To fully protect their increasingly complex IT environments, there are five fundamental security requirements no enterprise should be without:

    1. Resource Naming and Identity – To secure access of a workload or process, it needs to be named so that it can referenced as logic is applied. There is no notion of identity for the applications running today. They’re simply workloads running on a CPU.  If enterprises want to apply policy, they will need an overlay operating system that gives identity to that workload, so it can be organized into a manageable, policy-driven hierarchy.  This type of naming scheme is being done for Internet domains, but there is nothing comparable for the data center that enables IT to find, maintain and operate workloads residing there, regardless of where they are physically run.
    2. Chain of Trust – In today’s data center topologies, no actual proof is needed to ensure that a holder of a token is exactly who it claims to be.  To guarantee a high level of proof of identity and actual trust of components, enterprises require a central signing authority that issues tokens to all clients and internal components. This ensures that the management backplane is resilient to token and credential theft, and the system offers a high degree of trust.
    3. Context Aware Policy – Most systems rely solely on role membership to make authorization decisions, such as  “who” can do “what” to “what.” But enterprises need to go further than that, with the use of a dynamic scripting language for authorization decisions. Every authorization decision will require information over and above simple role membership (date and time, authentication strength, targeted resource and more). The result is a system that adapts more easily to enterprise authorization requirements.
    4. Control of the Network – The network is a vital part of any enterprise system, and controlling access to network nodes is key for enterprise IT governance. Today, network access control is a hodge-podge combination of network perimeters, firewalls, VLANs, VXLans, proxies and security appliances. Workloads exist in network segments and workload connectivity is a function of network segment configuration. Over time, these configurations become rigid, brittle and difficult to maintain. To prevent this, enterprises need to control the network within the cluster so that any workload running must be given explicit access to the network and other workloads (via policy) in real time and regardless of physical properties of the infrastructure.
    5. Ephemeral Service Credentials – Applications and services require connectivity and sometimes credentials to talk to one another. Once an application gets a credential for a service, the application becomes responsible for safeguarding that credential. However, credentials sometimes leak — they can appear in log files or configuration files, and can even be scraped from memory. What enterprises need is a new approach to service access that binds a credential to an individual network path. This ensures that even if a credential were to leak, it couldn’t be used from another location on the network. Moreover, with this method credentials live only as long as an individual workload in the system, rotating every time the application stops and starts again. By taking this approach, the burden on applications for handling credentials is reduced, strains of NetOps and network perimeter security models at scale decreases, and weak links in the trust chain are removed. The result is a more secure system that you can trust without changing your existing investments.

    About the Author/Derek Collison

    derek-collison

    Derek Collison is founder and CEO of Apcera. An industry veteran and pioneer in large-scale distributed systems and enterprise computing, Derek has held executive positions at VMware, Google and TIBCO Software.  As CTO and chief architect of cloud application platforms at VMware, he co-founded the cloud computing group and designed and architected Cloud Foundry,the industry’s first open PaaS. During his time at Google, he co-founded the AJAX APIs group.

  • Sleep easy: release automation reduces DevOps security threats

    Sleep easy: release automation reduces DevOps security threats

    Sleep easy: release automation reduces DevOps security threats

    “Devops reigns”. “DevOps redefines the way services are launched and managed”. Just two of the recent headlines from the sea of coverage on DevOps. It’s a reasonable argument. The software development methodology emphasizes communication and collaboration between software developers and other IT professionals, and is quickly gaining ground as organizations see a way to launch services faster and improve operations performance. The current DevOps talent shortage also points to Fortune 1000 companies waking up to the difference DevOps can make.

    Here’s the catch. While DevOps appears the master and commander of faster feature releases, it also has the potential to expose software vulnerabilities and security threats in your production environments. We all know that assembling existing code is more efficient than rewriting it from scratch, for example. And when assembling applications from libraries, developers typically use the latest version of that code, assuming it is likely to have less bugs.

    However, new releases can open up new security vulnerabilities. Take the Spring Framework, for instance, a Java platform that provides comprehensive infrastructure support for developing Java applications. According to Joshua Corman, CTO of Sonatype, 81 of the 85 versions of the Spring Framework have known vulnerabilities.

    Software and security vulnerabilities can also rise to the surface unless there is an audit of the production software for security defects. Developers can easily pick up any code they choose without identifying the source or what they did with it. Speaking at the RSA Security Conference, David Mortman, chief security architect at Dell Software, explained that when he began software audits at the company, 198 known execution flaws were found in the code base—putting the company and its applications at risk. And this risk is set to do more harm as DevOps is used to develop physical ‘Internet of Things’ products and services.

    Here’s another fact to put the issue of security into context. Organizations collectively spend $20 billion every year on network security, $10 billion on host security and $5 billion on data security. And you know how much is invested in software supply chain security by all companies? Just half a billion dollars.

    It’s not all bad news though. During the RSA Security Conference, Mortman commented, “A good DevOps process should be implemented using automation tools that can help to track and document updates. DevOps is about change management, process flow and documenting those processes.”

    And automation really is the answer here. It enables you to bring your new products and services to market faster, whilst remaining in control. By automating your application release process, you package the release from your continuous integration tool and securely promote it to the next environment via a reusable work flow. You maintain complete visibility throughout—and there’s no disruption to the business.

    Any software vulnerabilities are quickly identified using role-based access controls: only authorized staff get to promote packages, and only approved packages can move through the lifecycle. Moreover, the automated deployment model ensures you keep track of the code goes on each server and with what configuration settings. And if you are not happy with any aspect of the release, automation enables you to roll back the deployment to its previous state. Finally, comprehensive audit reports help you see who did what and when throughout the entire release process.

    Automation delivers other unique attributes to reduce security risks:

    • Packages and promotion paths so you can be confident that what is deployed is correct
    • Workflows so you have a standard and quality-assured way to consistently           deploy new changes
    • Deployment models to ensure the correct setting and configurations are applied to each environment.

     

    Your development squad is under more pressure than ever to deliver more functionality, faster without disrupting current applications. By automating your application release process, you not only embrace DevOps in full strength, you also gain back control.

    About the Author/ Dr. Chris Boorman

    chris-boormanAs Chief Marketing Officer, Dr Chris Boorman is responsible for Automic’s worldwide marketing.
    Prior to joining Automic, Dr. Boorman served as Chief Marketing Officer for cloud collaboration vendor Huddle, and data integration leader Informatica.  He has over 20 years of experience leading international teams at enterprise companies including SDL, salesforce.com, VERITAS and Oracle. Reach him on Twitter: @CHBoorman

  • What is Adaptive Security?

    What is Adaptive Security?

    72 days after the fact AdultFriendFinder.com, a “very mature” dating site, realized they had been hacked. The VERY personal information of 3 million registrants has been held hostage. By now, it should be clear that in the modern software development world, old-style static security just won’t work. Of course, there are times when the static security model still applies  —  for example, on a relatively stable, hardware-based system with traditional, non-continuous deployment and a limited traffic volume. Such environments can easily be routed through a checkpoint with no significant loss in performance.

    (more…)

  • The DevOps and Security Manifesto

    The DevOps and Security Manifesto

    Early in Illumio’s history, I saw the future of DevOps security. The CISO of an electronics manufacturer brought us in to help secure a new support service that was built entirely in the cloud. After meeting with the security team, we were introduced to the application development team who cast a cold eye on our technology. About five minutes into the demo, the group’s manager asked to take control of the keyboard and start using our software. “I know how to use this. It’s like network-security Chef,” he said with a wry smile. He flew through the UI.

    Fast forward to the recent DevOps Connect event at RSA, which underscored the critical importance of cybersecurity to the application development process. If business increasingly relies on agile software development, the lack of corresponding fast-moving security approaches effectively increases the risk of a breach or a cyberattack. You cannot build and mount applications in a distributed application and computing environment and then rely on a static, hierarchical security model built upon chokepoints, infrastructure control points and organizational silos.

    Traditionally, one group created applications and another deployed them on the compute infrastructure. Then, a third group implemented security and ensured applications were trusted, particularly through instrumentation of the perimeter network security. Those days are disappearing.

    It is time for a new relationship – and new, shared technologies — among DevOps, infrastructure and security, expressed through what I believe are are 10 principles for DevOps and security.

    Principle I — No divine right of InfoSec primogeniture. Security must not be run in a silo. While security teams play the most critical role in assessing corporate risk and setting policy, there must be leadership and shared responsibility across various IT functions.

    Principle II — Orchestrate but remediate. Security must be as responsive to continuous delivery as application creation and scaling. Application developers need cool, agile tools for security, too.

    Principle III — Application developers must not put the organization in harm’s way. They must consider security at the beginning of the application development cycle and not simply hand off the responsibilities to others. Moreover, they must have security capabilities well instrumented into application development tools and infrastructure.

    Principle IV — Speed should not kill. Lack of speed hurts business. The spread of malware kills business. The speed of application development should not provide a corresponding acceleration in security risk.

    Principle V — Reduce the attack surface. Application developers must co-join with security teams to reduce the attack surface available to bad actors. By considering exposure and risk at the front end of the DevOps cycle, fewer issues should arise afterwards.

    Principle VI — Security must be built-in, not bolted on. Application and security architectures that can contain the threats are the order of the enterprise. To Principles IV and V, this increases organizational speed and reduces risk.

    Principle VII — Equality of the data center and cloud. Information security must be considered and deployed equally for the data center and the cloud. Separate but equal approaches are not the preferred path for IT professionals. The more widely distributed and deployed applications become, the more unified the security approach must be.

    Principle VIII — Stream, not batch. Security must deploy as streaming technology, not batch processes. There is no “set it and forget it” approach for security in a DevOps world.

    Principle IX — A minute lost finding a breach is unacceptable. Only a minimal amount of time (second, minutes) must pass in finding cyberattacks and breaches. Systems must be engineered for constant visibility and notification of policy violations.

    Principle X — Common Contribution. The maintenance of a strong DevOps security approach requires a shared contribution to application and security approaches toward the common good. The day of IT silos is ending.

    About the Author/Alan Cohen

    Illumio Photo, Alan CohenAlan Cohen – As chief commercial officer, Alan leads Illumio’s go-to-market strategy and customer engagement life cycle organizations, including marketing, support, talent, and IT. He is a 25-year technology veteran known for company building and new-market-creation experience. Alan’s prior two companies, Airespace (acquired by Cisco for $450 million) and Nicira (acquired by VMware for $1.26 billion), were the market leaders in centralized WLANs and network virtualization, respectively.

    Prior to Nicira, Alan led the enterprise marketing organization at Cisco, a team of 300 responsible for bringing to market an associated $25 billion product portfolio. He serves as an advisor to several technology companies including MobileIron, Highfive, and Netskope. Alan is a frequent industry speaker and commentator whose work has appeared in The New York Times, Fortune, Re/code, and Gigaom. He has a BA from SUNY Buffalo, an MA from the School of International Service at American University, and an MBA in Finance from the Stern School of Business at New York University.

  • Enterprise DevOps: Standardize for Security

    Enterprise DevOps: Standardize for Security

    Etsy is a shining example of the success that can be achieved with continuous delivery (CD). By 2014 Etsy had doubled its deployment rate, deploying more than 50 times a day. Today the site deploys API changes in 18 seconds and launches a new website every 150 seconds.

    That’s speed, to be sure. Speed that very few enterprises need or want to achieve. But that doesn’t mean that Etsy and CD don’t have valuable lessons for the enterprise, because one of the reasons CD and Etsy succeeds is because of the underlying principle of standardization.  

    Whether it’s standardization of tools or of processes – or both – it is standardization that eventually drives such speed. The use of the same tools and the same processes over and over hones them until they’re an optimized, lean delivery machine. That standardization has other, benefits, too that are as beneficial – maybe moreso – to the enterprise than the speed it eventually brings.

    Standardization of delivery processes in the enterprise, especially when extended to such concerns as security and the network, result in direct and indirect benefits. Directly, standardization allows security and even network infrastructure to ensure that corporate policies are implemented. If all infrastructure – application and network alike – should only be hosting certain services (like HTTP and SSH) and not others, standardization can help enforce that. Template-based (or policy-based, if you prefer) automation along with an “infrastructure as code” approach can assist in ensuring that basic security and network policies are put into place for every application deployed. Customization can (and should) be allowed and encouraged as extensions to the core templates (or policies) deployed during the app deployment process.

    Indirectly, standardization on a common toolset and processes will reduce the stress on network and security operations that comes from trying to implement common policies across a conga line of solutions. There’s no getting around the reality that many enterprises employ sometimes twenty or more “middle boxes” that provide everything from security to monitoring to performance and scalability services. Each one must be provisioned and configured during the app deployment process. This is not a trivial problem. 26% of organizations cited “security policies that are too complex and can’t be enforced with the current network security processes and controls” as a significant challenge in a 2014 ESG survey.  Establishing a standardized template that encapsulates common (required) policy implementations can go along way toward addressing the challenges network security professionals face when trying to secure applications across a growing portfolio of both applications and network services.

    app-cprThis level of standardization is not easily achieved. There is no easy button, and that’s one of the reasons DevOps can be a desirable approach in the enterprise to addressing these kinds of problems. It isn’t just about achieving phenomenal speed, but rather achieving consistency through the standardization of processes and methods used to deploy security policies and controls that can improve the stability and the security of the entire application and network environment.

    DevOps is, in relation to network and security operations, more about CPR for infrastructure services than it is speed. Consistency through standardization. Predictability through automation. Repeatability through templates and by treating infrastructure as code.

    DevOps is an approach to operations and inter-operations that can have just as many benefits in the enterprise as it does for web-scale and startups born in the cloud. The same standardization that benefits Etsy by giving it extreme speed can benefit enterprises by endowing it with extreme security.

  • Welcome to the ADC (After DevOps Connect) era of DevOps and Security

    Welcome to the ADC (After DevOps Connect) era of DevOps and Security

    I was speaking with Britta Glade of RSA Conference after our DevOps Connect conference at RSA Conference Monday.  She congratulated us on putting together a great day of tracks and sessions (kudos to Gene Kim and Josh Corman).  But then she said something else that really struck me to my core.  She said after today there is no longer any question about security working with DevOps.

    Think about it.  Three years after Josh and Gene first presented Rugged DevOps at RSA Conference. After so many papers, articles, presentations and tracks, it has finally sunk in.  Security will embrace DevOps, Security will be better because of DevOps and as importantly, DevOps will be better because of Security.

    It is very fulfilling to know that this event we produced (along with Mark Miller and theNexus Community) was what finally pushed this over the finish line. For me personally it really represents one of the fundamental reasons I was so attracted to DevOps.

    It was 4 or so years ago that I first met Gene Kim and over a bottle or two of wine he explained to me what DevOps was about and what he was working on with the Phoenix Project.  While DevOps may seem primarily about Dev and Ops to some, for me it was about making security work better. It seemed like such a no brainer that of course security should embrace DevOps.

    But it was not that easy.  The besieged security industry faced with a never ending barrage of breaches and a continually escalating threat environment could not accept that automation, acceleration, velocity would also allow us to shift security left, leaving us more secure and more compliant. Many security people dug in their heels and said no, this wouldn’t work and they didn’t take the time to really explore it.

    Monday all of that changed.  Security folk came out in droves to see people like Jez Humble (many people in the audience weren’t really familiar with Jez when he first took the stage, but they were enthralled with him by the time he stepped off. Jez finished to a standing room only crowd of close to 700. They heard Damon Edwards and Alex Honor talk. Though they were also unfamiliar to the crowd, their message resonated to the core.

    When Julie Tsai of Walmart took the stage the audience heard how a “unicorn” like Wal-Mart used Agile and DevOps to be more secure. Terri Pots of Raytheon and Jessica Davita of Microsoft re-enforced the message that security needs to embrace this approach. I loved Jessica’s security org chart.  Chris Corriere who writes here on devopsy.kinsta.cloud, Dr. Aaron Cois of Carnegie-Mellon also had great sessions.

    Then names familiar to the crowd, Gene Kim and Josh Corman kicked it off with a great talk on Software Supply Chains.  Nick Galbreath had a great session. David Mortman delivered a terrific talk, Dan Cornell on web app security and more.  For me the perfect ending was when my friend Rich Mogull took the stage and demonstrated his Squirrel Monkey toolset. Rich’s scripts that he wrote himself showed how we could use automation to make our security better and easier.  People were stunned.

    Throughout the day, the buzz that was coming down the big hallway was that there were some great things happening over at the DevOps tracks. People from the Cloud Security Alliance meeting next door were hopping over to check it out. Other people joined in.  By the end of the day we had given out all of the materials we had prepared.

    By now I know you are wishing you were there.  The good news is the entire event was videotaped. We will have videos and slides of all of the presentations shortly so stay tuned.

    We are already starting to plan next year’s event. Also, the call for speakers is now open for DevOps Connect: Rugged DevOps event @InfoSecurity Europe June 4th.  But after Monday DevOps and security will never be the same again.  No longer can security deny that they must be part of DevOps. We are and should be. We are now in the ADC (After DevOps Connect) era.

  • Security and DevOps: the horses are finally here

    Security and DevOps: the horses are finally here

    It doesn’t seem like it was so long ago when it was actually difficult to find enterprises and experts who could speak – from experience – about having successfully managed security in a DevOps environment. Sure, they existed, but they were primarily the so-called “unicorns:” web-based enterprises that had little of the legacy infrastructure in place that also needed to be secured. Enterprises such as Netflix, Etsy, Google, Amazon, and others for who the cloud and virtualization management and DevOps practices are as natural as water.

    Fortunately, we’ve now experienced a year where stories about traditional enterprises having successfully made the DevOps leap are commonplace, from Macy’s and Target and others at the DevOps Enterprise Summit, while Nationwide and many others at IBM InterConnect.

    Like those conferences above, this year the annual RSA Conference (the information security industry’s biggest show), and some of the approximate satellite events this week, will have many sessions relating to DevOps and security. Our own DevOps Connect: SecOps Edition, being held Monday at the Moscone Center, is a daylong event highlighting the intersection of DevOps and information security.

    At DevOps Connect: SecOps Edition there are a number of must see sessions, for me, including David Mortman’s DevOps Myths Versus Real World Realities, Julie Tsai’s Windfall Wins: DevOps Empowers Agile Security and Compliance, and Jez Humble on Continuous Delivery.

    Also, throughout the week there are many DevOps and security sessions throughout the week in application security related tracks. There will be a lot of interesting news and developments coming from those sessions throughout the week.

    Here are some, for those interested in learning more about DevOps and security, that look very worthwhile:

    Continuous Security: 5 Ways DevOps Improves Security

    Joshua Corman, Chief Technical Officer, Sonatype and David Mortman, Chief Security Architect, Dell

    DevOps is upon you and no longer just the provenance of start-ups. Josh and David will discuss how things have changed and five ways security gets better as a result of other teams doing DevOps.

    Enterprise Cloud Security via DevSecOps

    Scott Kennedy, Chief Security Scientist, Intuit; Shannon Lietz, Sr. Manager, DevSecOps, Intuit

    Securing innovation at scale in a cloud environment can be quite challenging. The goal of our talk is to share the lessons we learned about operating under the DevSecOps model.

    How to Avoid the Top 10 Software Security Flaws

    Gary McGraw, Chief Technical Officer, Cigital

    DevOps and automation tools are changing both the breadth and speed at which risk propagates. This session will cover both how to monitor and respond to them without alienating your DevOps team.

     Is DevOps Breaking Your Company?

    Elizabeth Lawler, Chief Executive Officer / Founder, Conjur, Inc.

    DevOps and automation tools are changing both the breadth and speed at which risk propagates. This session will cover both how to monitor and respond to them without alienating your DevOps team.

      Containers vs. VMs for Secure Cloud Applications

    App developers and PaaS platforms are adopting containers to simplify app packaging, deployment and orchestration. But there has been no pause for thought about security and compliance.

    Participants:

    Simon Crosby – Chief Technical Officer, Bromium Inc

    Christofer Hoff – Vice President and Security Chief Technology Officer, Juniper Networks

    Mark Russinovich – Chief Technology Officer, Azure, Microsoft

    Scott Johnston – Senior Vice President Product, Docker

    How Security Can Be the Next Force Multiplier in DevOps

    Andrew Storms Vice President, Security Services, New Context

    DevOps is the hottest moving target when it comes to software development methodologies. Many people fear that this fast paced, barrier breaking movement will leave information security best practices.

    After the week is over, a great deal more security professionals in the industry should have a stronger grip on how to better incorporate security into DevOps practices and improve enterprise IT outcomes while reducing risk.

  • DevOps Security Talks At RSA USA 2015 Conference

    DevOps Security Talks At RSA USA 2015 Conference

    DevOps and security. Its a muddled mix of waters made even more confusing by the wet ink still on the concept of DevOps. There is no denying the popularity of DevOps and there is a lot of talk on how the DevOps movement functions alongside security teams.

    The annual USA RSA conference is just around the corner and its worth noting a handful of DevOps focused talks deserving of your attention.

    I am anticipating a lot of common themes around integrating DevOps and Security regarding tools, processes and culture. Given the history of these speakers, you can probably anticipate many of them to be on the bandwagon of security and DevOps folks better learn to work together and learn from each other or be prepared to find a new job.

    If I missed a talk that specifically covers the nexus of DevOps and Security at RSA USA this year, please leave a comment and I’ll be sure to get it included.