devopsy.kinsta.cloud

Tag: application security

  • DevSecOps and Development: Making the World Safer One Application at a Time

    DevSecOps and Development: Making the World Safer One Application at a Time

    If you have been around software development much at all in the past five or 10 years, then you’ve certainly heard of DevOps and know it’s here to stay. And it is very likely that you have also heard the term “DevSecOps” even more recently. With today’s extensive proliferation of application capabilities being delivered through services—and all the inherent complexity that comes with the delivery systems for them—it’s no wonder that cybersecurity has moved to the forefront for many companies. In fact, according to research from Stratistics MRC, the current global application security market is growing at a CAGR of 23.4 percent and is expected to reach more than $10 billon by 2023.

    But it is one thing for there to be an interest in cybersecurity; it’s another thing entirely to implement it well—and that is where the conversation gets more interesting. Today, the name of the game in application security is all about bringing the role of the developer into the fold and equipping developers to code, fix and maintain security as part of the software development process. In an article on DevSecOpsDays.com, DevOps thought leader and author Jon Willis offers the following comments:

    Fast forward to February 2017. I was speaking at the RSA Conference in San Francisco and I started seeing for the first time people talk about security as an interesting new way of integrating it into DevOps. They were unapologetically calling it DevSecOps. They were talking about this in a way that included security as a systems (end to end) approach to the traditional DevOps pipeline.

    This was not the first time I had heard people talk about security and DevOps.

    The thing that most caught my eye was that this approach was clearly putting the ownership of security on the developer. I immediately thought back to Werner Vogels’, the CTO of Amazon, statement of “You Build It, You Run It”, back in 2006. However, what I was hearing this time was “You Build It, You Secure It”. This thing they were calling DevSecOps was describing a holistic and systems approach to security as part of the software delivery pipeline.

    This notion of developer empowerment being a critical aspect to success was something I heard again and again at the recent 2018 Black Hat USA Conference. You can read more about my experience at Black Hat in this DZone article. But how do you effectively bring developers into the security fold? That is what we will explore in this multi-part series.

    In this first article, we will focus on what I (and many others) believe is the single most important factor for long-term success: the organizational culture. And by culture I am talking about the day-to-day environment of the organization the developer is a part of, and how they are (or are not) allowed to do their work. A successful DevOps culture is one that promotes collaboration to foster innovation and speed delivery, and the following two sections of this article depict perhaps the two most critical components for a strong DevOps culture: leadership and trust.

    It All Rises and Falls with Leadership

    Many would easily agree with the notion that long-term success for DevSecOps in an organization needs executive support and buy-in—and they would be correct—but real success needs much more than just budget approval and a shifting of resources. It needs ownership. It needs visibility. It needs truth-telling and that is where leadership comes in. According to the PuppetLabs “2018 State of DevOps Report,” 64 percent of C-Suite respondents firmly believed that security teams are involved in technology design and deployment, but only 39 percent of actual team members agreed. Bridging that kind of a gap requires breaking down traditional silos and evolving for better communication and transparency. The same survey also found that high-performing organizations were 24 percent more likely to use automated security policy configurations—a clear indication of tighter cooperation between security teams and the operations teams maintaining production environments.

    So, what are some of the key ingredients of successful leadership in this space? Glad you asked. Here are some things to look for:

    • Balance: Is the organization able to balance lowering technical debt with new work?
    • Shared ownership: Does everyone see how they contribute to business success and how their role impacts it? Is security included in that?
    • Shared learning: As projects progress and complete, is information moving across teams and projects? Are there best practices, lessons learned, etc., that are communicated both internally and externally?
      • Another way to think of this one: Is the level of “tribal knowledge” in your organization getting reduced?
    • Shared Vision Goals: Does everyone see and understand what matters most? Do they know the core metrics and KPIs, and how what they do impact them? Can they see their own success and bottlenecks?

    To have great success, you need leadership that defines the key standards, actively facilitates learning and collaboration and then provides the freedom necessary for innovation to occur. And there is another reason why you need it: Great leadership builds trust. Let’s explore that next.

    Your Speed of Delivery is Directly Proportional to Your Level of Trust

    The best depiction I have seen that correlates the speed of delivery with trust is this simple equation shared with me by DevOps Technical Evangelist Al Wagner from our mutual friend and Senior IT Specialist Lee Reid. It can also be found here. It simply states:

    Where “T” simply stands for time. In this simple equation, you can see that the HIGHER the percentage of trust is in the organization, the LOWER the overall value of the Time to Delivery will be, which is what we are all after. What that tells us is that today, businesses cannot tolerate a trade-off between speed and quality—you need both simultaneously.

    But how to you calculate trust?  In this model we are not talking so much about the work habits of the individuals as much as we are considering the outcome of each part of the process.  We  have to consider how often each of these areas “gets it right” versus how much we have to go back and rework.  Lee provides this example based on a client scenario:

    On a given project team the plan has about a 50/50 chance of being right, and the design is about 85 percent right, and the developers will get about 90 percent of the implementation right, and the testers have about 90 percent of the test cases right, and the release team has about 95 percent reliability of having the right stuff together to release, then your trust factor is something like

    .5 x .85 x .9 x .9 x .95 = 32 percent Trust

    Putting that back into the simple equation above, this level of trust means that your delivery time is three times longer than it could be.

    When my children were in elementary school and doing homework, I used to tell them that sometimes the best way to go fast is to go slow. The point was that if you wanted to solve problems you first had to understand them. Rushing to a formula or just trying combinations of numbers doesn’t work well and it ends up taking you twice as long to get done. This notion of trust and DevSecOps is similar and when you make the initial investment to build trust it can make a real impact.

    While it is true that adding application security to the Tplan and Tdeisgn parts of the process will initially increase those values, having application security as part of the software delivery process from the start—instead of at the end of a release cycle—will naturally cause the values for TDevelop, Tfix, and TEvaluate to shrink. This is largely because you are NOT having to go back to rework security into those areas midstream. It could also actually shrink Tplan and Tdesign over the life of the project for the same reason. In addition, the overall level of trust goes up because the risk that is associated with the delivered items decreases. We are more confident that artifacts are secure if vulnerabilities were identified early and fixed then.

    If you would like to learn more about how you can build trust, lower risk and make real business impact with application security, or to learn more about the potential impact of cognitive capabilities and artificial intelligence on your development efforts, download this complimentary Ponemon Institute study.

    — Rob Cuddy

  • Best Practices for Application Security Testing in the Era of DevOps and AI

    Best Practices for Application Security Testing in the Era of DevOps and AI

    Application security testing is no easy feat. And yet, it’s usually the first topic that most articles about application security address. The reasons are simple: As the pace of application development techniques (and their inevitable vulnerabilities) evolve, AppSec personnel have found themselves caught between the desire to keep pace with their management of security testing requirements and their ability to allow the developer teams to operate in the modern, fast-paced ecosystem of DevOps and artificial intelligence.

    To better understand the best practices for conducting AppSec testing in the era of DevOps and AI, it is important to first appreciate the technologies available to us, that allow us to do so.

    At the heart of the modern application security testing,  there are five main technologies to be aware of:

    1. Static application security testing (SAST)
    2. Dynamic application security testing (DAST)
    3. Software composition analysis (SCA), third-party code
    4. Fuzzing
    5. Penetration testing

    These five technologies account for the bulk of most of the activities around application security testing. However, many aspects of application security testing are rapidly changing, including efforts to incorporate automation and artificial intelligence into the equation.

    By including automation or AI, for example, code testing is allowed to be released in rapid fire sequence, with production use approvals baked inline through automated logic and decision-making. This idea of continuous integration/continuous delivery (CI/CD) can lead to a widening of fractures between the security and development teams. Therefore, DevOps users today need the ability to program their code and test it through automated code scanning techniques before pushing the code into secure staging environments.

    To successfully conduct application security testing in today’s era of advancing developer operations through automation and artificial intelligence, there are three critical best practices to keep in mind.

    1. The Earlier, the Better: Introduce appSec testing into the software development life cycle early on for maximum results: Regardless of the type of testing being conducted, waiting until the very end of the development process will only create more work. Users will either end up with more bugs than they could feasibly fix or find themselves a part of an overworked AppSec team as they attempt to document and deliver on discovered vulnerabilities and code flaws. Statistically speaking, code changes that happen later in the development life cycle are also more costly to the business.
    2. Conduct testing of business-critical applications as often as possible: When deciding which assets are next in line for application security testing, one should consider the applications and systems that are of critical business value to the organization’s revenue stream. Think of these systems in particular as the “crown jewels” for the majority of attacker motives, since they define the amount of money a given organization will procure for that day and, if attacked, could disrupt the business in myriad other ways.
    3. Test for third-party code security and interoperability flaws as you would your own software: The growing complexity of modern applications means there is a need to leverage open source or third-party components. As this is the case, these components must also receive the same level of scrutiny as the applications in one’s own enterprise. All third-party code referenced in the software delivery process must also be checked by performing software composition analysis for security and interoperability flaws.

    While the pace and techniques for AppSec testing will undoubtedly continue to advance, and while there are some AppSec testing techniques that may never become obsolete, it is imperative to ensure that one’s system for maintaining application security testing always adheres to the best practices to preserve a secure software environment for the future.

    — Anthony Lauro

  • Malicious Intent: Open Source Developers, Please Protect Your Users

    Malicious Intent: Open Source Developers, Please Protect Your Users

    For the second time in just a few weeks we’re seeing the fallout of missteps taken by publishers of open source components. It was just recently that I wrote about the GitHub id of go-bindata being highjacked. We don’t know for certain if the intentions were malicious, but the risk was obvious.

    Even more recently we find that credentials were compromised for an npm component called conventional-changelog and a malicious version was uploaded that allegedly included a Monero cyptocurrency miner. Anyone who built or installed an npm package depending on the malicious package is now potentially running a miner and worse, potentially distributing it to their downstream users or customers.

    A few months ago people were laughing at a parody of a similar situation describing credit card harvesting via a compromised package. It’s not so funny anymore, is it?

    Open source developers typically thrive in creating something used by millions or billions of other people. This is the fuel that drives us and knowing that you’ve contributed, even in some small part, to the lives of millions of users is amazing.

    Conversely, knowing that you’ve accidentally inflicted harm on those users through careless practices is probably devastating. Yet, seemingly not enough people are thinking about this beforehand while it’s preventable.

    We open source developers and package maintainers are finding ourselves at the frontline of the new battle. Attackers have recognized the power of open source in terms of broad distribution and are seeking to use that against us.

    We must not let them ruin the reputation of the things we’ve built—or, worse, the entire open source ecosystem.

    If you’re an open source contributor or package maintainer: Pay attention to your own digital security as you would if you were protecting millions of others. Because you are.

    — Brian Fox

  • DevOps Predictions for 2018

    DevOps Predictions for 2018

    The new year is upon us, and that can only mean one thing: outrageous tech predictions! This year, we have a few that are easy to believe and a few that are completely off-the-wall. See if you can pick them out.

    Serverless Overtakes Containers

    Serverless is the future and containers are dead. Some (or maybe even a majority) of the industry will come to realize this. Serverless is largely defined as using functions as a service (FaaS) as the backbone of your architecture. These services are a layer on top of containers that provide an opinionated way to run code that scales with demand and ties true compute usage to costs at sub-second billing increments. Much like virtualization in the data center was dwarfed by cloud providers doing opinionated virtualization a decade ago, serverless offerings will overtake the container market.

    DevOps Backlash Gets Loud

    DevOps has been happily spreading through the industry as an extension of Agile to the rest of IT. But in 2018, the pushback comes. In the early days of DevOps, there was a movement called “No-Ops.” It was championed by some, but then later, reversed back to DevOps. This year, we will see stories of failed digital transformations and DevOps attempts at conferences across the globe. At first, they will be marked as “not doing DevOps right,” but as more and more happen, they will be branded with the old-new stigma of No-Ops—and they won’t come back.

    Chaos Engineering Overtakes the Airwaves

    You remember the Chaos Monkey Netflix released to the IT world that captured the hearts and minds of software engineers everywhere? Well, this is the year when chaos reigns! We’ve already had a taste of it through the new open-source project ChaoSlingr on the Modern Security Series show at Signal Sciences, but my guess is that we are far from done. With the release of Nassim Taleb’s book “Antifragile” in 2014, this has been brewing for a few years. Expect to see more chaos-themed engineering books, conference talks and podcasts in the coming year.

    Software Flaws Mean Prison Time

    Unit testing used to seem like such a good idea, but this year it’s going to become illegal to release software without testing rigor applied. Congress has been on the edge of threatening software accountability legislation for years now, but at this point it looks unavoidable. Will this be the year that a landmark legal battle happens and an engineer who didn’t do proper testing gets thrown in jail? Don’t laugh. We have already seen the first signs of this with the VW diesel scandal; just imagine if it was a pacemaker failure. In 2018, lawyers make the new rules for software engineering.

    Promise Theory Finds New Adoption

    Mark Burgess brought physics to IT through his groundbreaking book on Promise Theory and its implications for the way our applications and infrastructure will be built over the coming years. Instead of making assertions of obligation from machine to machine, networks will be composed of voluntary agents making promises. At the time it was released, Promise Theory received a lukewarm reception. But with the new services-based architectures such as serverless and even the rise of container orchestration platforms, the industry is now ready to adopt Promise Theory thinking. Networks, applications and systems are already functioning as voluntary agents working together through promises. This year, we will see more and more mainstream adoption of the concepts and more examples of how to get it right. Get ready to learn how systems can be self-organizing.

    Application Security Becomes More About the Application

    The perennial web application security checklist is to avoid XSS, SQLi and all the rest of the OWASP Top 10. Application security will finally shift from language and framework vulnerabilities to more conversations around how applications are getting attacked. In the new year, the conversation hinges on account takeovers, fraud detection and abuse inside the application. This is good for the industry because we will move past fighting automatic scanning by adding real instrumentation to detect bad actors.

    Happy New Year!

    The next 12 months are certainly going to be an adventure, and I hope you have a happy new year.

    P.S. Please don’t get thrown in jail!

    — James Wickett

  • 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.

  • It’s Time to Break Up with Your WAF

    It’s Time to Break Up with Your WAF

    If the only reason you have a web application firewall (WAF) is for compliance, you deserve better. It’s time to replace it with something that provides not only compliance, but real security value as well.

    In the land of web application security, there are a few not-so-well-kept secrets, arguably none bigger than this: The WAF survived not by being excellent, but by being mandated.

    The WAF is an antiquated technology that was created to help stem the rise of application security vulnerabilities, which had been overwhelming organizations with their frequency of discovery. Static and dynamic analysis tools dumped huge quantities of bugs onto development teams that had no possible way to fix so many code issues.

    Meant as a stop gap measure to address this problem, the WAF made it possible to filter out rampant SQLi, command execution and XSS attacks that were threatening to consume all of the development and security team’s available resources. The idea behind the WAF was that the application bugs and security flaws would be triaged for now, and then eventually fixed in the code at the root of the problem.

    At the time, a drop-in web application security filter seemed like a good idea. Sure, it sometimes led to blocking legitimate traffic, but such is life. It provided at least some level of protection at the application layer—a place where compliance regimes were desperate for solutions. Then PCI (Payment Card Industry) regulations got involved, and the whole landscape changed.

    PCI requirement 6.6 states that you have to either have a WAF in place or do a thorough code review on every change to the application. Given the unappealing nature of the second option, most organizations read this as a mandate to get a WAF. In other words, people weren’t installing WAFs due to their security value—they just wanted to pass their mandatory PCI certification. It’s fair to say that PCI singlehandedly grew the WAF market from an interesting idea to the behemoth that it is today.

    And the WAF continues to hang around, an outdated technology propped up by legalese rather than actual utility, providing a false sense of security without doing much to ensure it. If that isn’t enough for you to show your WAF the door, here are four more reasons why WAFs should be replaced.

    The Minimum WAF Rules Approach is Broken

    A common side effect of a WAF implementation is the blocking of legitimate traffic. In the application security business, we call these false positives. Don’t be fooled by this innocuous phrasing—what it means is that customers aren’t able to buy things they want, or upload their latest vacation photos or generally use the functionality of your applications. It’s the kind of experience that can quickly turn current customers into former customers.

    To combat WAF false positives, most companies run the bare minimum number of rules to get by. This means that only the most obvious and most egregious attacks are caught, while everything else just sails right past the filter. Simple rules mean easy-to-bypass rules, leaving you with an ineffective WAF.

    Learning Mode is Broken at Speed

    One way that WAFs try to cut down on false positives and avoid breaking valid traffic is through a “learning mode.” In learning mode, the WAF learns what normal traffic looks like versus what malicious traffic looks like and protects accordingly. A lot can be said about how tough it is to get learning mode right, even under perfect conditions, but let’s skip to the real problem we see in production environments.

    Learning mode takes time. WAFs that need to learn to recognize “normal behavior” require a certain amount of traffic review before they can actively block everything else. It may take a few hours to learn safe application traffic patterns.

    When you move from waterfall to agile and DevOps, deployment speed gets faster and faster. The application code changes weekly, daily or even hourly. If you deploy using anything close to a modern cadence, putting the WAF in learning mode on every code change means you are always in learning mode. Essentially, any kind of learning mode, when applied to modern application development techniques, just can’t keep up with the pace of production.

    Monitoring Mode Really Isn’t Compliance

    The fact that WAFs have survived due to legal mandates rather than effectiveness isn’t the only open secret in the business. You also won’t be shocked to hear that most companies never put their WAF into active blocking mode. After all, blocking mode has high false positive rates and breaks your legitimate traffic, so it’s the way to go only if you’re hoping to break your application.

    Instead, the WAF is run in monitoring mode, where it watches traffic and logs any event as an attack. When it’s time for audit, the WAF gets flipped on for a short bit, then back off again. In reality, of course, some auditors don’t even care if you have it in active blocking mode. Just having a WAF in place is good enough for them.

    Running your WAF in monitoring mode is not an effective control. All it does is add a false sense of security and additional overhead to the security team to evaluate logged events. In this scenario, you’re spending money where it doesn’t need to be spent while adding close to zero defensive measures.

    CDN-based WAFs Were for Convenience, not Effectiveness

    The last not-so-fun thing about WAFs is their daily care and feeding. Your WAF adds complexity to your network, and having to dynamically scale it in the cloud is not exactly easy. Enter the content delivery network (CDN). Since most shops are already using a CDN to offload web application woes, why not add a WAF at the CDN layer? This meets compliance (yay!) and we don’t have to manage it (double yay!).

    For many enterprises, this idea is the win-win that has allowed the WAF to persist even as its usefulness has been questioned. The problem with the CDN-based WAF, though, is that you end up running the WAF with a minimum set of rules again (see above or here), leaving the door open to all kinds of attacks. In fact, in my work at Signal Sciences, many customers use our web protection platform behind their CDN-based WAF and discover tons of real attacks that happily made it through the CDN.

    If compliance is your main goal, go ahead and use a CDN-based WAF. If you want real defense, look elsewhere.

    Achieve Compliance and Real Security at Speed

    If this article sounds a little too familiar—if all you’re getting from your WAF is compliance—then it’s time to replace it. There are new options for adding defense at the web application layer and achieving compliance at the same time—for example, using runtime application self-protection (RASP) or next-gen WAF to provide application-aware defensive coverage. This means that, instead of just checking a box for PCI, you can be actively defending against the OWASP Top 10, account takeovers, instrument business logic and fight off bots, all without interfering with legitimate customer activity.

    Don’t settle for compliance alone. You can achieve both compliance and real protection—and that’s what your business and your customers deserve.

    — James Wickett

  • Speaking for the Dead: Are ‘Agile’ and ‘Monolithic’ Actually Good?

    Speaking for the Dead: Are ‘Agile’ and ‘Monolithic’ Actually Good?

    What if Agile is the product of getting bored at work, microservices are the result of us needing a challenge and scrums are the result of an obsessive project manager? Do we all think waterfall development is a dinosaur whose extinction is deserved because of what we have been told and not because of reality? Do we think Agile is better because it simply sounds desirable?

    Michael DeHann (@laserllama), creator of Ansible, spoke at the 2016 All Day DevOps conference, which espouses the benefits of DevOps, and, by association, Agile and microservices. It essentially says, “Let’s step back and evaluate the past. Maybe waterfall development and monolithic architectures are actually a good thing?”

    Michael has been a software engineer and created a key tool in the IT automation toolbox: Ansible. His arguments deserve a look, because re-evaluation can keep you from making mistakes and improve processes going forward.

    Michael started his talk by making the point that in this day and age, it is waterfall versus Agile and monolithic architecture versus microservices. The assumption is that if you are still developing software with the waterfall method and/or developing monolithic applications, you might as well be riding a horse and buggy to work and dialing up coworkers on your rotary phone.

    Throughout his talk, he asked questions to make his points, beginning with, “Is big design up front bad?” with the conclusion, “I don’t think so.” His argument is that design and requirements at the beginning of the process enable a better production. Marketing and engineers hammered out requirements based on needs, abilities and budgets. There was plenty of time to research and design solutions. Both sides worked together, raising questions and comments and documenting mutual agreement. This presented an accurate view of the strengths of various team members and dependencies between tasks and task orders. And, perhaps most important, engineering was engineering—the engineers had greater responsibility and less hand-holding.

    Contrasting that with his view of Agile, big design up front is labeled as bad or counterproductive, engineers are viewed as interchangeable and scope is more unpredictable. Estimates are encouraged to not be time-based, which often results in a constant crunch time. Finally, meetings can consume a significant portion of team members’ time and often include “games reminiscent of Kindergarten, such as Fist of Five or Planning Poker.” Even in lightweight Agile systems, testing can suffer, requirements are more vague and there is no mutual sign-off.

    Michael argues that there can, in fact, be a middle ground where teams:

    • Do share design
    • Have an accessible, effective product owner
    • Know hard requirements versus soft requirements
    • See test-driven development and test automation as super important
    • Understand that Agile and iterative development can be closer than we think

    Agile and DevOps are also often associated with microservices versus monolithic applications, but according to Michael, “What’s so bad about a monolith?”

    Sample Monolithic Diagram

    dehann1.png

    Sample Microservices Diagram

    dehann2.png

    An example microservices shop has 150 services, many thousands of Jenkins builds per day, eight Amazon regions including dev, staging and production and thousands of EC2 instances. This can result in Jenkins configuration and security enforcement drifts, suboptimal code sharing and DevOps writing lots of custom code to manage it.

    Michael contrasts that with monoliths, which have:

    • Increased ability to develop on one laptop
    • Interfaces that benefit from static typing versus design-by-contract
    • Very small numbers of different server/image types in production
    • Local function calls that are much faster than RPC
    • Few instances sitting around with 5 percent utilization
    • No need for “containers” to get around above utilization problem
    • Greatly simplified debugging
    • Easy code-sharing
    • Very simple version upgrades

    Rather than argue that all applications should be monolithic, he makes the point that many of the concerns that resulted in microservices could be solved with improved communications. He contends that microservices are a tech solution to a people problem.

    Michael concludes that:

    • Labels cloud true meanings,
    • Monolithic architectures are more efficient,
    • Agile can be less efficient,
    • Microservices attempt to solve people problems but introduce new technical and people problems, and
    • We should try and separate the labels from the true meaning of things.

    Most importantly, though, is the fact that there is something to learn from everything. So, even if you don’t agree with Michael’s conclusion, you should listen to his talk online here. You might learn an unexpected lesson.

    If you missed any of the other 30-minute long presentations from 2016 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 Oct. 24.

    — Derek E. Weeks

  • 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

  • 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

  • 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