devopsy.kinsta.cloud

Tag: vulnerability management

  • Vulnerability Management for DevOps Teams: A Practical Guide

    Vulnerability Management for DevOps Teams: A Practical Guide

    Vulnerability management is a process that includes the identification, categorization, prioritization and resolution of security vulnerabilities in software systems. It involves a continuous cycle of protection to ensure that your digital assets are secure and your operations are running smoothly.

    With the rapid evolution of technology, fast-moving cloud-native systems and evolving cyber threats, it’s critical to stay ahead of the game. The goal is to close the gap between the discovery of vulnerabilities and their resolution, thereby minimizing the window of opportunity for potential attacks.

    Vulnerability management is not just about finding and fixing vulnerabilities. It’s also about understanding the nature of the vulnerabilities and the potential impact they could have on your network and systems. This understanding informs the prioritization process, helping teams decide which vulnerabilities need immediate attention and which ones can be addressed later. See this blog post for an in-depth review of vulnerability management.

    Why is Vulnerability Management Important for DevOps Teams?

    With the DevOps approach, development and operations teams work together throughout the software life cycle. This collaboration results in faster development times and more reliable software. However, the fast development cycle also introduces new security challenges. This has given rise to the DevSecOps paradigm, where developers, operations teams, and security experts collaborate during all stages of the development lifecycle.

    Here are a few reasons vulnerability management is a critical part of DevSecOps practices:

    Early Detection of Vulnerabilities

    DevOps teams are under constant pressure to deliver high-quality software quickly. However, the speed of delivery should not compromise the security of the software. Vulnerability management helps DevOps teams identify vulnerabilities early in the development process. This early detection allows teams to address security issues before they become serious problems.

    Early vulnerability detection is not just about finding vulnerabilities; it’s also about understanding the potential impact of those vulnerabilities. It involves analyzing the vulnerabilities to determine their severity and the risk they pose to the system. This analysis informs the prioritization process, ensuring that the most critical issues are addressed first.

    Building Continuous Security Into CI/CD Pipelines

    Integrating vulnerability management directly into continuous integration/continuous deployment (CI/CD) pipelines is essential for maintaining continuous security. CI/CD pipelines automate the steps in software delivery, from code integration to deployment, ensuring faster and more consistent releases. By embedding vulnerability management into these pipelines, DevOps teams can automatically scan for and address security vulnerabilities at each stage of the software development life cycle.

    Incorporating vulnerability management tools into CI/CD pipelines allows for automatic scanning of code repositories, container images, and even infrastructure-as-code (IaC) configurations for known vulnerabilities. This integration means that any security issues are identified as soon as code is committed or containers are built, not just at the deployment stage. The advantage of this approach is twofold: It reduces the risk of deploying vulnerable software, and it allows developers to fix issues in their context of development, making the process more efficient.

    Cost-Effective Development and Operations

    Implementing vulnerability management can lead to cost savings for DevOps teams. By identifying and resolving vulnerabilities early in the development process, teams can avoid the high costs associated with fixing security issues after the software has been deployed. In addition, vulnerability management can help prevent costly security breaches that could damage the company’s reputation and result in financial loss.

    Moreover, vulnerability management can contribute to more efficient operations. By systematically managing vulnerabilities, teams can avoid wasting time and resources on low-priority issues. Instead, they can focus their efforts on addressing the most critical vulnerabilities.

    Enhancing Cross-Team Collaboration

    Vulnerability management can also enhance cross-team collaboration within the DevOps environment and between DevOps and security teams. By providing a clear framework for identifying, categorizing, prioritizing and resolving vulnerabilities, it fosters a shared understanding of security issues among team members. This shared understanding can facilitate communication and cooperation, ultimately improving the software product’s security posture.

    Strategies for Integrating Vulnerability Management Into DevOps Processes

    Adopt a ‘Shift-Left’ Approach

    The ‘shift-left’ approach is a strategy that involves shifting the security measures to the early stages of the DevOps pipeline. Traditionally, security checks and vulnerability assessments were conducted toward the end of the development cycle, often leading to late discovery of security flaws and vulnerabilities.

    By shifting these security measures to the left, i.e., to the earlier stages of the development cycle, DevOps teams can catch and fix security vulnerabilities early on. This approach aligns well with the DevOps philosophy of early error detection and continuous improvement.

    Automation of Vulnerability Scanning and Detection

    Automation is at the heart of DevOps. It allows for rapid, reliable and consistent processes, freeing up the team to focus on what they do best – delivering quality code and features. Automation should also extend to vulnerability management.

    Automating vulnerability scanning and detection means integrating security tools into the DevOps pipeline that can automatically scan the code, detect vulnerabilities and even suggest fixes. This approach ensures that security checks are not skipped or forgotten and that vulnerabilities are dealt with promptly.

    Security as Code

    Another strategy for integrating vulnerability management into DevOps processes is embracing the principle of security-as-code. This principle treats security infrastructure and configurations as code, allowing them to be part of the DevOps pipeline.

    By adopting security-as-code, DevOps teams can ensure that the security configurations and infrastructure are always up-to-date and follow the best practices. Like the rest of the code, security configurations can be version-controlled, reviewed, tested and automatically deployed.

    Collaboration Between Security and DevOps Teams

    One of the key tenets of DevOps is collaboration between different teams. In a DevSecOps paradigm, this collaboration extends to the security team as well. Integrating vulnerability management into DevOps processes fosters close collaboration between the security and DevOps teams.

    The security team can provide valuable insights into the security landscape, vulnerability management tools and best practices. On the other hand, the DevOps team can ensure that these insights and tools are integrated into the DevOps pipeline.

    Continuous Monitoring and Feedback Loop

    Continuous monitoring is crucial for effective vulnerability management. Continuous monitoring ensures that the security state of the system is always known and that any changes or vulnerabilities are promptly detected. The feedback loop ensures that the insights gained from monitoring and vulnerability assessments are fed back into the development process, leading to continuous improvement in security.

    Regular Training and Awareness

    Finally, regular training and awareness are crucial for integrating vulnerability management into DevOps processes. DevOps teams should be trained in security best practices, threat landscape, and use of vulnerability management tools.

    Regular training ensures that the team stays up-to-date with the latest security trends and vulnerabilities. Awareness sessions can help the team understand the importance of security and vulnerability management, encouraging them to take an active role in securing the system.

    Conclusion

    In conclusion, integrating vulnerability management into DevOps processes is not only possible but crucial for secure and reliable systems. Adopting a shift-left approach, automating vulnerability scanning and detection, embracing security-as-code, fostering collaboration, implementing continuous monitoring and feedback and ensuring regular training and awareness are some of the strategies that can help achieve this integration. 

    Remember, vulnerability management is an ongoing process that requires commitment, collaboration and continuous improvement.

  • Poor App Remediation Creates a Vicious Vulnerability Cycle

    Poor App Remediation Creates a Vicious Vulnerability Cycle

    A survey of 200 security professionals found nearly 83% of respondents reported that an increase in the rate at which applications are being deployed has led to an increase in the reintroduction of previously remediated vulnerabilities.

    The survey, conducted by Waratek, a provider of tools for managing security-as-code, found 93% of the security professionals polled currently work for organizations that have embraced DevOps or Agile development methodologies. Half of the respondents (50%) described maintaining security in those environments as challenging, with a slightly higher percentage (58%) noting that implementing security within DevOps process does slow down the rate at which applications are deployed. A full 85% also noted that manual security work slows the rate at which applications can be deployed as well.

    Surprisingly, more than two-thirds (67%) of security professionals also said they would be willing to sacrifice security to allow applications to be delivered on time.

    Nearly three-quarters (71%) also said they expected that keeping pace with DevOps teams would only become more difficult, with 61% also noting that keeping pace with DevOps teams resulted in delays to other critical security projects.

    Waratek CEO Doug Ennis said the root cause of the application security challenge can be traced back to continued reliance on manual processes. It’s too easy for developers, for example, to reuse code that contains vulnerabilities that were fixed in one version of an artifact but not another, he noted.

    That lack of automation also conspires to increase overall cybersecurity fatigue, added Ennis. More than 50% of survey respondents reported they spend days or weeks each year investigating false positives. There simply are not enough cybersecurity professionals available to make sure applications are secure without relying more on automation, said Ennis.

    In the wake of a series of high-profile security breaches, there is more focus on software supply chain security than ever. However, it’s not clear to what degree organizations are embracing automation and DevSecOps best practices to secure those software supply chains. The challenge is finding a way to build more secure applications without slowing down the rate at which those applications are built and deployed.

    Many organizations are clearly already shifting more responsibility for application security left toward developers and DevOps teams with hopes of achieving that goal. However, it’s still the cybersecurity team that get the call whenever there is a breach, noted Ennis. There must be workflows in place that enable automatic remediation in ways that don’t always require organizations to wait on a developer to build and deploy a manually-applied patch that is usually inconsistent, he added.

    The Log4Shell vulnerability is a perfect example of how flawed the current process for building and deploying patches is, Ennis explained.

    In fact, as more applications are deployed, developers often find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building and deploying secure applications that leverages automation is clearly required. The challenge is creating automation that consistently achieves that goal each and every time required in a way that doesn’t break any of the applications that need to be fixed.

  • Majority of Orgs Lack Visibility Into Container Vulnerabilities

    Majority of Orgs Lack Visibility Into Container Vulnerabilities

    Today’s blend of third-party application dependencies and polyglot software development often makes assessing risk difficult. With many new cloud-native deployment models, it can be tricky to discover potential vulnerabilities. These threats take the form of insecure default settings in Kubernetes, over-permissive states, CVEs that threaten container integrity, and other vulnerable conditions.

    Plugging gaps throughout the cloud-native strata is now crucial to avoid exposing data and breaking privacy regulations. Yet, gaining visibility into these holdings is challenging, and traditional application security practices may not cut it within a cloud-native context.

    A new 2021 CISO Report released by Dynatrace, “Precise, automatic risk and impact assessment is key for DevSecOps,” demonstrates increased false positives and a general lack of real-time container runtime vulnerability scanning among enterprise IT departments worldwide. Of the 700 CISOs surveyed, most report that microservices, containers and Kubernetes have caused security blind spots across their organizations.

    Below, we’ll cover the major takeaways from the study to see why new cloud-native development models are leaving security gaps. We’ll consider how CISOs can increase security throughout the cloud-native IT stack while still reaping the rewards of container-based delivery models.

    Cloud-Native Security Blindspots

    Adopting new container-based technologies may introduce multiple nuanced security implications. Of the tech leaders surveyed, 89% report that microservices, containers and Kubernetes have created new vulnerabilities within their organizations.

    Engineers are shipping code to maintain release velocity and to meet the demand for digital innovation. In the process, 28% of CISOs say application teams sometimes bypass vulnerability scans to speed up software delivery. Due to these realities, it’s no surprise that 71% of CISOs admit they are not fully confident code is free of vulnerabilities before going live in production.

    As some teams bypass security pre-production, it follows that more aren’t applying holistic security scanning during production. As a result, nearly all organizations (97%) lack real-time visibility into runtime vulnerabilities, found the report.

    Adding to the number of cloud-native blindspots is information overload. The report calculated that, on average, an organization receives a staggering 2,169 new alerts of potential application security vulnerabilities each month. Out of this high volume of alerts, 77% of CISOs say they are mostly false positives and not actual exposures.

    Due to minimal testing and a high number of false positives, organizations are likely to leave many vulnerabilities unpatched. To make matters worse, developers, pressed for time, may lack the bandwidth to resolve known issues.

    Faster Delivery, Harder Detection

    Much of the setbacks in vulnerability detection may lie in a general shift toward new ways of working and faster delivery cycles. For example, 63% of CISOs reported that DevOps and agile methodologies are making it harder to detect and manage vulnerabilities.

    In addition, 74% of CISOs say traditional security controls such as vulnerability scanners no longer fit today’s cloud-native world, and 77% of CISOs agree that automation could help. This could involve replacing manual deployment, configuration and management with more automated approaches. Others agree that security-as-code is required to ensure high container security best practices.

    Another result of more frequent delivery is increased over-reporting. Of the total security vulnerability alerts received per month, CISOs report that only 42% of these alerts require action. More rapid release cycles could thus exacerbate already crowded vulnerability detection systems.

    Who Owns Vulnerability Management?

    Only 3% of organizations have real-time visibility into runtime vulnerabilities in containerized production environments, the study found. In reality, vulnerability scanning in production is only happening once a month or less within 68% of organizations.

    To compensate for this gap, most CISOs believe the onus is not on the security team but the application and DevOps teams to manage and respond to vulnerabilities—85% of CISOs believe these groups should hold responsibility for vulnerability management. These findings come to light as other stakeholders advocate for increased full-cycle developer control and encourage the DevOps mindset across roles.

    Handing more control to developers sounds good, yet, 64% of respondents say developers don’t always have time to resolve vulnerabilities before code goes into production. As a result, over one-quarter of application teams bypass vulnerability scanning entirely. Often, engineering teams may not frequently sync with security groups, and DevSecOps principles are not yet pervasive throughout all organizations.

    The report also highlighted the fact that existing security tools are often ineffective; 69% of CISOs say security tools slow down DevOps because they only focus on one state of the software delivery cycle.

    Cloud Use Requires Security Repositioning

    As cloud architectures rise in prominence, organizations are adopting cloud-native tools like microservices, containers and Kubernetes. There is also the chance of multi-tool conditions further complicating the vulnerability scanning process. With more systems to protect than ever before, teams may have to reposition their approach to vulnerability detection.

    “The increased use of cloud-native architectures has fundamentally broken traditional approaches to application security,” said Bernd Greifeneder, founder and chief technology officer at Dynatrace. “This research confirms what we’ve long anticipated: manual vulnerability scans and impact assessments are no longer able to keep up with the pace of change in today’s dynamic cloud environments and rapid innovation cycles.”

    The Global CISO report, “Precise, automatic risk and impact assessment is key for DevSecOps,” from Dynatrace, queried 700 chief information security officers (CISOs) on their monitoring practices concerning vulnerabilities. To review the report’s full findings, you can download it here.

  • How to Source Vulnerability Data for True DevSecOps

    How to Source Vulnerability Data for True DevSecOps

    Open source comes with code vulnerabilities that must be considered in the DevOps process

    The war between open source and “only proprietary code” is long over. Open source won the day by convincing the opposition of the benefits of joining the open source community. “Vulnerabilities in the Core,” a report published by the Linux Foundation and the Laboratory for Innovation Science at Harvard in early 2020, explained: “Open source has now become an integral component of the modern economy and is a fundamental building block of everyday technologies like smart phones, cars, the Internet of Things, and numerous pieces of critical infrastructure.”

    Development teams have embraced open source for its inherent strengths: efficiency, speed, quality and innovation. As one Gartner report puts it, “In most modern DevOps development projects, the majority of code used in an application is made up of open source.”

    But open source comes with code management responsibilities that DevOps teams need to consider. Open source has the same security risks that plague all software—bugs or other defects that could be exploited by hackers. While larger open source projects have communities that generally issue patches for vulnerabilities much more quickly than commercial vendors, thanks to thousands of “eyes” on the code, keeping open source software secure is not as simple as enabling auto-updates, as is done for much commercial software.

    Unlike commercial vendors that automatically “push” patches out to users, open source operates on a “pull” model. As patches are made available, consumers of the open source component first need to be aware that the patch is out there and then “pull” it from a repository to accomplish the needed update.

    The NVD and Its Timeliness Problem

    Public sources such as the National Vulnerability Database (NVD) are a good first step for information on publicly disclosed vulnerabilities in open source software. However, you need to keep in mind that there can be significant lags in data reporting, scoring and actionability of the data in an NVD common vulnerabilities and exposures (CVE) entry, with some research reporting an average 27 days between the initial announcement and NVD publication. The format of NVD records also makes it difficult to determine which versions of any given open source component are affected by a vulnerability.

    For example, the Linux vulnerability CVE-2016-5195, popularly known as Dirty Cow, was announced Oct. 19, 2016. Proof-of-concept code exploiting the vulnerability was available a full two weeks before the Nov. 10 listing for the CVE in the National Vulnerability Database. That’s two weeks in which anyone relying on the NVD would have been left in the cold.

    The problem is more recently reflected in the findings of the 2020 Open Source Security and Risk Analysis (OSSRA) report, produced by the Synopsys Cybersecurity Research Center (CyRC). Four of the top 10 vulnerabilities found in the audited codebases did not have CVEs associated with them at the time of the report’s publication. The vulnerabilities without CVEs included high-severity flaws in jQuery and FileAPI. Those security issues can be fixed with updates of the respective open source components, as can the majority of vulnerabilities listed in the CyRC OSSRA report. But, to patch any of those CVE-less vulnerabilities, you first need to be aware of them.

    The issues impacting the NVD’s ability to publicize security vulnerabilities make it unwise to rely solely on that organization for vulnerability information. While I’m not recommending abandoning the NVD, DevOps teams should look to a secondary source of information that will provide better notification of vulnerabilities affecting your codebase and, ideally, supplement notifications with technical details and upgrade and patch guidance.

    Augmenting NVD Vulnerability Information

    Many commercial software composition analysis (SCA) solutions can provide you with more timely, richer vulnerability data than the NVD alone, proactively finding issues and helping you fix them quickly when warranted. If you’re considering an SCA solution, you should ask your vendor what they offer in the form of security advisories and alerts.

    For example, consider the Common Vulnerability Scoring System (CVSS), an industry standard for assessing the severity of a vulnerability. The CVSS score (v2 and v3) provides an overall base score that takes both exploitability and impact into account.

    A robust SCA solution will provide a temporal score in addition to the CVSS base, exploitability and impact scores. Temporal scores take into account metrics that change over time owing to events that are external to the vulnerability. Remediation levels (“Is there an official fix available?”) and report confidence (“Is the report confirmed?”) can help temper the overall CVSS score to an appropriate level of risk.

    Similarly, an SCA solution should offer key Common Weakness Enumeration (CWE) classifications—a list of software or hardware weaknesses that have security ramifications—for all vulnerabilities, providing insight into the type of weakness being exposed. A CWE classification tells developers which type of weakness leads to the vulnerability in question.

    Information such as this can help you understand what you’re dealing with and aids in assessing the severity of the vulnerability for mitigation purposes. For example, a development team may prioritize a SQL injection differently than a buffer overflow or denial of service.

  • 3 Ways IoT Developers Can Make Their Applications More Secure

    3 Ways IoT Developers Can Make Their Applications More Secure

    When the IoT was still young, IoT application developers got away with making security an afterthought, as they built prototypes and minimum viable products designed to demonstrate the different ways the IoT could be used to transform the way we work, play and live. But the IoT has matured and grown to the point where today, Gartner estimates there were 8.4 billion connected things in 2017 and forecasts there will be 20.4 billion IoT devices deployed by 2020. With this growth has come a massive increase in number and sophistication of IoT security attacks, and the need for developers to make security not just a priority, but a top priority.

    As the IoT hacks of Trendnet’s SecurView camera, St. Jude’s cardiac device and the Jeep Cherokee have demonstrated, when security is not a top priority, successful IoT attacks can cause significant real-world financial, reputational and even human damage.

    While it is impossible to make IoT applications (or any type of software) 100% secure, there are several best practices that IoT application developers can adopt to strengthen the security of their IoT applications. These best practices include:

    1. Following a set of approved cryptographic standards when building applications.
    2. Using static code analysis programs that analyze application code to identify common coding mistakes that can lead to security vulnerabilities.
    3. Instituting a vulnerability management strategy that identifies and repairs known vulnerabilities in IoT applications on a scheduled, ongoing basis.

    These three best practices will not make IoT applications perfectly protected from malicious actors. However, they can significantly reduce an IoT application’s vulnerabilities and attack surface, making it much less likely a developer’s applications will be breached, generating angry customers and negative headlines.

    Follow Approved Cryptographic Standards

    Most developers understand that, if they hope to keep IoT data safe, they should encrypt this data, especially while it is in transit from device to cloud or vice versa. Yet, faced with tight development deadlines, as well as the need to make the most of their IoT devices’ limited bandwidth and processing capabilities, some developers choose to not encrypt their data or use weak cryptographic algorithms that promise to be faster or more lightweight than others but do not provide proper levels of security.

    Experience shows taking encryption shortcuts can result in customers’ data being stolen, an application disabled or other problems. For this reason, developers need to work closely with their security teams to encrypt IoT application data appropriately, following standards and guidelines approved by internationally recognized experts such as the National Institute of Standards and Technology (NIST).

    Choosing to use such approved standards does not have a major impact on IoT application development time, performance or functionality. NIST provides developers with guidelines on how to streamline integration of encryption standards into their applications. They also offer many different standards to choose from, so developers can find one that will provide their application with an appropriate level of security without sacrificing too much in terms of performance or functionality. Yes, it does require some additional work and effort, but if IoT developers want to make security a top priority, they need to make sure they are following approved cryptographic standards.

    Use Static Code Analysis Programs

    Many developers are familiar with static code analysis programs and their ability to discover common coding errors that can lead to bugs that affect software quality. However, these programs also can identify unsafe coding practices such as the use of improperly terminated strings, pointers to freed memory and buffer indexes allowed to go past the end of the buffer. These common coding mistakes create security vulnerabilities malicious actors can exploit in otherwise functional applications.

    There are a variety of static code analysis tools available, both proprietary and open source that developers can use to alert them to coding errors that could create security vulnerabilities. Developers should research which ones best support their security and other code analysis needs, and then ensure that throughout the application development processes—and especially before deploying an application—they use these static code analysis programs to discover any coding errors that might lead to a security breach down the road.

    Again, many developers might be tempted to skip this step, since the problems revealed by the program might prevent them from deploying and commercializing an otherwise functional application as fast as they would like. But, as the examples of IoT application hacks mentioned above demonstrate, cutting corners with security can often result in major problems down the road. If developers are dedicated to delivering their customers IoT applications with robust security, they need to commit themselves to using static code analysis programs to fix coding errors that might make their applications vulnerable to cyberattacks.

    Monitor For and Repair Known Vulnerabilities

    The media pays a lot of attention to so-called zero-day vulnerabilities—those that a software vendor has no prior knowledge about. However, the low-hanging fruit for most attackers is the ever-growing number of known vulnerabilities present in the millions of software components used in IoT applications that haven’t been fixed, either because the user of the component is unaware of the vulnerability or because they have not taken action to update their application to repair the vulnerability.

    All IoT application developers should be aware of the known vulnerabilities their applications might have as result of incorporating third-party software components into their applications, be they open source components (such as a Linux operating systems and associated software) or proprietary components. However, keeping up to date on all the known vulnerabilities in an IoT application’s device firmware, operating system and other third-party software components is not simple. The enterprises that have built these software components, government agencies and other watchdogs often identify as many as 1,000 different vulnerabilities in these types of software components per month.

    Fortunately, there are resources that can help developers stay up-to-date on new known vulnerabilities. For example, the National Vulnerability Database (NVD) is a public resource operated by NIST that catalogues known vulnerabilities in all types of software components, both proprietary and open source. To ensure their IoT applications do not have any known vulnerabilities, IoT developers can compile a security bill of materials (BOM) for their IoT application—a list of all the software components and versions used in the application—and then monitor the NVD for new known vulnerabilities with these components. Alternatively, there are a number of proprietary and open source tools that leverage free APIs to query the NVD database and then scan applications for vulnerabilities either by evaluating their components’ codebases or by discerning versions of exposed services (such as DNS, HTTP/S, NTP, SSH) on network interfaces.

    However, simply being aware of known vulnerabilities does not fix those vulnerabilities. Which is why developers need to not just check for new known vulnerabilities on an ongoing basis, but also have a plan to regularly repair new known vulnerabilities with security updates. Ideally such a plan should allow these updates to be performed remotely (over the air) and automatically. Today, many consumer IoT applications already include an option to enable remote, automatic updates. The commercial IoT applications built by many developers sometimes need more coordination to enable such remote, automatic updates—but this should be the goal. In any event, even if the updates can’t be done remotely or automatically, it is essential that IoT developers have some sort of plan to deploy security updates for known vulnerabilities in their applications in a timely fashion.

    Robust Security Will Enable Future Growth of IoT

    IoT is at an important inflection point. The market continues to rapidly expand, with exciting new agricultural, supply chain, industrial, public safety, consumer and other IoT applications being launched every day. Yet, additional high-profile IoT application breaches could threaten the tentative level of trust businesses and consumers have placed in the IoT, especially as it increasingly is used to collect sensitive data or complete critical tasks.

    To strengthen trust in IoT, developers need to dedicate themselves to making IoT security a top priority. Lip service is not enough–developers need to implement IoT security best practices, including the adoption of approved cryptographic standards, use of static code analysis programs to discover coding mistakes that can create security vulnerabilities and implementation of vulnerability management strategies that regularly identify and repair known vulnerabilities in their applications. If IoT developers make security a real top priority by implementing these and other IoT security best practices, the world’s trust in the IoT will grow and so will their business.

    — Larry LeBlanc

  • Black Duck Targets Open Source Code Security Flaws

    Black Duck Targets Open Source Code Security Flaws

    Open source platforms and projects offer a wide variety of benefits for organizations and developers, but they also can introduce vulnerabilities if you’re not careful. That’s why Black Duck has released Security Checker, a free tool based on its Hub open source security tool to help you identify those vulnerabilities so your applications will be secure.

    One of the advantages of open source is also a potential concern. Open source software has benefits from community cooperation and collaboration. More eyes and more hands contributing to the development allow for faster evolution and greater innovation. However, when all of the code is available to the public, and any developer can add or change the code, it also is an opportunity to introduce problems.

    While theoretically it is possible for a malicious developer to intentionally add vulnerabilities or exploits, the collaborative nature of open source projects actually makes it less likely. Any obvious attempt to insert malicious code would be detected and thwarted by other developers. The communal nature of open source development is not infallible, though, as evidenced by recent major revelations such as Heartbleed.

    Open source projects that are active and properly maintained address these issues fairly quickly. The problem, however, is that organizations and developers need to be able to easily determine whether their existing applications are affected and apply the appropriate patches and updates. There also are many open source tools that are not being actively developed or supported, which means known vulnerabilities may be left unfixed.

    Security Checker from Black Duck can help minimize exposure to these risks and give organizations and developers an opportunity to address any known issues. The tool is a drag-and-drop solution that allows you to scan code contained in an uploaded archive file, such as a .tar or .zip file, or in a Docker image. Security Checker then generates a report that shows identified vulnerabilities and security issues.

    A recent report from Black Duck found that 67 percent of audited applications contain known open source security vulnerabilities. More than a third of the vulnerabilities identified were classified as “severe.” The most notable finding, however, is that 10 percent of the applications surveyed still contain the Heartbleed vulnerability, which was discovered in April 2014.

    “Applications represent the greatest level of risk on the security threat landscape, and we expect that Security Checker scan results will provide an ‘a ha moment’ for many open source users,” said Black Duck CEO Lou Shipley in a press release statement. “Their findings will focus attention on the need to regularly review application code to ensure it’s free of known open source vulnerabilities.”

    The process of scanning and generating the report takes about 15 minutes, according to Black Duck, which also noted the maximum file size Security Checker can scan is 100MB.

  • Alert Logic Cloud Insight brings cloud-based security to your cloud infrastructure

    Alert Logic Cloud Insight brings cloud-based security to your cloud infrastructure

    One of the primary driving forces behind DevOps is its fluidity. There is a domino-effect that cascades from the developers who create the apps to the IT admins who deploy and administer the apps to the individuals who download and use the apps and back again. Traditional security can’t keep pace so Alert Logic created Cloud Insight—a cloud-native vulnerability and configuration management solution for cloud infrastructures running on Amazon Web Services (AWS).

    I’ve written previously about the continuous continuousness of DevOps. Anything and everything that used to be manual tasks on a static infrastructure is now automated to the Nth degree. “Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change.”

    All of that also means that it’s virtually impossible to keep up with the current configuration or accurately assess vulnerabilities in a constantly-changing environment. If your entire cloud infrastructure can change at the push of a button you also need to have security controls in place that are just as automated and capable of flowing with the changes and providing continuous, real-time security. Traditional security solutions simply won’t work.

    Alert Logic agrees, which is why it developed Cloud Insight. Gray Hall, CEO of Alert Logic, explained in a press release announcing Cloud Insight, “Managing security while maintaining the agility of the cloud is fundamentally different than in any other environment. With Alert Logic Cloud Insight we are delivering an innovative solution that gives businesses an added layer of visibility for workloads running on AWS—actionable intelligence to identify and eliminate risk across instances and applications while not slowing the business down.”

    Cloud Insight automatically tracks changes—additions, moves, deletions—within the AWS platform. It continuously identifies threats and vulnerabilities and potential exposure to risk within the dynamic environment. Alert Logic uses AWS APIs to integrate with the cloud infrastructure to detect any changes and inspect the new, change, or modified resources for vulnerabilities or configuration issues.

    Cloud Insight generates a prioritized list of remediation actions so the organization knows in real-time what’s broken and what the exposure to risk is and it can focus on addressing the issues and maintaining a strong security posture rather than spinning its wheels just trying to keep up with vulnerability assessments in a fluid environment.

    Terry Wise, VP of Worldwide Partner Ecosystem for AWS, said “Security-as-a-Service solutions built on AWS and designed to complement AWS-native security features enable customers to maintain the highest levels of protection while achieving the agility, elasticity, and cost savings of the AWS Cloud.”

    Alert Logic Cloud Insight is pre-approved to run on AWS. You can use Cloud Insight to conduct vulnerability scans and penetration testing within AWS without any additional permission. Cloud Insight also includes customer-facing APIs that can be used to integrate with other DevOps tools, and it can be integrated into your existing DevOps pipeline.

    Pricing for Alert Logic Cloud Insight is similar to the AWS pricing model. It functions on a pay-as-you-go basis based on the number of hosts or protected instances for a given day. Customers are billed $1 (USD) per instance per day. You can request a free trial of Alert Logic Cloud Insight to determine if it’s a good solution for your organization before taking the plunge.

  • Alert Logic lends more agile, cloud-native security to DevOps architects

    Alert Logic lends more agile, cloud-native security to DevOps architects

    Amid the avalanche of research and product news emerging from this year’s Black Hat USA 2015 conference, held in Las Vegas this week, at least one vendor is attempting to advance a new solution aimed at empowering DevOps architects to streamline and improve security workflow.

    Houston-based Alert Logic announced the release of its Cloud Insight solution on Tuesday, positioning the offering as a cloud-native vulnerability and configuration management package designed for customers running on Amazon Web Services (AWS). Cloud Insight promises to integrate with AWS native security features, providing an integrated view of potential host and application-level vulnerabilities.

    By empowering operational teams, including DevOps architects, to identify and move to remediate vulnerabilities before affected applications code is pushed into production, company officials claim, the solution promises to both improve the configuration of resulting infrastructure and remove obstacles related to traditional cloud security management.

    “This solution is specifically aimed at helping AWS users who are not security professionals, such as operations and DevOps teams who deploy the infrastructure, address inherent security issues,” said Rahul Bakshi, Senior Director of Product Management at Alert Logic.

    “When you think of rolling security into the existing model, typically it interrupts the notion of continuous deployment, as historically it hasn’t integrated via the application or plugged into automated orchestration systems, becoming a hindrance,” Bakshi said. “That’s where this approach introduces a significant advantage, allowing organizations to identify and fix high risk vulnerabilities before the code gets pushed to production.”

    Unlike traditional vulnerability management specialists, such as Qualys or Tenable Network Security, which require users to manually configure and review data and provide only a “partial” view of cloud platforms such as AWS, Alert Logic claims that Cloud Insight lends critical automation to involved processes and allows ops teams to gain far deeper visibility into AWS services level security.

    Alert Logic has already won some customers over with its ability to enable greater control over applications security in the cloud. Speaking at the annual AWS Summit, held in San Francisco in April, Colin Bodell, Chief Technology Officer at publishing giant Time Inc., highlighted some of the work his company has done leveraging the vendor’s existing Security-as-a-Service offerings.

    “AWS is great for physical security, or for network security, but when you’re building an application you need to own security of the application yourself,” Bodell said. “AWS doesn’t know how you’re building things and you can build them in any weird and whacky way that you like; Alert Logic has been an amazing partner.”

    In the recent report, “Market Overview: Cloud Workload Security Management Solutions – Automate or Die”, published in June, analysts at Forrester Research highlighted the specific need for new security methodologies that integrate and automate processes to stem potential DevOps bottlenecks.

    “One of the key benefits of DevOps is to enable continuous integration of code and continuous delivery of apps and infrastructure,” the Forrester report notes. “To keep up, [security and risk management] pros must make security processes more embedded, faster, and more continuous – otherwise, security will slow down code release.”

    In terms of bringing Cloud Insight – which exists as a solution, rather than a SaaS service offering – to market, Alert Logic claims that it is successfully appealing to organizations’ hopes to embed AWS vulnerability management further within operations, despite introducing an altogether new and unfamiliar approach.

    “Beta customers seem very positive as we’re reducing the security workload and time related to remediation handoff for cloud architects,” Bakshi said. “There’s always a continuum for education, but with the culture of responsibility [for AWS security] evolving, we think that we’re meeting demand at just the right place.”

    Dan Raywood, Analyst at 451 Research, said that Alert Logic could take advantage of related demand by leveraging the combination of its existing cloud security expertise along with capabilities added via its January 2015 acquisition of Critical Watch.

    “I think it’s a very interesting move for them as even though they did have something offering this‎ type of scanning previously; the acquisition of Critical Watch added the engine to do continuous scanning and change management,” said Raywood. “The major bugs of the last year have driven business to assess and respond immediately, and having something which tells you if you are vulnerable or not a few clicks away is a really useful tool for businesses.”

    About the Author/ Matt Hines

    matthinesMatt Hines has over 18 years as an IT marketing/communications professional at companies ranging from ground-floor startups to established industry leaders with emphasis on advancing broader understanding of key technology industry trends, market drivers, customer requirements and innovative products to highlight value, increase awareness and drive revenue growth. Additionally Matt has a decade-plus writing in IT journalism covering leading trends for a wide array of industry-leading business technology publications including eWeek, InfoWorld, CNet and TechTarget. You can reach him on LinkedIn