devopsy.kinsta.cloud

Tag: devsecops

  • Cloud Services Demand Security Up the DevOps Stack

    Cloud Services Demand Security Up the DevOps Stack

    In the era of soaring use of public cloud by companies, software delivery is moving away from an on-premises install approach to a cloud-based subscription model through software as a service (SaaS).

    Customers expect a lot when it comes to SaaS products and services. Whether they are investing in SaaS-first offerings or shifting workloads to cloud-based providers, companies no longer have upfront costs for hardware and related software or a reliance on costly labor to install, manage and secure it. They expect software that is easy to launch, upgrades that are unobtrusive and feature-rich and limitless scaling to meet their changing business needs.

    When it comes to security, the cloud-based subscription model significantly changes the paradigm of how software security should be treated. Fortunately for many cloud providers, customers trust that a strong foundational security and privacy posture has been built into to the service by design. Preserving that trust requires a healthy tension of shared responsibility between the security teams demanding it and the cloud providers offering it. A new paradigm shift requires a deeper acknowledgement that an emphasis of the security problem “up the stack” to the application layer is needed.

    For security teams, ensuring the protection is built in from the beginning and moves dynamically in lockstep with the workloads requires a much closer partnership with application developers and DevOps teams. This ultimately leads to a richer understanding of the business applications by security teams, creating a more cooperative business-aware and security-minded culture. Getting there will help reduce the tension and improve the overall delivery of secure cloud services regardless of where you sit in the cloud provider/consumer ecosystem and ultimately enables value creation to the business. To get there, a strong partnership must be fostered.

    There are obstacles to moving up the stack. In most companies, the reality is that many security teams are not well-aligned to keep up with this change while the business continues to make cloud-based investments, making the problem worse. Security’s comfort zone seems very much still focused on perimeter defense, but this emphasis isn’t optimally aligned to a cloud-first future. Even when forward-leaning security shops realize a need to change, they often get pushback from app developer teams because security reviews can delay deployment and security tools create “noise” and false positives for app developers. Also, traditional security tools often do not work well in cloud environments.

    Interestingly enough, the No. 1 concern of app developers is preventing data breaches and cyberattacks, a survey of 500 developers and development managers by Veracode found. Less than one-quarter of developers said meeting customer or regulatory compliance is their top concern, while 21 percent said meeting budget and delivery schedules is their top concern, and 19.4 percent said delivering secure code to pass internal audits is a priority. Furthermore, app developers who work with security teams get “major and tangible business and technical benefit,” according to a survey of 150 security and app development pros conducted by Forrester Consulting. Almost all of the collaborators said that working together leads to major or moderate benefit in customer satisfaction.

    Respondents said the more frequently they collaborate, the better the results, “including improved customer satisfaction, business/IT alignment, quality and frequency of releases, and the rate of innovation at their firms.”

    By overcoming barriers to collaboration, app developers and security teams can leverage this knowledge to improve their approach and also come to the table with solutions aligned at moving up the stack. First, they can perform code analysis to uncover vulnerabilities early in the app development process. Second, they can work on stronger runtime protection once the SaaS application is deployed. Code analysis can be used to make runtime protection better, and runtime data can be used to improve code analysis. This creates a continuous improvement loop between the two and both teams can work on code analysis and runtime protection together.

    To achieve this continuous improvement loop, companies must work to break down traditional work silos that exist because of a mismatch in expectations. App developers, measured for speed, need to receive security information accurately, early and with sufficient context to correct problems during software development. Security pros can benefit by installing security tools in production that understand the security needs of their applications, as opposed to tools that require security pros to write rules, tune the tool and then deal with large number of alerts.

    The goal is to fix software mistakes, weaknesses and vulnerabilities at the beginning of the development process rather than after deployment, when liability, revenue and reputational risks are the greatest. It is also important to realize that achieving zero defects in source code is a noble but difficult-to-achieve goal. Instead of focusing on extremes, the goal should be to establish a continuous improvement logic in CI/CD (continuous integration/continuous deployment), where bugs are identified, some are fixed and the remainder have fast and accurate runtime protection.

    This shift in thinking and processes will give companies fewer security worries and enable them to more proactively embrace a SaaS-first mentality with higher confidence and trust levels. Companies will reap the financial benefits that come with strengthened industry reputations for rapid innovation capabilities and improved levels of software security.

    About the Authors

     Manish Gupta is founder and CEO of ShiftLeft Inc. He is a 20-year veteran of the security industry and has led product development, management and strategy at FireEye, Cisco Systems, Intel, McAfee and Redback Networks.

     

     

    Craig Rosen is vice president and CISO at AppDynamics. He has held leadership roles for more than two decades in the security industry, including at FireEye, Pacific Gas & Electric, TDI and CGI.

  • DevSecOps: Security Needn’t be Sacrificed for Speed

    DevSecOps: Security Needn’t be Sacrificed for Speed

    With the right practices, security needn’t be an impediment to continuous development and rapid improvement.

    The same cycle keeps repeating, according to IT security and risk management consultancy Sense of Security co-founder and CTO Murray Goldschmidt. A new technology is hyped, leading to rapid adoption, but security is left as an afterthought. It happened with WiFi and voice over IP (VoIP), he says, and is currently happening with the internet of things (IoT). But it doesn’t have to be that way.

    DevSecOps: DevOps + Security

    DevOps is good for making things better, faster. But there tends to be a culture clash between those talking about speed, velocity or agility and those concerned with issues such as control points.

    So Goldschmidt and his colleagues are showing their clients how security can be integrated into DevOps (DevSecOps) in an automated manner without affecting velocity.

    Most people with development, operations or cloud backgrounds aren’t well-versed in security, he suggests, so Sense of Security shows clients how DevSecOps means security and DevOps can run in parallel.

    “It’s not that complicated,” he says, but it’s something most people don’t think about.

    Organizations often have a vulnerability management life cycle to identify and treat issues. After all, that’s part of various industry standards.

    The typical approach is an annual penetration test to find issues, which can then be addressed.

    A better way is to move to automated testing, and there are various commercial and open-source products to do that job. Goldschmidt says he sees little resistance to this idea.

    The next step is to go from scheduling these vulnerability scans on a quarterly basis to weekly or daily—or even to run them continuously.

    Citing the Struts vulnerability that caused a big problem for Equifax, he notes the challenge is to identify vulnerabilities in your systems before an attacker does. Continuous automated scanning means the window of vulnerability is very narrow.

    This idea is simple enough, he says, but for some reason it doesn’t occur to most people until someone brings it to their attention.

    When a scan reveals a vulnerability, its significance (severe, medium, etc.) is used to prioritize remediation.

    “DevOps guys understand those triggers,” he observes: If you give them the data, they can take the necessary actions. For example, that might mean shutting down the servers in a small web farm one at a time, applying the patch, restarting and moving on to the next. They could all be patched and running by the end of the day.

    Patching Isn’t Everything

    However, “it is unfair to assume organizations can patch things quickly” every time, he says. For example, the Struts vulnerability required more than just a patch—the code running on it had to be recompiled and tested, and that process could take months in a large organization.

    So organizations should not rely on the idea that patching is the fix for a vulnerability. While patches will be applied eventually, if you can make it difficult to actually take advantage of any exploits, the risk of data breaches is very low.

    One very easy-to-implement example of these measures is using a stateful firewall to ensure inbound-only access to web servers. By disallowing outbound access—”the channel through which data is lost”—there is no path for data to leave.

    Goldschmidt also recommends using tools to examine in-house code and the open-source and commercial code that is used with it. Such tools can detect most common problems, including openings for SQL injection, cross-site scripting and token misuse.

    He describes these tools as being the equivalent of “spellcheck for developers,” and says it reduces the likelihood of putting insecure code into production.

    The market includes products from Veracode (now part of CA), Sonatype and Qualys.

    Qualys, he notes, provides differential reporting. This makes it obvious that something has changed, and “that is the key to automation.” Whether the system itself has changed or new information has been discovered about vulnerabilities or configuration issues, action is required.

    Furthermore, the ease of making configuration changes that could have security implications makes continuous scanning even more important.

    These checks should not be limited to individual modules. Rather, they should be repeated—preferably automatically—as modules are assembled to help developers avoid poor code and to check the overall product.

    RASP Away Some Attacks

    Runtime application self-protection (RASP) is another technology Goldschmidt advocates. The idea is to detect abnormal and possibly malicious activity. One example is that normal operation would see an application communicating with its application server, and the application server communicating with the database. If the application suddenly makes a direct request to the database—as happens in an SQL injection attack—action is clearly required.

    Depending on the situation, RASP might raise an alert or immediately terminate the application, among other possibilities.

    The use of these and other technologies and techniques should allow organizations to run at the pace implied by DevOps without sacrificing security.

    — Stephen Withers

  • DevSecOps: IoT Right and Nobody Dies

    DevSecOps: IoT Right and Nobody Dies

    Dr. Suzanne Schwartz, CDRH Associate Director for Science and Strategic Partnerships at the Food and Drug Administration (FDA), recently released a blog to update us on the FDA’s role in medical device cybersecurity.

    Cybersecurity risks in medical devices are nothing new. As far back as 2012, Sonatype published warnings of security risks in pacemakers that could lead to lethal attacks. Last year, Johnson & Johnson warned of cyber vulnerabilities in its insulin pumps. More recently, our “2017 State of the Software Supply Chain Report” shared details of pacemaker programming machines that were discovered to have more than 8,000 known software vulnerabilities (see page 37).

    When it comes to software in medical and other devices, cybersecurity will be a constant threat requiring constant vigilance. The encouraging guidance I read from the FDA blog was that cybersecurity should not be limited to devices already on the market, but that security needs build in throughout the product life cycle. Schwartz remarked:

    “It is the goal of FDA’s Center for Devices and Radiological Health to encourage a coordinated approach of vigilance, responsiveness, resilience, and recovery that fits our culture of continuous quality improvement.

    “This means taking a total product lifecycle approach, starting at the product design phase when we build in security to help foil potential risks, followed by having a plan in place for managing any risks that might emerge, and planning for how to reduce the likelihood of future risks.”

    In these two brief statements, Schwartz shares views that are common in many of today’s DevSecOps conversations. Perhaps she has been listening in?

    The first view is that we need to “emphasize the performance of the entire system and never pass a defect downstream” (Gene Kim’s first way of DevOps). Schwartz recommends that device manufacturers start by building security in at the earliest stages of the development life cycle. Security cannot be an afterthought.

    Schwartz also recognizes that even when precautions are taken early in the life cycle, risks can emerge over time as new vulnerabilities are discovered. When it comes to device security, vigilance must be continuous across the development life cycle and over the product’s life in the market. As we have said for years, software ages like milk, not wine. Constant vigilance improves our ability to identify risks, initiate feedback to development teams and remediate issues in the device’s software. The faster we can address risks when they appear, the safer we can make the lives of consumers who rely on them.

    I applaud the FDA’s guidance and its proactive stance here to work with device manufactures. What we don’t want is a knee-jerk reaction to medical device security after someone has died. What we need is for security to be ingrained in the planning, design, production and maintenance of medical devices our families rely upon.

    You can read the full blog from Schwartz on the FDA Voice.

    — Derek E. Weeks

  • DevSecOps and DevNetOps: New Heroes in the DevOps Saga

    DevSecOps and DevNetOps: New Heroes in the DevOps Saga

    The evolution of DevOps is by no means done, but it’s safe to say that there is enough agreement and acceptance to declare it a hero. DevOps has helped glorify IT to the point where it’s no longer preventing business, nor a provider nor a partner of the business.

    Often IT is the business, or its vanguard for competitive disruption and differentiation.

    Splintering the success of this portmanteau hero, we now hear more and more of two trusty sidekicks: DevSecOps and DevNetOps. Lesser known in their adolescence, these tots are still frequently misunderstood, are still forming their identities, and still need a lot of development if they’re to enter the IT hall of fame like their forerunner.

    Just as the terms look, DevSecOps and DevNetOps are often assumed to be about wrapping DevOps principles around security and networking: operators hope to assuage technical debt and drudgery by automating in proficiency and resiliency. For networking, I’ve covered how there is a lot more to that than coding, but to be sure, these sidekicks certainly espouse operators learning how to do develop while DevOps was equally, if not more, about developers learning to operate.

    The Shift Left: SecDevOps and NetDevOps

    As if it wasn’t hard enough to tell what DevSecOps and DevNetOps want to be when they grow up, we’ve gone and given them alter egos: SecDevOps (aka “rugged” DevOps) and NetDevOps. Think about them exactly as the words look—it’s about the shift to the left. Left of what?

    Traditional DevOps practices focus on business-specific applications development. The development timeline is known as a concept to cash, and with all the superpowers of DevOps we try to reduce our enemy—the lead time and repeatable processes between code and cash.

    Security and building infrastructure, like networks, were considered supporting tasks, not revenue-generating nor competitive advantages. Thus, security and networking were far to the right on the timeline with concerns that deal with operational scale, performance and protection.

    Today’s shift left propels security and infrastructure considerations earlier down the timeline, into coding, architecture and pre-production systems. It’s a palpable penny-drop amid daily news of security breaches and infrastructure outages causing technology-defined establishments to bleed money and brand equity.

    Fill the bucket with cash, but don’t forget to forestall the leaks!

    DevOps and Infrastructure: Challenge and Opportunity

    Automation sparks have flown over the proverbial wall into the camp of I&O pros. Operators trading physical for virtual, macro for micro, converged for composed, and configuration for code is proof that the fire has caught security and networking. Controlling the burn now, is key, so that healthier skills and structures arise in place of the I&O dogma and duff. Fortunately, this is precisely the destiny for our newfound heroes, DevSecOps and DevNetOps.

    However, doing DevSecOps and DevNetOps, embracing security and networks as code, we mustn’t be so credulous as to forget the formidable DevOps practices and patterns that need transforming along the ultimate automation journey. Testability, immutability, upgradability, traceability, auditability, reliability and other you-name-it-abilities are not straightforward to achieve.

    Discounting “aaS” technology consumed as a service, a fundamental challenge to innovating SecOps and NetOps, compared to application ops, is that applications are crafted and built; security and networking solutions are mostly still bought and assembled.

    Security and network infrastructure as code is something that needs to be co-created with the vendors. Other than in the cloud, it will take a while before security and networking systems are driven API-first, and redesigned to offer simulation, finer disaggregation into microservices, and orchestration with scale and resilience.

    While this will land first in software-defined infrastructure, there is still a way to go to manage most software-defined security and networking systems with continuous practices of artifact integration, testing and deployment. Hardware and embedded software will be even more challenging.

    Finding Strength in Challenge

    So on one hand, DevOps is evolving with security and networking shifting left. On the other hand, traditional security and networking ops are transforming with DevOps principles.

    Is the ultimate innovation to squeeze out those traditional operations altogether? Does NetDevOps + DevNetOps = DevOps?

    There is a parallel train of thought and debate, with success on both sides. Purist teams cut out operations with the “you build it, you run it” attitude. Other companies such as Google have dedicated operations specialist teams of SREs. While the SRE reporting structure is isolated, SRE jobs are very integrated with that of development teams. It’s easy to imagine the purist approach, subsuming security and networking into DevOps practices, but only if we assume the presence of cloud infrastructure and services as a platform. Even then, there is still substantiation for the SRE.

    Layers below, however, somebody still needs to build the foundations of the cloud IaaS and data center hardware. As they say, “Even serverless computing is not actually serverless.”

    Underpinning the clouds are data centers. And then there’s transport, IoT, mobile or other secure networks to and between clouds. In these areas, it’s obvious there is a niche for our two trusty sidekicks, DevSecOps and DevNetOps, to shake up ops culture and principles. These two heroes can rescue software-defined and physical infrastructure from the clutches of so many anti-pattern evils, like maintenance windows and change controls (ahem, it’s called a “commit”).

    We may not require rapid experimentation in our infrastructure, but we would warmly welcome automated deployments and updates, failure and attack testing drills, and intent-driven continuous response. They will boost resiliency and optimization for the business and peace of mind for the builders.

    Teams operating security, networks and especially clouds, need to honor and elevate DevSecOps and DevNetOps, so that on the journey now afoot, our teams and our new heroes may realize their potential.

    About the Author / James Kelly

    James Kelly is a lead expert architect on cloud and software-defined networking at Juniper Networks. He also serves as a private yoga instructor, and previously, he founded a capital management firm in Ottawa, Canada. Connect with him on LinkedIn and Twitter.

  • Software Security is an Engineering Problem

    Software Security is an Engineering Problem

    We live in a world where those who sell products are generally held accountable for defects. Automobile manufacturers, pharmaceutical companies and toy makers are among the businesses that have been handed fines and tarnished reputations for distributing items that were later deemed ineffective or dangerous.

    One notable exception to this “consumer first” ethos is the traditional shrink-wrapped software world, where responsibility for product problems is hazy. The vendors that develop and sell software and the customers who purchase and install that software are in a constant battle to shift security liability. The vendors strive as best they can to reduce and remove product vulnerabilities and offer secure configurations while customers deploy, configure and operate the software in very different environments, with very different configurations, which can produce very different security outcomes. Because no customer can (or should) assume receipt of 100 percent vulnerability-free software, they must always take on the primary burden of protecting the environments where that software lives to offset the risks—which typically falls to the customer’s IT and security teams.

    Although there are excellent arguments for both sides, the current situation leaves both parties wanting—and needing—a higher level of assurance in both the development and runtime settings.

    Software Delivery Has Changed (Along with Security Responsibility)

    The good news for software customers is that software delivery is rapidly moving away from an on-premises install approach to a cloud-based subscription model where applications are delivered via the internet. Upfront costs for hardware and software, as well as the expense of personnel to install and manage that software, are replaced with business-friendly, predictable, subscription-based operational costs. Software is easy to launch, upgrades are uncomplicated and scaling to meet changing business needs is simple.

    Customer expectations are high for software-as-a-service (SaaS) solutions. Purchasers demand an elevated level of innovation and want new features more often. They assume built-in support of global information security and privacy regulations such as the European Union’s General Data Protection Regulation (GDPR) and various U.S. regulations, including the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and PCI Digital Security Standard (PCI DSS). SaaS customers also expect the vendor to take on larger responsibility for any potential software vulnerabilities that might negatively impact the customer’s data and operation.

    The new reality is that deploying software in the cloud significantly changes the paradigm of how software security should be treated at the vendor level. This means companies now have to think critically about security as an engineering problem as the balance of the liability burden shifts focus to the cloud provider’s engineering practices to ensure constant delivery of a secure and trusted cloud service, rather than just secure software.

    Now is the Time to Rethink Software Security

    Cloud-based application delivery brings together under a single company umbrella the ones that make the software and the ones who run the software. Informing software development of runtime behavior and vice versa can have significant advantages in enhancing the overall security of the software by offering a closed-loop system. In such a perspective, the rapid pace of software releases work in favor of enhancing security.

    Shifting security to an all-around engineering responsibility requires the elimination of traditional work silos. Geared-for-speed developers must receive precise information early, allowing them to correct security problems during the initial coding process. DevOps team members also must assume security responsibilities. And security engineers who understand the attacker mindset, security risks and compliance requirements must provide guidance at all points in the software development process.

    Change is never easy in any organization, so transforming disconnected teams into one in which security is an across-the-board responsibility is difficult. Managers must be careful to not alienate team members who already have full plates. And although we’re starting to see some shifts in the educational model to one in which professionals are taught early on how to seamlessly integrate coding and security, we have a long way to go.

    While we wait, the most effective way to overcome the chronic problem of heavily siloed teams is to provide the entire software engineering team with a means to quickly identify issues between software development, its deployment and runtime across all the components. These tools must give users the ability to:

    • Scan and provide real-time analysis that integrates source code analysis and its runtime behavior. After all, they are two sides of the same coin;
    • Obtain accurate and full visibility into the security impact of changes from build-to-build;
    • Ease the audit analysis process;
    • Reduce the number of false positives; and
    • Allow developers, DevOps, and Security to collaborate to enhance the security of the environment.

    The goal? An ability to fix software mistakes, weaknesses and vulnerabilities at the beginning of the development process instead of post-deployment, when liability, revenue and reputational risks are the greatest.

    Consolidating today’s siloed security practices into an integrated engineering effort is the only way to ensure the appropriate level of security at the appropriate time in today’s fast-moving cloud-based software industry. This sort of shift in thinking and processes will give customers less security worries and better products. Development teams will become more effective and efficient. DevOps will have real-time visibility into how each release impacts the infrastructure. And Security will know how each release impacts both security and compliance requirements. SaaS companies will reap the financial benefits that come with strengthened industry reputations for rapid innovation capabilities and high levels of software security. It’s a win-win-win for everyone.

    About the Authors

     Manish Gupta is founder and CEO of ShiftLeft Inc. He is a 20-year veteran of the security industry and has led product development, management and strategy at FireEye, Cisco Systems, Intel, McAfee and Redback Networks.

     

     

    Craig Rosen is vice president and CISO at AppDynamics. He has held leadership roles for more than two decades in the security industry, including at FireEye, Pacific Gas & Electric, TDI and CGI.

  • VMware Aims to Advance Application Security

    VMware Aims to Advance Application Security

    Most of the tasks associated with maintaining IT security assume that IT security professionals should discover and neutralize all potential threats to an application. At the VMworld 2017 conference this week, VMware is seeking to turn that notion of IT security on its head by focusing the efforts of IT security professionals on the known good.

    Tom Corn, senior vice president for security products at ware, says instead of chasing all the potential bad things that could adversely impact an application, VMware App Defense employs machine-learning algorithms and data VMware collects from its management console and the host on which the applications are running to determine what elements make up an application workload. Those elements are compared to the manifest that was created when the workload was first deployed and, if they have been altered, VMware App Defense will invoke a preloaded library of incident response routines to enforce policy using VMware network virtualization software. Data collected from the host by VMware App Defense is done by inserting code into the kernel rather than deploying agent software.

    Corn says VMware App Defense uniquely provides DevSecOps teams with access to reliable telemetry into the guest operating system environments running on top of VMware. IBM will feed the telemetry data gathered by VMware App Defense into its portfolio of security analytics software, and eventually that data will be fed into the IBM Watson cognitive computing platform to generate application security recommendations. Other vendors pledging support for VMware App Defense include VMware sister companies RSA and SecureWorks, as well as Carbon Black and Puppet.

    Longer term, Corn says VMware expects to also be able to apply this capability to any production environment attached to a VMware NSX virtual network overlay.

    As potentially compelling as VMware App Defense might be, Corn notes that IT organizations should not attempt to boil the IT security ocean. Rather, they should concentrate on new applications currently under development. Otherwise, managing security policies across hundreds of applications made up on thousands of microservices and communicating over microsegmented network overlays might be too complex to manage.

    VMware has been making a case for some time now to employ NSX to take advantage of microsegmentation to limit the flow of east-west traffic in a data center. The idea is that if one node gets compromised by malware, it can only share that malware with nodes participating on the same microsegment of virtual network. VMware is now expanding on that idea in a way that also provides more visibility all the way up the application stack.

    Priced at $500 per CPU per year, VMware App Defense will induce more IT security professionals to recommend deploying its stack over any other available option, VMware hopes. The degree to which IT operations teams and cybersecurity professionals can influence developers in that direction remains to be seen. But VMware App Defense does fulfill its promise, it’s more than likely developers will appreciate the not having to spend as much time defending existing applications instead of writing new ones.

    — Mike Vizard

  • CloudCoreo: Get Your Cloud Security on at Jenkins World

    CloudCoreo: Get Your Cloud Security on at Jenkins World

    I mentioned in a previous blog post that I’d take some more of the people pinging me about Jenkins World 2017 and post about them. One of the companies I’ve picked to highlight is CloudCoreo, makers of AWS security controls and auditing.

    Disclosure: My company, Ingrained Technology, has a business relationship with CloudCoreo outside of our relationship with devopsy.kinsta.cloud. That’s how I know about their attendance. But they’re a cool company for cloud security automation, so I chose to include them in my Jenkins World previews.

    CloudCoreo is based on the premise: What if you could automate and audit security settings in AWS without learning security for each of their services? I’ve used their tools, and I’ll be honest, my personal AWS account had a bunch of security violations. Since I use AWS off and on in spurts, this makes perfect sense, and I was able to clean house a bit based upon the tools’ feedback.

    CloudCoreo’s presence at Jenkins’ World will be to talk about itsr system, but will also concern its new Jenkins’ plugin. While there are tools that allow you to partially automate security generation in AWS, the cool part of the plugin is that it allows your automated system to audit the actual results of a deployment to check against standard security patterns. And those checks include things that are normally outside the build/deploy process, such as user rights and password change frequency.

    One of the directions that cloud is going is putting security configuration directly into templates. But not every template will be designed with the same level of configuration/security. By auditing the results as part of a deploy, weaknesses in templates obtained from external sources easily can be detected early in the development process. This is fully in line with the “shift left” approach currently being used in DevOps, and gives security an edge in automating one more thing. If it is just part of the deployment to kick off this Jenkins plug-in as one of the final steps of deployment, then security can shift from “pawing through tons of config code” to “reviewing results.”

    Right now, security is one of a few items (NetOps being the other) that is on the critical path for DevOps to be both responsive and controlled. Companies such as CloudCoreo are helping make certain that not only does it go out quickly, but it goes out secure.

    I haven’t tried its Jenkins plug-in yet, and don’t currently have any complex AWS projects going on, but the thought intrigues me. Someone should go stop by (the company will be giving a demo of stopping a release for violations at table T1) and see it in action, then report back what you learn. Having used CloudCoreo’s web interface, I expect the results of the Jenkins plugin will be both thorough and definitive, but verification of those suspicions would be nice.

    — Don Macvittie

  • SecOps: The Next Stride for DevOps

    SecOps: The Next Stride for DevOps

    Global IT spending is now touching a figure of $4 trillion. In today’s technology-intensive environment, data is the biggest commodity, more valuable and powerful than ever. And like Peter Parker’s uncle Ben noted, “With great power comes great responsibility.”

    Security has always been a big concern for valuable things and IT is no exception. IT as a whole is trying to push security left in the development cycle—trying to involve it in every step of the development cycle. And just when development and operations teams are getting used to the “esprit de corps” we call DevOps, I think it’s time we add the third musketeer: security.

    What is SecOps?

    SecOps is a collaboration between security and operations teams, just like development and operations teams collaborate on DevOps front. SecOps is a set of practices organizations need to follow, processes they need to execute and tools they need to use to ensure the security of their application environment. SecOps is making sure organizations do not sacrifice security to attain set performance and uptime indexes.

    In a typical development cycle—requirements gathering, design, development, testing, implementation or deployment and maintenance—security normally is introduced in the later stages, somewhere between testing and deployment or even later. But SecOps is all about making sure to introduce aspects around security much earlier or at each stage of the software development life cycle (SDLC).

    I know what you are thinking: This is going to complicate things and increase the time to delivery. This is where operations and development teams need to join forces to uncomplicate the things and make it time efficient practice. Next thing you must be thinking of is, Why so much hassle? Think of it the other way. Wouldn’t it save more time when you address the security concerns at much earlier stages than at the time of delivery or implementation? All it takes is an amalgamation of the security group, development team and operations team; a little bit of planning; and a whole lot of execution.

    SecOps + Containers

    Containerization is slowly but steadily moving from an alternative to full virtualization to a serious platform for running your applications. Containers have some obvious advantages including scalability and flexibility, and this solves most of the problems related to resources in case of application development. Reduced size; reduced time to provision application environment and testing; platforms including Docker, Solaris Zones, BSD Jails; and orchestration platforms including Kubernetes, CoreOS Fleet, Amazon ECS and OpenShift make containers a more preferred option for application development environments.

    This increased traction toward containerization points to the increased need to concentrate on security aspects. Here are some best SecOps practices for container environment you and your organizational teams can follow:

    • Authentic sources and images: Always check for authenticity of container images. There are various tools such as Docker’s security scan. With Docker Cloud and Docker Hub you can scan images to check for potential security vulnerabilities. Most images are built from some base image and not built from scratch, so there is always a threat with the used images.
    • Vulnerability management tool: There are tools available in the market to analyze container image formats and libraries for threats before you actually start using them.
    • Follow benchmarks and hardening guidelines: Always make sure you do the checks and follow hardening guidelines for containers, images, hosts and platforms before you start with production. There are few standards and benchmark checks for containers such as CIS’s Docker security benchmark, PCI compliance checklist, etc.
    • Periodic auditing: Regular auditing of your application environment can help you save yourself from the future troubles. Moreover, automation of auditing process can help in detection of unused images and containers.
    • Use of management frameworks: Use frameworks that can automate behavior profiling and control all the users, authorize the access to the containers, images and hosts.
    • Security built in to container engine systems and third-party security solutions: Third-party vendors have a number of applications for container security in addition to security systems of container management platforms.

    Dev + Sec + Ops

    With the continuously increasing business demands for new applications and software, and new practices and development trends such as DevOps, Agile, cloud, automation, CI/CD and others, traditional security needs to upgraded in the new paradigm. Thankfully, some of these practices facilitate the security. Consider CI/CD as an example: Continuous integration requires continuous integration tools, or what we call build servers. Some popular examples are Jenkins, TeamCity, GitLab CI, Travis CI, Bamboo, Go CD, CircleCI and Codeship. The best SecOps practice is to check and fix vulnerabilities at early stages as a part of CI/CD workflow. Integration between authentication, scanning, management tools and CI/CD pipeline tools could be the best possible solution to your security-related problems. Some easy-to-implement solutions can include automated security testing, static code analysis, authentication checks and login tracking.

    SecOps enable organizations in lifecycle management, analysis of security threats, incident management, optimizing and measuring the effectiveness of security controls, reduced breach response time, reduced security risks and increased business security. The basic principle on which SecOps works is Avoid, Analyze, Respond, Review, Repeat. By analyzing the security events and data, you can build incident response plans to avoid future unwanted events.

    Frameworks and Tools

    Now that you have a clear understanding of why you need your security, development and operations teams to work together, let’s see what tools and frameworks you can use.

    • Docker-native tools: If you are using Docker as a platform then you can use few security tools provided by Docker itself for the security of production environment: Docker Bench and Docker Notary. Docker Bench is a script that checks common best practices around deploying Docker containers in production. Docker Notary enables you to check whether content is from a trusted publisher.
    • Chef: Chef provides different tools including Inspec to automate security testing.
    • Puppet: Puppet provides security compliance and policy defining frameworks.
    • Ansible: Ansible provides system tracking, setting up firewall rules, user lockdown and compliance automation solutions.
    • CoreOS Clair: CoreOS Clair is an open-source project for vulnerability analysis in applications and Docker containers.
    • SaltStack: SaltStack can help in orchestration and automation of security practices solutions for containers.

    This is just a look at some of the most popular ones. If you want, there are a number of others that can look after the security of your application environment.

    The main motive behind implying SecOps practices in any organization is involving security team at all possible stages to remove any ambiguity in any stage of development rather than security team providing analysis reports to the operations team and then sitting back and enjoying the show. When these teams perform in a synergistic manner, the business focus can be shifted to other important things.

    About the Author / Chaitanya Jawale

    Chaitanya Jawale is founder and CEO of Opcito Technologies, a leader in microservice-based product engineering and automation. Chaitanya comes with strong background in product engineering, data center automation, DevOps and multi-cloud orchestration and management.

  • Jenkins World: Q&A with CloudBees CEO Sacha Labourey

    Jenkins World: Q&A with CloudBees CEO Sacha Labourey

     The Jenkins Community and DevOps professionals around the world are excited for Jenkins World, coming up in just a month, Aug. 28-31 in San Francisco. CloudBees, the hub of enterprise Jenkins and DevOps, is the lead organizer and premier sponsor of the event. We sat down with CloudBees CEO Sacha Labourey to discuss everything Jenkins World.

    NOTE: If you haven’t registered yet, there is still time! devopsy.kinsta.cloud readers can register now with the code JWDEVOPSCUST and get 20 percent off.

    Q: How has Jenkins World evolved since its inception?

    A: It’s been quite the journey since the beginning of Jenkins World. The very first Jenkins World was back in 2011. We had 200 people attending and we were extremely proud of that. The Jenkins project was still new, as it had just changed its name in 2011, so we were excited to see the community already coming together. Fast forward to 2017 and we’re expecting about 2,000 attendees at this year’s event. We’ve grown 10x since the first show and even from last year to this year we’re expecting almost 50 percent more attendees. It’s been great watching the conference mature and grow over the years. 2017 will be our best show yet!

    Q: What’s new at Jenkins World this year?

    A: This year we’re expanding everything, covering a wide range of topics including DevOps culture, process design, automated testing, performance measurement, security, leadership and more. We’ve added a welcome reception and evening event in the expo hall so attendees have more opportunities to network and learn from each other.

    Additionally, we’ll be kicking off the first-ever annual Jenkins World Awards. These awards recognize the achievements of CD innovators and Jenkins contributors from around the world. There are two award tracks: Jenkins Community Awards and CloudBees Innovation Awards. Winners in each track will be featured at Jenkins World.

    Q: What can attendees expect from the keynotes?

    A: We have a great lineup of keynotes this year, including myself! My keynote will be a state of the union that looks at what’s happened in the last year, what worked, what didn’t work and what we’ve learned from it. Stemming from that I’ll also offer a vision for the future. This will be actionable, and practical—something we can truly act on. I’m excited to say that there will be some significant announcements throughout the week as well.

    Kohsuke Kawaguchi will also be keynoting. His keynote is always excellent. He’ll offer a state of the union from the Jenkins community angle. He’ll go over the evolution of the Jenkins project and run through the latest numbers. It’s such a pleasure to watch him on stage each year; his talks are always exciting.

    We’re also thrilled that Jez Humble will be keynoting this year. He literally wrote the book on DevOps, so if you’re looking to learn about DevOps, he’s the man you want to hear. He’ll be discussing the DevOps market, challenges, opportunities, the evolving requirements and needs of DevOps professionals and more.

    Q: What advice do you have for first-time attendees?

    A: My advice is: Take advantage of the trainings, workshops and certification opportunities. Last year, workshops and training were a huge success, so we’re offering even more this year. It’s a great way to further your career. It’s very hands-on and provides an opportunity to show tangible results of how the conference helps you improve your skills and ultimately helps your career.

    Also, make sure to network with fellow professionals. It’s the perfect time to find out how others are approaching their projects, what challenges they faced and how they’ve overcome them. It’s such a great community of professionals to learn from.

    Q: Are there any sessions you recommend?

    A: I’d certainly recommend checking out some of the specialized vertical sessions. For example, we’ll have a number of sessions that focus on the financial services industry with speakers from Capital One, PayPal and more.

    We’ll also have some great DevSecOps presentations. It’s a very hot topic and is increasingly important in DevOps. I’d highly recommend attendees get to at least one of these sessions.

    Finally, there will be several sessions focused on testing—which often adds the most friction to delivery pipelines. These sessions will prove really helpful for attendees looking to enhance their testing processes.

    There you have it! This year’s show is bound to be bigger and better than ever before. Register now with your 20 percent off code: JWDEVOPSCUST.

    — Alan Shimel

  • Survey: Inviting Security into DevOps Promotes Effective Agility

    Survey: Inviting Security into DevOps Promotes Effective Agility

    Two of the biggest trends in business technology are seemingly at loggerheads with one another. Many companies are under severe pressure to digitally enable their businesses. At the same time, the need for hardened application security has never been more critical than it is now. You can deliver apps quickly and you can deliver apps securely but, generally speaking, the two things don’t happen at the same pace. The DevOps mission is aligned more with development efficiency and agility, but it’s also in keeping with the thinking behind DevSecOps. How are enterprises handling the conundrum?

    According to a new survey from identity and encryption enterprise vendor DigiCert, they are handling it quite well. The recently released “Inviting Security into DevOps” survey found that 98 percent of respondents said their companies are integrating their security teams into their existing DevOps methodologies. The survey found that 49 percent of the respondents are in the process of doing so; the other 49 percent have already done so. Those who report having already integrated security with DevOps are 21 percent more likely to report what might seem counterintuitive: They are doing well at meeting app delivery deadlines.

    “Successful security for DevOps requires a combination of culture building and the right technology,” said DigiCert CSO Jason Sabin. “Companies that can do this and bring in security at the start of a project avoid costly delays, because they deliver their project just once rather than discovering security issues late in the process.”

    The methodology for the survey, which was conducted in May, involved 100 DevOps professionals, 100 IT professionals and 100 security professionals with executive management to management titles skewing 3:1.

    The large enterprises polled for this survey agree it’s worth striving for. Some 88 percent of the respondents called security working directly with DevOps somewhat or extremely important. More than 70 percent of the respondents are concerned that if their companies don’t make this change, one or more of these negative repercussions are likely: increased costs, slower app delivery and increased risks.

    Although nearly all the respondents have integrated or are integrating security within DevOps, they’re not saying it is an easy process. Their top challenges include a lack of a champion for the transition, the security team resists the change, lack of relationship skills required to bring the teams together and it takes much more time than expected—an average of one to two years.

    How should you approach this in your company? First, recognize that it’s no panacea. It’s a logical first step, but don’t spend a year planning it, just do it. Start by appointing or identifying a leader for the project. Someone who understands both sides, ideally, and who knows how to get things done. And install a security lead at the DevOps table for all DevOps business. Integrate, standardize and invest in automating baseline security practices within DevOps workflow. Thinking that way will get you the agility you need.

    Then address what comes next. Have the team identify choke points in the application security process and develop ways to work around them or eliminate them. In other words, attack the problem head on with all your best minds. Don’t forget to look for best practices developed by others. It’s a problem a lot of companies are trying to solve, so networking with people from other companies at industry events may give you your best ideas.

    — Scot Finnie