Tag: security

  • Automation: Critical Missing Pieces in the CD Puzzle

    Automation: Critical Missing Pieces in the CD Puzzle

    As enterprises accelerate the frequency with which they develop and release new code into production to meet the ever-mounting demands of their consumers, there’s growing pressure on networking and security operations teams to keep pace with their DevOps counterparts. And it’s not hard to see why. According to Forrester, nearly four out of five business leaders believe it is IT’s responsibility to ensure the network can support the company’s digital transformation plans.

    And yet, 67 percent of businesses believe the network is the bottleneck—and with good reason. The current networks that NetOps and SecOps teams manage are highly complex, distributed entities that have historically been configured and provisioned manually—and often, in silos. Yet, as DevOps accelerates ahead at lightning pace, underpinned by the continuous integration, delivery and deployment (CI-CD) approach, NetOps and SecOps teams are scrambling for new ways to gain speed to more quickly launch, scale and secure applications and code updates in production.

    The Need for Speed 

    Enterprises are increasingly leveraging DevOps principles to execute daily deployments into their multicloud test and production environments. For example, Etsy deploys 80 times per day, while Netflix and Amazon deploy up to thousands of times a day. In this new world order, collaboration, communication and synchronization across development, operations, network and security teams is essential.

    This also means that testing of the network and application services infrastructure must happen concurrently with the application development and testing processes—not afterward, which can dramatically slow down the agile CI-CD process. Similarly, security cannot be retrofitted after the development and test phases are complete. A recent study by Puppet Labs found that high-performing teams spend 50 percent less time remediating security issues when security is addressed at every stage of the software development and delivery cycle.

    New CI-CD Tools Deliver on the Promise of DevOps  

    New innovations in virtualization and programmability of network and application service infrastructure are making it possible to test policies and configurations prior to production—even in highly complex environments. Powered by validated templates and APIs, these network orchestration and application services tools help automate task execution for scale, preserve provisioning and configuration policies for consistency and bolster security, while dramatically reducing management time cycles and the risk of human error. They empower NetOps and SecOps teams to leverage DevOps principles and apply them to network and security during the development, deployment and delivery of multi-cloud apps and code updates.

    Similarly to how software-defined components such as servers and storage are provisioned, network orchestration tools leverage a software-defined infrastructure (SDI) approach to rapidly provision network services across multiple network devices. These tools support flexible application provisioning across physical and virtual environments, help identify and address issues quickly and improve overall network performance. In the CI-CD model, network orchestration helps NetOps and SecOps teams ensure that all production-critical application and network elements—such as availability, core network services, security services and performance—are accounted for and are rolled out in proper sequence and at scale.

    Application services automation focuses on application availability, performance, and security. While automation used to focus solely on simple load balancing, it now also includes a range of solutions that help network teams configure and automate application services during the test phase. These include web app and network firewalling, DDOS protection, application acceleration, WAN optimization, DNS services and TCP optimization, among others. In the dev and test phases of the CI-CD process, automation allows for faster configuration and deployment of network settings and policies. Similarly, in the production phase, automation significantly speeds up and simplifies areas such as policy adjustment and other time-intensive processes by eliminating the need to reconfigure underlying infrastructure. This means that ticket resolution and necessary changes can be completed in a matter of minutes versus weeks. At the time of rollout, application services automation toolsets also help to ensure the infrastructure is ready to perform at peak levels.

    Network and application services automation innovations—the critical missing pieces in the continuous deployment puzzle—work together to ensure the entire DevOps team—including network and security—can deliver and deploy applications with the speed, reliability and security necessary to meet today’s business challenges.

    About the Co-Author / Ranga Rao

    Ranga Rao is Director of Product Management & Solutions Engineering at Cisco Systems, where he leads a team of product managers, architects/TMEs and software engineers to collaborate with partners to define use cases and build software integrations for leading Cisco solutions including Cisco ACI, Nexus 9000 and Tetration Analytics. Ranga earned an M.S. in Computer Science at Stanford after receiving his B.E. from the National Institute of Technology Karnataka. Ranga is also an author of a popular book, Programmability and Automation with Cisco Open NX-OS, published by Cisco.

    — Lori MacVittie

  • All Day DevOps: Modern Infrastructure Automation

    All Day DevOps: Modern Infrastructure Automation

    “We’re no longer an airline. We’re a software company with wings,” claims Veresh Sita, CIO, Alaska Airlines. The success of today’s businesses rests on software. It is an integral part of infrastructure, so we need to always ask, “How can it be better? More reliable? More secure?”

    Nathen Harvey (@nathenharvey) is the VP of Community Development at Chef and the co-host of the Food Fight podcast. He is also an evangelist of automating software operations, which is what he presented on at the 2016 All Day DevOps conference.

    Nathen started his talk by stating that “automation at scale is required for high velocity IT,” making the point that in today’s environment, you can’t wait months between deployments. Enterprises are moving to continuous integration/continuous deployment, and he advocates for continuous automation.

    harvey pic1.png

    To implement automation at scale, you have to start with a dynamic infrastructure by:

    • Provisioning and setting up environments
    • Implementing dynamic scaling of compute resources
    • Migrating legacy workloads to the cloud
    • Deploy in multi-cloud and hybrid-cloud environments
    • Support heterogeneous environments

    harvey2.png

    Several speakers of All Day DevOps talked about automation, and all of them said a critical step is to treat infrastructure as code. According to Nathen, this means that to programmatically provision and configure components, such as servers, databases, firewalls, etc., you also have to treat it like any other code base. This includes version control and automated testing, but also:

    • Automated, full-stack application policies
    • Package and service installation
    • Versionable, testable and repeatable workflow
    • Scalable application policies
    • Management of interdependencies across nodes

    When you treat your infrastructure as code and deliver at scale, you can scale elegantly from one to tens of thousands of managed nodes across multiple complex environments.

    For software to be effective, users have to trust that it will do what they expect it to do. This is true from handheld calculators to self-driving cars, and it is also true when we automate our development and operations. Nathen advocates that we have to build a pipeline to production that creates faith in us that our code is ready for production.  This pipeline must:

    1. Test the code/verify locally
    2. Verify in pipeline with automated testing
    3. Approve with another engineer (aka code review or Nathen’s “four eye rule”)
    4. Build an artifact
    5. Deploy into acceptance environment to automatically test the artifact
    6. Ask someone else, “Do we want to ship this?”
    7. Ship the code with a click of a button
    8. Union (bring together dependencies and run tests)
    9. Rehearsal
    10. Delivered (ship to customers)

    What does the future hold?

    Infrastructure automation is NOT enough. Why? Auditors show up to audit your infrastructure and applications. The problem is, they use different tools—Excel spreadsheets, notebooks, PDFs, etc. This makes it very difficult to audit. Nathen advocates managing compliance documents as code, too. When we translate compliance into code, it can be executed as part of the pipeline so we can test for compliance throughout the entire life cycle.

    Finally, Nathen stresses the need to have application automation, too. Modern applications look like infrastructure as code.

    harvey3.png

    Developers can make applications that operations can deliver and run in production. This makes it easier to consume, run, and keep applications healty. Operable applications need to be:

    • Isolated
    • Immutable
    • Configurable
    • Built on a common interface for monitoring health
    • Rebuildable from sources
    • Reside in common packaging
    • Maintain runtime independence

    As enterprises implement infrastructure, application, and compliance automation, it creates a freedom for people to focus, and people are the key.

    Nathen notes that, “DevOps is a cultural revolution and professional movement, focused on how we build and operate high velocity organizations, born from the experiences of its practitioners.” He underscores that people are the future of automation. Automation places the priority on people, which enables great companies and great products.

    harvey4.png

    You can watch Nathen’s entire talk online here, where you can dig deeper into this subject. If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free of charge here.  Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here.  This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free and online on Oct. 24.

    — Derek E. Weeks

  • 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

  • Fighting Deployment Anxiety: 5 Tips from the Pros

    Fighting Deployment Anxiety: 5 Tips from the Pros

    You know the feeling: You’ve put in hours of work developing a new feature. It has gone through QA, been tested and passed all stakeholder inspections, and now you’re ready to deploy. Despite your experience and preparation, you have a pit in your stomach. What if something goes wrong and it brings your app to its knees? What if it doesn’t function in your production environment the way it’s supposed to? We’ve all been there. Fortunately, we also have some ways to help.

    Electric Cloud CTO Anders Wallgren recently participated on a webinar with Gene Kim, CTO, researcher and co-author of “The Phoenix Project” and “The DevOps Handbook.” Hosted by devopsy.kinsta.cloud Editor in Chief Alan Shimel, the webinar addresses lessons learn from large-scale DevOps transformations, the business value of DevOps and some of the best tips and tricks for fighting deployment anxiety. We pulled out the top five tips and tricks from Kim and Wallgren for making deployment worries a thing of the past.

    Tip 1: Automate Your Deployment

    A theme throughout the webinar from both Kim and Wallgren was “automation.” One of the big reasons for this is that typically, when you automate your deployments, you’re also automating the diagnosis of problems in those deployments. You can’t always just rely on the exit code of a command-line tool to tell you whether something went right or went wrong. To help keep your deployments healthy, you’ll want to do testing along the way, possibly as a blue-green deployment or a partial deployment. However, if you don’t have automation behind that, it can be difficult to get that accomplished at speed. Without automation, you may start to rely on heroic efforts by individuals—so that every time you are doing a deployment, someone is having to do a figurative tightrope-walk to get everything accomplished. This creates a tough environment for your employees, and can lead to extensive downtime (and lost profits).

    Tip 2: Enable Self-Service Deployments to Any Infrastructure

    You’re probably wondering why this is a separate topic from automated deployments. That’s because the majority of deployments that occur in a given release pipeline aren’t going into production. Most deployments end up in testing environments (for performance testing, regression testing or just developer testing). It’s also important that you give your engineers the ability to use the same deployment methodology (artifacts, process definition, environment definition, etc.) regardless of the location to where they are deploying. From a cost perspective, allowing QA to test on a local Kubernetes cluster might be more cost-effective for your enterprise than running tests on Amazon Container Service. But, allowing teams to use the same approved automation as part of every deployment—to any location—means a more thoroughly rehearsed and therefore less anxiety-inducing deployment.

    The ability to do self-service deployments also gives your teams the ability to move substantially faster when they need to deploy something for testing by avoiding the need to open a ticket and get your Ops teams involved. By allowing self-service deployments, you can avoid the process of running around to find the right person to accomplish the deployment you need to run, and empower your organization to react and build more autonomously across different groups. The result is better-tested and built deployments (resulting in lower deployment stress and fewer errors).

    Tip 3: Self-Service Environments

    We’re continuing to roll with the theme of automation, but this time we’re talking about self-service environments. More often than not, we’re working with complex distributed apps. This means things such as a containerized microservice application, DBMSs, messaging, key value stores, legacy applications and third-party vendors that we need to integrate with—all things that make our deployments complicated. Being able to consistently provision complex environments is a very important part of being able to successfully recreate a deployment as you promote the application through its life cycle.

    It’s important to make sure that your engineers, and in particular, your QA and development engineers, have easy access to environments and that they’re not standing around waiting for access. When you don’t have the ability to get VMs or containers provisioned and configured correctly to receive your application, you run into problems. One of these problems is that your ability to test rapidly just became much more difficult. When you can’t get a near-production quality environment stood up in a few minutes, it means that your bug fix that requires just a few lines of code could potentially take weeks to test. Suddenly you need to requisition a set of VMs to test on (which could take weeks) and another day or two to do the deployment, and only then can you complete your tests. Things become painfully slow. And, when it comes to testing and fixing bugs, slow equals stress.

    Tip 4: Artifact Repositories

    Want to feel more confident about your releases? Look at your artifact repositories. Use of a shared artifact repository in production environments has been shown to be a good are a really good predictor of deployment success. If you’re not versioning your binaries, and have little insight into where binaries are coming from and how they were built, it can lead to failed deployments.

    It may not be easy or simple to get your artifact repositories in line, but it’s a labor that will pay massive dividends in the long term. Electric Cloud worked with a massive online mortgage company that had the challenge of deploying large artifacts (gigabytes) into multiple data centers. To get everything up to speed, it was necessary to transfer those artifacts out of their build and test infrastructure and into their pre-production and production infrastructure. Because of the size of the artifacts and concerns about worldwide availability for the files, Electric Cloud worked with this financial services company to use Amazon S3 as the backing store for the repository server to create a long-term solution that is flexible and scalable.

    Tip 5: Security and Auditability

    If you work in a regulated industry, already know the heartburn auditability and governance can cause. Security is one of—if not the single—most important aspect of many application delivery pipelines. The reality is, we are just beginning to scratch the surface of the problems we will see the in the future when it comes to infrastructures getting hacked. So what’s our tip? Again, it comes back to automation. At ElectricCloud, there is a saying: Automation is auditing, automation is documentation.

    The idea behind this is that by automating your deployment tasks, you are essentially creating a very real and tangible paper trail that shows what you intend to do (the automation definition) and a report of exactly what happened (the automation logs). When you rely on manual deployments, you suddenly take an aspect of repeatability and predictability out of your workflow. At that point, you are forced to report based on people’s spreadsheets, emails and memories. This is one of those things that doesn’t become a big deal until it’s a really big deal, and—to borrow another saying—an ounce of prevention is worth a pound of cure. In the case of auditability and security, being able to retrace your steps because your steps are always the same is a fairly foolproof method to making your audits much more smooth.

    To provide a real-world example for how automation can make auditing and security much less painful, one of ElectricCloud’s clients is an aerospace customer with very stringent and demanding security standards. In the past, at the end of each release, it would have a two-week process where everybody had to sit down and compile a list of every single check-in deployed as part of that release. They had to understand where it got built and exactly how it was tested, and then assemble all of that information in a report. It was an extremely time-consuming, but seemingly necessary process. However, by automating many of the steps in the pipeline, the audit response effort went from a two-week process to just a few hours. They accomplished this because 99 percent of the information they needed was in the automation system and was simply scraped as part of process. The task went from manually pulling that data to just getting into it consumable formats.

    Summary

    By now you’ve certainly seen a theme emerge in our recommendations for reducing the stress of deployments—namely, automate! By putting effort into automation and streamlining your pipeline, you can take what was once a very labor-intensive and sometimes stomach-churning process and make it much more enjoyable. Not only will this save you time and money in the long run, but it will also allow you to focus on building better software, doing more deployments and focusing on the tasks that bring your business and your customers real value.

    For more details on how you can relieve your deployment anxiety, and to hear the rest of the discussion focusing on the lessons learned from large-scale enterprise DevOps transformations and the business value of DevOps, watch the full replay.

    About the Author / Sam Fell

    sam-fellSam Fell is the Head of Marketing at Electric Cloud, responsible for driving awareness and demand for our DevOps Release Automation and Acceleration solutions. For 20 years, Sam has helped companies achieve success by marketing, selling, and implementing DevOps Release Automation, IT Change Management and Application Performance Management solutions. Prior to joining Electric Cloud, Sam held leadership roles at BMC, CA, Marimba and Nimsoft. Follow him on Twitter and connect with him on LinkedIn.

     

  • Study: Half of Enterprises Have Achieved DevSecOps

    Study: Half of Enterprises Have Achieved DevSecOps

    The inclusion of IT security into DevOps processes, also known as DevSecOps, appears to be occurring at an accelerated rate. A new survey of 300 enterprise IT organizations published this week by DigCert, a provider of identity management and encryption software, finds that almost half (49 percent) of the respondents says they have completed DevSecOps, while another 49 percent say they are already working on it.

    In terms of overall impact, however, only 22 percent say they are doing well in terms of achieving and maintaining higher levels of security.

    In addition, those that have achieved DevSecOps say it took them anywhere from 12 to 14 months to make the transition. Those that have not completed the transition are estimating it will take them seven to 11 months. Based on the experience of the organizations that have completed the transition, there would appear to be a natural tendency to underestimate how much the cultural difference between developers and IT security teams can negatively impact integration objectives.

    Jason Sabin, chief security officer (CSO) for DigiCert, says that while many organizations may have brought IT security professionals into the process, an increase in the overall security of applications being built requires more time and patience, says Sabin.

    DigiCert recommends IT organizations identify an IT security champion within a DevOps process and automate the implementation of IT security controls as much as possible. Those moves can help lower developer cultural resistance to having to spend time on what often are considered mundane programming issues.

    It’s worth noting that most IT security professionals don’t have much in the way of programming skills. They can secure an application using any number of platforms that have a management console. But understanding how to employ APIs to help plug security holes before an application gets deployed is beyond the capabilities of most IT security professionals. IT security professionals can make developers aware of issues, but in general there’s not much they can do to fix the application itself.

    Also, IT security professionals typically don’t understand the amount of coding that might be required to fix an issue, and they are not always able to access the true risk associated with a specific vulnerability. All vulnerabilities tend to be treated as equal threats regardless of number of instances a vulnerability has been exploited.

    The good news is a full 88 percent of respondents saying it is somewhat to extremely important to integrate security into DevOps. Failure to do so will lead to issues such as increased costs (78 percent), slower application delivery (73 percent) and increased security risks (71 percent). Awareness of these issues should eventually lead to the development and deployment of more secure applications.

    The issue, of course, is that not every development team is equally along the DevSecOps maturity code. Because of that issue, it unfortunately may be years before the preponderance of applications running in a production environment are able to defend themselves from even the most rudimentary cybersecurity attacks.

    — Mike Vizard

  • Barracuda Networks Enhances API to Advance DevSecOps

    Barracuda Networks Enhances API to Advance DevSecOps

    Recognizing that DevOps teams deploying applications in the cloud need a more sophisticated approach to security, Barracuda Networks at the Microsoft Inspire 2017 conference unveiled an enhanced REST API for its Web Application Firewall (WAF), in addition to providing integration with the IT automation framework developed by Puppet Labs.

    At the same time, Barracuda Networks revealed that it has integrated all of it firewall offerings with the Microsoft Operations Management Services running on the Microsoft Azure Cloud. Finally, Barracuda Networks announced it is now including a software-defined wide area network (SD-WAN) capability with the Barracuda NextGen Firewall platform.

    Tim Jefferson, vice president of cloud for Barracuda Networks, says the REST API the company is exposing in its WAF enables IT organizations to better manage security within the context of larger DevOps environment. As part of that effort, Jefferson says, Barracuda Networks also plans to integrate its WAF offering with other IT automation frameworks.

    Jefferson says many IT organizations are discovering that public clouds are more secure than on-premises environments because of the level of security and instrumentation that cloud service providers now routinely include. For example, cloud service providers make it easier to track unusual API calls that might indicate an IT security breach or even an attack in progress. Those capabilities, says Jefferson, make it easier for vendors such as Barracuda Networks to provide more visibility into what’s occurring in a public cloud than what’s generally feasible on-premises.

    However, each cloud service provider has its own unique network stack that requires security tools to be optimized for each platform, says Jefferson. Because of that issue, most IT organizations have not had the security wherewithal needed to rise beyond adopting more than one public cloud service in their production environments, he says.

    In general, Jefferson says, developers are not likely to consume security technologies on a public cloud that can’t be invoked via an API. Because of that issue, many IT organizations are discovering that the security platforms they have employed on-premises simply can’t be lifted into the cloud. That issue, he says, creates a level of friction inside the organization that inevitably hampers usage of cloud platforms more than any other challenge an IT organization faces. Cloud applications require a DevSecOps approach that developers will view as a natural extension of existing DevOps processes, says Jefferson.

    To achieve that goal, organizations need to make it easier for developers to secure their applications and invite IT security experts inside their organization to participate in, for example, scrum teams that collaboration build, deploy and manage applications. In fact, Jefferson notes most DevOps teams don’t even want to talk to a vendor’s sales representative; they prefer to be able to download code that they can test and deploy on their own before committing to buying a license.

    It’s still relatively early in terms of appreciating the impact DevSecOps will have on improving IT security. But one thing is clear: IT security vendors that don’t make it simple for developers to invoke the capabilities they provide soon will be left behind.

    — Mike Vizard

  • DevOps Chat: Developers and Security with Pete Chestna, Veracode

    DevOps Chat: Developers and Security with Pete Chestna, Veracode

    In this DevOps Chat we speak with Pete Chestna of Veracode about the roles and opinions of both developers and security pros about how and who should be working on security in the enterprise. Much of the discussion centers on a survey Veracode conducted with consulting firm Enterprise Strategy Group (ESG).

    Pete is always a great interview with a common-sense approach to DevSecOps borne from being both a developer and security pro. I am sure you will enjoy this discussion. As usual, the streaming audio of our discussion is immediately below and the transcript of our discussion is below that.

    Audio

     

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel of devopsy.kinsta.cloud here for another DevOps Chat. Today’s guest on the chat is Pete Chestna, Veracode, a CA company, director of developer engagement. And that’s a fancy way of saying Pete’s out there talking to developers about bringing security, shifting it left, bringing it into the developer universe and making all of our apps more secure. Pete, welcome to DevOps Chat.

    Pete Chestna: Thanks, Alan. Pleasure to be here.

    Shimel: Yep. So, Pete, you and I have, of course, crossed paths before and I’ve seen you present and you’re a knowledgeable, knowledgeable person, in terms of how security is continually kind of making inroads into the developer community and kinda convincing them that security’s everyone’s responsibility, right? That security isn’t just the purview of the security team; it’s everyone’s job. And you’re doing a heck of a job with it, which has, I think, attested to Veracode’s value in the market and its place in the market, so great job there.

    Chestna: Thanks.

    Shimel: Pete, what we’re gonna talk a little bit about today is that Veracode recently conducted a survey of developers and security folks, talking about this very subject. And I wanted to share it with our audience a little bit, if you can. Why don’t we start with what you consider sort of the headline of this survey?

    Chestna: Thanks. So this was done with the enterprise strategy group and the key takeaway for this is, really, again, it’s reinforcing the messages we already bring out to the market, so we need increased accountability. The reason that developers don’t take security more seriously is because they’re held to account for their functionality and not necessarily their security, so, if we bring in metrics and goals into the equation, for developers, we’re gonna see an increased uptick in the way they think about security. It’s about building relationships with your security team, so security and developers need to work together to build that relationship, so, that way, they feel like there are people on each side and not just a function.

    And, really, it’s what I call the “three-legged barstool of application security.” It’s about training, making sure developers are trained—a lot of the times that they don’t wanna develop these tools is because they don’t know what to do with the results. Second is integrate and automate—if you bring it into their toolchain and make it easy for them to use, then they’re more likely to use it. And, lastly, it’s about helping them fix what they find—again, this knowledge gap of, “What is across-site scripting? What is OS command injection?” Help them understand how to fix these and prevent them makes them more likely to adopt these tools and make security a better part of their work.

    Shimel: Got it. And you know what, Pete? So I’m up here in Boston, recording this, and we just finished a DevOps Connect. I had an interesting question from the audience yesterday, and a gentleman said, “Well, our developers kinda get paid or judged on how much code they commit. And to go back and tell them that the code they committed, you know, it had vulnerabilities and they gotta fix it, it really upsets them.” I’m sorry for them, right, Pete? But –

    Chestna: Right.

    Shimel: – to me, it’s kind of—you know, I used to see this problem with running sales teams and stuff like that. You’ve mismatched incentives here. Right?

    Chestna: Oh, absolutely.

    Shimel: You know, and that has to be—and that’s not the developer’s or the security guy’s fault; that’s management’s fault.

    Chestna: Yeah, if we don’t take accountability for what we’re doing, if we don’t hold the developers—so, you know, I always look at the security team. They are responsible for security but the developers need to feel accountable for security. And you’re right; it’s management that needs to say, “We’re gonna measure you on this and it’s gonna be part of how we evaluate you at the end of the year.” That will drive the right behaviors. They’re gonna do what they get paid to do. And if they get paid to produce functionality faster, that’s exactly what they end up doing.

    Shimel: Yep. And so this is apparently something, I think, we need to solve. You know, we’re gonna see real progress in the area. But, look, let’s save that for another day. Pete, can you share some more of the findings on the survey with us?

    Chestna: Yeah, absolutely. So a couple of things that stood out to me, as I read through it, was there’s a increased maturity as far as adoption of Agile and DevOps. There’s only 5 percent of respondents that said they have no Agile in their shop at all, where 18 percent say that most or all of their products are using a Agile methodology. And then it goes on from there—28 percent is more than half. So we’re seeing a really good adoption, at least of Agile. And then if you think of DevOps usually being run on an Agile methodology, only 6 percent of respondents says they haven’t adopted DevOps at all and 17 percent are reporting that they have extensively adopted it, so great numbers, as far as people coming up to speed in doing this. And, as far as making things easier, 45 percent of respondents said that DevOps makes it easier for them to developer software, including security, which is a great finding.

    Shimel: That is—what was the number? 45? Just about half?

    Chestna: Yeah.

    Shimel: Excellent.

    Chestna: So those must be shops that are doing it well because they’re seeing the benefits that you get from experiencing DevOps.

    Shimel: Well, I mean, you know, Pete, you take this, I think, in conjunction with the recent release—I was out in London last week for DOES and the folks at DORA and Puppet released the State of DevOps for this year’s survey and results, and it dovetails nicely here, where DevOps-enabled organizations deal with something—I forget what the number was—15 percent less vulnerabilities or 15 –

    Chestna: Right.

    Shimel: It was some –

    Chestna: It was from the Puppet report.

    Shimel: – eye-popping number of the improvement in the quality of code, vis á vis security. So it seems to make sense, but you know what, Pete? I’m amazed that something that seems so, you know, simple, so elementary, if you will, is still—we’re still talking about only half of organizations, a little less than half organizations doing it. What do you think is holding back the other half?

    Chestna: It’s the culture. You know, people wanna maintain their silos. I see it all the time where the management—again, we’re going back to management, as a problem here—they wanna hold on to their silos and their power. And if you look at where DevOps takes a company typically, if you do it whole-hog and embrace everything, you’re reorganizing, so someone that has a large quality staff reporting to them is now gonna have that broken up and disseminated into other teams, and now they’re gonna be responsible for other functions or they’re gonna have to go find another job. So there’s this big unknown and fear for them of, “What does the future hold if I just don’t do quality and I have to actually produce product?” So this cross-accountability is just—is scaring the hell out of them.

    Shimel: Yeah. Yeah. But you know what? Let’s not put it all on the dev side of things; let’s talk a little bit about the security folks, too. And, Pete, you and I both come from the security world. There are a lot of security people who get very territorial, you know, to say the least, around running scans, being the ultimate deciders of what’s secure and not secure, and they’re just as resistant to change, from a cultural point of view, as dev teams are sometimes. I mean, do you agree or –

    Chestna: Yeah, and they white-knuckle the release, so –

    Shimel: Yeah. [Laughs]

    Chestna: – I’ve talked to a lot of people that say, “Hey, it’s gotta be pen-tested. I have to pen-test everything.” If you’re talking about releasing multiple times a day, there’s no way in heck that you’re gonna be able to do that. So you have to pick your battles and say, “This is important. It touches crypto or this touches authentication or authorization. It has to be pen-tested,” versus, “I can use the easy, least expensive way of SAST and DAST to go and find vulnerabilities and I can trust that those tools will find things.” So it’s that back-and-forth of how much security needs to be in there and how assured do they need to feel before they can sleep at night.

    Shimel: Mm-hmm. And they’re ultimately, Pete—you know, I think, when we look at surveys like this and we talk about the view of the security team versus the view of the dev team, view of management, really, the way to kinda bridge these gaps and bring this all together is really a lot of the kinds of things that you do. Right? You’re out there, talking to the different constituencies around the world, almost constantly—we were talking off-mic about how much both of us have been traveling—but there’s a mission there to bring these tribes together, if you will, and forge a common path and a common way of working together. And I think, if we take surveys like this and we look at the results and we share those results with the two teams, again, it becomes sort of like, “Duh. What are we fighting about?”

    Chestna: Oh, exactly. So, I mean, if I go back to the survey for a second here and look at how people are being measured, 33 percent of respondents say, “I’m being measured on functionality that I released,” versus only 18 percent that are saying, “I’m being judged on security.” So, if you look at that number and say, “Well, what are they doing? Their actions reflect how they’re being measured, so let’s change how they’re being measured and see if that changes what they think about their jobs.” The people that responded and looked at “Does DevOps help me with security, the ability to automate and integrate?” 58 percent of respondents said, “Hey, it allows me to do this integration and automation,” which is one step toward getting them to actually pay attention to those results.

    Shimel: Yeah. And 58 percent is a sizable majority.

    Chestna: Yes.

    Shimel: That is Pete, I don’t know if you have the insight on this, but these were large enterprises, primarily, that were surveyed here?

    Chestna: Yes, most of them were—98 percent were 1,000 or more employees.

    Shimel: Okay. Now were there any particular verticals that were highlighted or anything?

    Chestna: The biggest ones were IT at 23 percent and the finance industry at 21 percent.

    Shimel: Oh, okay, there you go. And those are both pretty DevOps-savvy, if you will, or maybe early—no, I don’t wanna use the term “early adopters,” ’cause finance is very rarely an early adopter, but, I mean, certainly, DevOps has taken a strong foothold within the financial and financial services industry, so.

    Chestna: Yeah, and the thing is driving them is really the regulatory compliance, so 53 percent of respondents said that, “We’re doing app-sec because of regulatory.” Forty percent are saying it’s because of corporate governance. And an interesting stat here was 34 percent said it was because of customers or partners, so the great news is people are starting to pay attention to their software supply chain, to say, “Am I getting secure software to install in my environment?” and they’re asking customers to prove that they are. And, hopefully, that also means that outside customers, like individuals, are also looking at security as an important decision in where they go and where they spend their money.

    Shimel: Yep. I agree. I mean, it is interesting stuff, Pete. So, Pete, where do we go from here with this now?

    Chestna: So I think the next step is to continue the journey that you and I are on, of helping security understand development, help development understand security, tell them that they need to build in accountability. It’s built by relationships, so they have to work together. If security starts to teach developers how to do secure development and explains to them how to fix the things that they’re finding, developers are more likely to engage because it’s not this great unknown of “Hey, I don’t wanna go in and fail. I don’t wanna go in and look like an idiot,” or, “I don’t wanna go in and not understand what I’m doing.”

    So security needs to take their part and companies need to understand that training and development and education around security is a carrying cost of having developers. They were never trained to do it and they have to pick that cost up; it’s not like they can just throw them all away and bring in new developers because the developers that they bring in are gonna have the same problem. So getting that education done leads to better engagement, leads to better results.

    Shimel: Agreed. And you know what, Pete? Just a shameless plug on that note: I’m gonna be out in Singapore at the end of July, at the RSA APJ show, putting on another DevSecOps event at RSA, and we’re working with both the local—so it’s interesting. In Singapore, there’s almost a 900-person-strong DevSecOps MeetUp group, which is huge for that area of the world, and there’s an equally-as-big DevOps MeetUp group. And we’re working with both of these MeetUp groups, as part of this event, and we’re really—I’m hoping to really kinda bring these tribes together and make it happen. Of course, I’d –

    Chestna: Sounds great.

    Shimel: – you to come out. You’re in Black Hat at that time.

    Chestna: Yes.

    Shimel: Are you speaking at Black Hat, Peter?

    Chestna: I’m not. I’m doing customer stuff, customer-facing.

    Shimel: Ah, very good. So you’ll be in hot Vegas and I hear Singapore’s pretty warm now that time of year as well. Well, we continue along our mission of spreading the good word, right?

    Chestna: Yes, sir.

    Shimel: as they say. Anyway, so, Pete, we’re about out of time. I know you don’t have the URLs off the top of your head right now, but we will include them in the show notes for people to download the results of the survey and the report, maybe find out a little bit more, but I wanted to thank you for sharing and giving us a little bit of insight into the results. And then keep up the great work, Pete. You do good stuff.

    Chestna: Thanks. I appreciate your time, Alan.

    Shimel: All right, Peter. This is Alan Shimel for devopsy.kinsta.cloud’s DevOps Chat and we’ll see you on the next chat.

    — Alan Shimel

  • Tips to Optimize the Cloud for Scaling

    Tips to Optimize the Cloud for Scaling

    When I first started migrating companies to the cloud (about seven years ago), companies would ask me, “How come the app isn’t scaling? How come users are still complaining about the slowness?” I would explain that the cloud enables auto-scaling, but you still have to make sure your app can scale in the cloud. In people’s minds, auto-scaling and the cloud was synonyms.

    I don’t get asked that question anymore (maybe people realized the cloud is not as magical as it seems). But now, people think the cloud is synonymous with speed, agility and cost-effectiveness. Sure, cloud enables all that. But you still need to make sure you optimize the cloud to facilitate that. I see many companies in the opposite situation: their accounts full of resources with names such as test1, test2 and finaltest2, or they put together a SWAT team to reduce an AWS bill, or security is an afterthought. So many engineers are making changes, it’s hard to know who is doing what.

    Before you run into this situation (maybe you’re already there), you have to create tools and processes to optimize your cloud for scale.

    Establish Strong Policies

    The magnitude of changes in cloud infrastructure is high. Unless you establish strong policies, managing all the resources across multiple cloud accounts get out of control pretty quickly. The most effective way we have seen is using tags for resources. For example, use tags that identify whether the resource is from a certain department are added to each resource. Typically, it works very well when the tagging process is embedded into the automation. If there are new resources that don’t comply, automation should terminate these resources. You should enforce policies like these sooner than later.

    And just because these resources were provisioned with proper tagging, it doesn’t mean they are provisioned for its full capacity. You should build automation to find underutilized instances and establish a process for downsizing. To ensure everyone complies with these policies, you should also establish change management process.

    Change Management and CMDB

    The objective of the change management process is to ensure all the infrastructure changes cause minimum disruption and meet internal guidelines. Many say that ITIL change management process is not compatible for fast environments such as cloud. I agree that the traditional way of doing change management by tracking changes manually just doesn’t work, due to the magnitude of changes. But in the cloud, you can leverage automation to streamline the change management process; for example, you can use automation to filter normal changes versus manual changes. Once all the AWS changes are reviewed and approved, in addition to bringing visibility to all the changes for security and reliability change management can simultaneously help reduce waste.

    Most companies heavily leverage auto-scaling, where new resources can be launched based on specified metrics. However, this behavior makes approving changes difficult. If new resources are appearing and disappearing, how do we track what truly changed in the infrastructure? To gain a true picture, you need an infrastructure delta, which shows resource updates for the still-running resources for a given time period. You can also use automation to build a dynamic change management database, and use auto-discovery to keep CMDB in sync.

    Shared Responsibility

    DevOps calls for breaking down the walls between operation and development team to deliver code faster. If you release software fast, you can rapidly add value to your customer. The cloud enables this culture because developers no longer have to wait for IT to provision resources. What doesn’t work well, though, is when no one takes responsibility for optimizing cost and maintaining security. If engineers can launch resources, they are also responsible for cost and security—it’s a shared responsibility. You should provide visibility to the cost for each department, based on tagging we talked about earlier, so they know the cloud is not free 🙂 Anyone can launch resources as long as they understand the security best practices for each service they are using.

    Conclusion

    Lean thinking calls for reducing waste. What’s waste? Anything that doesn’t add value to the customer. You should work fearlessly to reduce waste. You move to the cloud because you can innovate fast and it’s cost-effective, so you can quickly add value to your customer. You should continue to optimize your cloud infrastructure to ensure it’s meeting its original intent.

    About the Author / JT Giri

    JT is the creator of nOps – AWS cloud security tool. He spent last 10 years helping companies migrate to cloud and build automated infrastructures. nOps is a next generation security and collaboration solution for the cloud. nOps applies change management practices to deliver integrated security and reduce cloud waste.

  • Signal Sciences Looks to DevSecOps to Improve App Security

    Signal Sciences Looks to DevSecOps to Improve App Security

    The time has come to put control over IT security into the hands of the developers who increasingly are being held accountable for it. To make that possible, Signal Sciences has launched a Web Protection Platform (WPP) capable of inspecting traffic in real time across multiple deployment models.

    Intended as a replacement for more traditional web applications firewalls (WAF), WPP redirects any suspicious traffic to a cloud analytics engine without adding any meaningful overhead in terms of overall latency, says Signal Sciences CEO Andrew Peterson.

    What makes WPP unique, he notes, is that it can be deployed in three different modes. When deployed on a local server, no changes to the application code are required. WPP also can be deployed as a reverse proxy in from of a web server. But from a DevSecOps perspective, the most flexible options is to deploy WPP in a runtime application self protection (RASP) mode that allows developers to embed WPP directly into their source code. In the later instance, Peterson says developers can assume security responsibility for their own applications, in keeping with process employed by organizations that have implemented advanced DevOps processes.

    Peterson says WPP not only provides protection against the top 10 most common web applications threats, but it also thwarts distributed denial of service (DDoS) attacks, account takeover and even attacks employing malware embedded in custom business logic.

    Regardless of the delivery model, Peterson says it’s become apparent that legacy WAF are not able to secure modern applications based on containers and microservices, Embedding WPP in application source code enables developers to embed a cybersecurity defense mechanism in each container-based microservice in a way that scales over time.

    As part of its commitment to DevSecOps, Signal Sciences has created 16 pre-built integrations with a range of third-party DevOps tools and security technologies, including Atlassian JIRA software, Datadog, PagerDuty, Slack and Splunk. In addition, DevOps teams can take advantage of an application programming interface (API) that Signal Sciences has developed to integrate WPP with other applications.

    Of course, the whole DevSecOps movement is only in its infancy. Most IT organizations are still struggling with the concept. It’s also not clear how much IT security professionals will be comfortable relinquishing control over application security to developers. However, Signal Sciences claims that 95 percent of its customers have implemented automated blocking, versus only 10 percent to 15 percent of IT organizations that have implemented a WAF.

    Signal Sciences is betting that in much the same way they now exercise more influence over IT operation, developers will play a much larger role in IT security. In fact, as developers are held more accountable for application security, Peterson says many of them will demand to be able to programmatically implement IT security controls. Naturally, there’s no such thing as perfect security. But is the case of application security, DevSecOps may turn out to be our only hope.

    — Mike Vizard

  • ShiftLeft & DevOps: A Narrative Within a Narrative?

    ShiftLeft & DevOps: A Narrative Within a Narrative?

    I procrastinated watching the season finale of “Westworld” just because I ended up reading a day later how Dolores ended the episode! I don’t know who to blame: my inquisitiveness or that guy who couldn’t hold himself. It kind of feels stale when you know the ending.

    Finally, I finished weeding through the multiple narratives across the episodes, and the flashback narrative merged seamlessly with the current one. That got me thinking about using that as an analogy and maybe understand whether the concept of ShiftLeft is really actually a “narrative within a narrative” of #DevOps.

    Ok, so what is ShiftLeft?

    I came across the term at my fav go-to source, @devopsy.kinsta.cloud, where Alan wrote on how much to Shift Left and its diminishing returns, and another very old article on the continuous testing approach, which primarily seeks to test early and often, to catch defects, yeah, early!

    Then it was thrown at me in the context of identifying repeatable activities, often manual with consistent results, performed by the Support & Operations team, and moving that work left from Level-3 all the way to L-0. Empowering the help desk, I would say!

    In both the scenarios, the underlying objective was to catch defects and or reduce life support activities early in the cycle (below) which costs more and more as we move up the food chain, which in turn makes a release and subsequent maintenance cheaper.

     

    As Alan also referred in the same article to the IBM Study, it’s almost 100 times more expensive to fix an eventual production defect which cost about six times more if caught at Implementation stage or about 15 times more if found during testing. Thus, “Early identification and prevention can improve reliable software delivery” would be the mantra.

    Now, to the crux of this article, Is ShiftLeft not what we aim to achieve via DevOps?

    DevOps basically creates a collaborative, non-siloed cultural change to bring both Development and Operations together early in the game.

    Throw in a bunch of tools to facilitate CI/CD, pull in the security guys early, expand automated testing coverage, include change and release—who are the catalysts, as I call these functions in my earlier article here—squeeze in a few monitoring tools and dashboards and voila! You have a complete and mostly successful DevOps team to dish out the most appetizing feast of quality software repeatedly.

    A table for two (Dev & Ops) has become a party of six! Yaaay!!

    So, from DevOps standpoint, ain’t we doing the same as ShiftLefting (If I may coin the word) with the resulting cost effectiveness, more efficiently?

    We do when we as a team make shorter and frequent sprints; gain insight, not just on how to code better or leaner but also by learning from the masters in Operations who run that software on the infrastructure they monitor and support daily. Or perform the VA scan early, or push a scenario as unit test instead of regression, and/or raise flags on potential capacity challenges.

    So again, isn’t DevOps team already doing that ShiftLefting as part of its charter?

    There is a limit to moving things left, but then, if your organization is still doing wireframes under a waterfall or is in the process of setting up a DevOps team, then this approach could be a stop-gap arrangement, an eventual merging of a narrative within a new narrative.

    But then my argument would be, Why stop-gap and why not a full frontal? Why not embrace the DevOps model, which comes preinstalled with all the ShiftLeft possibilities?

    Even if we are aware how an episode ends, procrastinating raises the risk of being left behind in the race to deliver quality, cost-effective product quickly.

    Technology is redefining businesses: Transportation is an app and soon probably will be driverless; banks are rebranding as tech companies in FinServ business; a fridge can reorder milk; trash cans can be Wi-Fi-enabled! Ah, the internet of things. Is Alexa listening?

    My other relevant posts are here and here.

    Thank you for the time.

    — Abdul Salaam Khurram