devopsy.kinsta.cloud

Tag: security teams

  • How IaC Bridges the Divide Between DevOps, Security

    How IaC Bridges the Divide Between DevOps, Security

    IaC provides a connection between security and DevOps teams in a subtle, non-intrusive manner

    Companies often choose DevOps as means to provide value and responsiveness through rapid, high-quality service delivery. Instead of traditional siloed development and operations teams, DevOps embraces multidisciplinary teams that share efficient practices and tools. Essential DevOps practices include agile planning, continuous integration, continuous delivery and application monitoring. But how does security fit within this framework?

    Traditional models of product development have explicitly defined processes and people dedicated to security assessments, analysis, testing and maintenance. While this doesn’t offer the efficiency and agility of DevOps, many organizations find comfort in having a set place and time for security.

    In DevOps, with the absence of strictly defined and linear processes, there is perhaps a less explicit definition of where and how security fits in. But sometimes there is power in the less obvious aspects of life. In fact, just because there aren’t dedicated, standalone security processes as there are in traditional product/project management models doesn’t mean that security isn’t there.

    Some could argue that the less apparent security is, the higher its efficacy. This is particularly true in the DevOps world, where security teams are sometimes perceived as impeding the speed and agility of DevOps teams. This perception is unjust because, quite often, it is not the security team that is necessarily impeding the progress of the DevOps team. The root of the problem is a fundamental disconnect between the security and DevOps teams.

    So, how can teams overcome this divide? By evolving their DevOps team into a DevSecOps team. Every company’s goal should be to make security part of the development workflow. Again, DevSecOps is the natural evolution of DevOps. The process can either take the benefits that DevOps gives to the development and operations branches of your IT department and extend them to the security team, or it can integrate the security processes into the DevOps team. With the latter approach, the bridge is then built by shifting cloud security left using infrastructure as code (IaC) plans and templates. Security teams can build these plans and templates for developers as a way of guiding them toward security and compliance and preventing policy violations and cloud misconfigurations from the very beginning. Shifting much of the security team’s work earlier in the development life cycle, long before runtime, is a smart and efficient approach.

    Through the use of IaC templates and plans, DevSecOps teams are engaged in security from the very start. And, for the most part, the layer of security in the form of an IaC template or plan is silent. It is a noninvasive way for security to participate in DevOps, without the friction that sometimes arises in the midst of chaotic runtime security fixes. Though its presence may be subtle, the benefits of hard-coding cloud security through IaC are pronounced.

    Most conspicuously, it prevents the need for security to intervene in recurring problems. The same security issues, policy violations and misconfigurations that took time and resources to resolve can be addressed at a global level through IaC plans and templates. Secondly, the efficiency of the security team grows exponentially. Time previously spent tracking down the right developers to fix ephemeral security issues and misconfigurations is redirected and refocused. Security teams are able to spend their time more wisely, creating thoughtful, holistic approaches delivered through IaC plans and templates. Another benefit of creating DevSecOps teams and using IaC is that it can empower individual teams to use the tools of their choice.

    While some companies mandate the use of specific cloud service providers or third-party tools, others do not. When used correctly, security achieved through the use of IaC templates provide the flexibility of incorporating variables from any cloud environment. DevSecOps teams that have the opportunity to use the cloud service providers and tools of their choice will work more efficiently and effectively. The final and most significant benefit is the connection that IaC provides between security and DevOps teams. Not only does it broaden participation in security, it does so in a gentle, non-invasive manner.

  • Fostering Better Collaboration Between ITOps and Security Teams Should Be Top Priority

    Fostering Better Collaboration Between ITOps and Security Teams Should Be Top Priority

    Last year, the average business lost $13 million to cybercrime, which is 12% more than in 2017 and 72% more than in 2014. When Tanium recently asked IT decision makers how they planned to reduce that risk in 2020, they reported making multi-million dollar investments across operations and security. Over the last two years, they increased operations budgets by 11% and allocated 18% more funding to security teams.

    However, despite massive budget increases, both operations and security teams continue to struggle. Only half of the teams that Tanium surveyed said they had full visibility into their environments’ vulnerabilities and risks (51%), and less than half said they had full visibility into all of the hardware and software connected to their networks.

    Businesses are investing more in tools than ever before, but the issue isn’t more investment — it’s the right investment. “More tools” aren’t bringing siloed IT teams closer together, and aren’t achieving the kind of total visibility and control of all endpoints needed for effective risk mitigation.

    Here are some ways to reconsider the crucial collaboration between IT operations and security teams.

    Find Areas to Align

    While just 27% of the enterprises we consulted on these issues would describe their IT teams as “embedded,” as many as 67% said that coordination among teams is extremely challenging. Aligning the security and operations teams is one way to overcome this challenge. Different teams using different tools and receiving different data sets have little room for compromise, but teams united by a common toolset are not only more likely to collaborate; they are also better resourced to mitigate risk and protect valuable data. As teams do away with the point tools and invest in coordinated, platform-based solutions, their ability to easily verify the quality of their data, trust their vulnerability scans and remediate threats at scale will significantly improve.

    Prioritize Visibility Across the Environment

    While most IT decision makers (80%) believed they could instantly act on the results of their own vulnerability scans, fewer than half (49%) thought they had full visibility into all the hardware and software assets. But without full visibility, the vulnerability scans are merely good enough, and unable to account for areas managed by other teams. That false confidence is even worse in IT departments that have a rift between security and operations.

    If businesses fail to gain a view of the entire environment, it could take them two weeks longer to patch IT vulnerabilities (37 business days versus 27.8 business days for teams with a healthy relationship). By implementing an end-to-end view of the entire environment, both teams will be able to gain the visibility of the computing devices they need to protect organizational data.

    Reduce Complexity Between Teams

    More tools lead to a more complex environment. Tanium’s research showed that IT operations and security purchased an average of five new tools each within the last two years, and large organizations reported using as many as 40 to 50 point solutions. It’s no wonder why this happens: As new problems emerge, each team seeks a new solution based on that individual problem, ultimately creating an environment too difficult to manage. To keep an organization nimble and responsive, ITOps and security must work together to select solutions that are capable of solving the range of problems that both teams face, and agree on what data is most important.

    Create a Culture of Improved IT Hygiene

    As many as 80% of the organizations we spoke to said that maintaining IT hygiene was the most challenging task for IT operations and security teams. Once the entire department begins to prioritize the fundamentals, response times will improve and prevention and detection methods will sharpen.

    Conclusion

    Businesses that do not take these steps are vulnerable to disruption. It is essential that IT operations and security teams unite around a common set of actionable data and are empowered to ask questions about the state of every endpoint across the enterprise, retrieve data on their current and historical state, and execute change as necessary. These teams must come together from day one to maintain performance and security within their organizations — or continue to face the threat of cyberattacks, outages and other business-crippling disruptions.

  • Who’s Responsible for Security? Apparently, It Depends

    Who’s Responsible for Security? Apparently, It Depends

    More than 10 years after organizations began implementing DevOps, responsibility for security still resembles the proverbial chicken and egg dilemma.

    GitLab’s 2020 Global DevSecOps Survey asked developers, security team members, operations pros and testers about sole responsibility for security in their organizations.

    About 28% of developers, 33% of security teams, 21% of ops pros and 23% of testers said responsibility for security rested only on their shoulders. At the same time, 29% of security teams said everyone was responsible, nearly as many as said they had sole ownership.

    Confused yet? So were many of our survey respondents, who had a lot to say about the fluid – and frustrating – nature of DevSecOps.

    “The team is trusted to do its own security research and implementation. We don’t know how good or bad we are.”

    “I am the only one who actually cares about security in my organization.”

    “I regularly put security suggestions in the box of suggestions, only to be ignored.’”

    “There’s a security team, but it doesn’t involve face to face with us, the dev team. So we just run the dev process without counting on them.”

    The Blame Game

    There’s a long history of developers and security pros not seeing eye to eye. In GitLab’s 2019 Developer Survey security pros were very expressive on the subject of developers simply not doing enough to enable security. Developers were equally unhappy, citing security’s “heavy-handed approach.”

    This year, we drilled down further to see if we could understand why dev and sec continue to see the world differently.

    Differences between the teams quickly became apparent. According to the survey findings,  65% of security team members told us their organizations have shifted security left. But the devil is in the details, and the details do not really support a shift left.

    A solid majority of developers are not running SAST, DAST or container scans, and only about half conduct compliance scans. Even if the scans are run, less than 19% put SAST results into a pipeline report a developer can access. Dynamic application security testing (DAST) fares even worse – less than 14% of companies gave developers access to those reports.

    So, developers don’t have easy access to critical data. On the other hand, security pros are frustrated that developers continue to either miss bugs altogether or find them too late in the process. Over half of security respondents (61%) agreed at some level that vulnerabilities were mostly found by security pros (not developers) after code is merged in a test environment (which is relatively late in the process). In other words, when asked how developers find bugs versus security teams, 93% gave developers credit for discovering only 25% or less of the bugs to be found in existing code, leaving three-quarters of the bugs for security to find at a later stage in the process.

    And as if that wasn’t sufficiently frustrating, 69% of security team members complained it was difficult to get developers to remediate bugs, even if their organizations included security as a developer performance metric.

    How DevSecOps Can Work

    Clearly, there is work to be done to get developers and security on the same page, but we are seeing a few glimmers of hope. Security pros are not quite the lone wolves they once were; many told us that DevSecOps has brought a welcome change to their responsibilities. Nearly 28% reported being part of a cross-functional team focused on security and almost the same number (27%) said they were more hands-on and involved in the day-to-day development activities. Almost 23% said they were now focused more on compliance and about 20% said they did not see any changes in their roles.

    In perhaps the most significant (and promising) finding, GitLab asked what skills would be most important to a security professional’s future, the majority (almost 28%) said soft skills like communication and collaboration. Interestingly enough, a majority of their developer counterparts agreed with that.

    So, while no one agrees just yet on who owns security or even how to prioritize security, it’s encouraging that both developers and security pros realize they need to prioritize communication and collaboration.

    At least one respondent reports success in figuring it all out:

    “We don’t have separate security, developers and operations; we are DevSecOps (and more).”

  • GitLab Survey Surfaces Major DevSecOps Challenges Ahead

    GitLab Survey Surfaces Major DevSecOps Challenges Ahead

    A report based on a survey of 4,071 software professionals published this week by GitLab, a provider of a continuous integration and continuous deployment (CI/CD) platform, found that while appreciation of the potential value of DevSecOps best practices is high, the ability to implement those practices is uneven at best.

    According to the survey, half of the respondents reported that security vulnerabilities are discovered mostly by the security team rather than developers after code is merged and in a test environment. And, when cybersecurity professionals participate in a DevSecOps process, the survey found those organizations are three times more likely to discover bugs before code is merged. In addition, a full 90% of those organizations are more likely to have tested between 91% and 100% of their code early in the development process.

    Obviously, that’s better than discovering them after they’ve been deployed in a production environment. On the downside, however, nearly half of security professionals participating in the GitLab survey (49%) said they struggle to get developers to make remediation of vulnerabilities a priority. That challenge may reflect the overall maturity of the DevSecOps practices in place. For example, only 25% of developers participating in the survey rated their security practices as being good. That compares to only 20% of security professionals who rated their processes as good. Only 14% of respondents said they are relying on application security tools to test more than 91% of their code. A full 44% are using these types of tools to test less than a third of their code.

    Priyanka Sharma, director of technology evangelism for GitLab, said the survey makes it clear that DevSecOps is now officially a thing in the enterprise. However, only 44% of the survey respondents said that security vulnerabilities are a performance metric for developers in their organizations. As such, it’s clear there is still a long way to go before anything approaching DevSecOps nirvana is likely to be achieved. In fact, Sharma noted building and deploying more secure applications may require organizations to slow down the rate at which applications are being built, at least initially.

    The GitLab survey makes it clear most organizations are still struggling with mastering DevOps. Only 28% of developers said they feel good about their organization’s level of DevOps sophistication, while less than half (45%) said they have been able to implement continuous code deployment at least somewhere in their organization. That level of adoption suggests there still is plenty of opportunity to refine DevOps processes that are not fully ingrained. In fact, it appears most organizations are still trying to master agile development methodologies—more than half of the respondents said they employ Scrum (54%) as their application development methodology, followed by Kanban at 37% and DevOps at 36%.

    Ultimately, most organizations will have no choice when it comes to embracing DevSecOps. There simply are not enough cybersecurity professionals available to secure every application on their own. That means developers will need to assume more responsibility for cybersecurity, regardless of whether they like it. DevSecOps processes will be required to validate whether developers have implemented all the security patches and controls required. Anything less than that going forward will be deemed as nothing short of reckless—which, as any lawyer will gladly share, means much higher penalties for everyone involved.

    — Mike Vizard

  • Software Security is an Engineering Problem

    Software Security is an Engineering Problem

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

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

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

    Software Delivery Has Changed (Along with Security Responsibility)

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

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

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

    Now is the Time to Rethink Software Security

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

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

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

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

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

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

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

    About the Authors

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

     

     

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