devopsy.kinsta.cloud

Tag: secure code

  • Massive Number of Transitive Dependencies Traced to Open Source Code

    Massive Number of Transitive Dependencies Traced to Open Source Code

    An analysis of nearly 2,000 software packages published by Endor Labs found 95% of all application vulnerabilities can be traced back to a transitive dependency created when a developer used an open source component.

    The study, conducted by the Station 9 research arm of Endor Labs, a provider of a platform for identifying software dependencies, concluded there’s still a 32% chance those software packages would have known vulnerabilities even after components are upgraded to the latest version.

    Endor Labs CEO Varun Badhwar said vulnerabilities often remain because the last update made to one of those software components may have been made several years ago even though there are existing known vulnerabilities that affect it. Development teams can’t assume the latest version of a software component is secure, he added.

    In general, functional dependencies are created whenever developers download a third-party component, he noted. The most important thing for any software development team to determine when assessing actual risk levels created by those dependences is determining how accessible any given vulnerability is to an attacker regardless of its severity score, noted Badhwar.

    In the wake of a series of high-profile breaches, there has been an increased focus on software supply chains. The challenge is most developers don’t have a lot of cybersecurity expertise. They often create patches for applications based on a list of potential vulnerabilities surfaced by cybersecurity teams. The issue, of course, is that just because there is a vulnerability it does not immediately follow that the affected software component can be externally accessed.

    Endor Labs is making a case for a graph-based platform that identifies dependencies between the software components that make up an application environment. That approach makes it simpler to prioritize remediation efforts based on the impact a vulnerability might actually have and narrows the current divide between cybersecurity teams and application developers. By the time cybersecurity teams alert developers to a vulnerability they often have moved on to other projects. As a result, developers often lack context because it may have been months since they last looked at the impacted code.

    Of course, the inclusion of DevSecOps best practices should improve the overall state of application security as more responsibility for it shifts left toward developers. However, achieving that goal will require more than just giving developers access to software composition analysis (SCA) tools that only surface vulnerabilities in source code as it is being developed, noted Badhwar.

    In the meantime, the efforts to remediate all existing application vulnerabilities will be measured in years, so organizations need to determine where to focus their efforts. After all, every minute spent developing and deploying patches is less time that can be allocated to building and deploying new code. The trouble is that as more new code is written, the number of vulnerabilities that could be exploited increases and makes a bad situation worse.

  • How Devs Can Improve Open Source Security in the Enterprise

    How Devs Can Improve Open Source Security in the Enterprise

    Modern applications are dynamic. They’re distributed and they’re often born in the cloud. These applications can be developed on the fly, spun up and scaled quickly to meet evolving user and market demands—enabling a level of business agility that allows users to make quick, informed decisions in real-time and take advantage of opportunities as they arise.

    Enabling this development velocity are tens of thousands of open source libraries–pieces of code that developers can include in their applications to perform a specific function without having to code it from scratch. Open source libraries prevent developers from having to reinvent the wheel and allow them to focus on their differentiated business logic. While efficient and a major time saver, open source software may be the biggest single threat to software supply chains today. Developers simply have too much faith in the integrity of free, open source code that they casually include and distribute with their applications.

    Despite the operational benefits, the pressure to develop quickly shouldn’t expose the organization to increased security risks. Development teams need to rethink how they use open source software and take steps to ensure they meet the same security standards as other enterprise applications.

    The Open Source Security Issue

    The problem is that most open source projects are maintained by a small number of developers that contribute their time and expertise to build software components that can be reused by the community at large. However, these developers are volunteers who aren’t being paid for their time and effort, nor are they under the same pressure as enterprise developers to ensure there are no vulnerabilities in their code. They may also lack the level of enterprise security expertise necessary to protect applications from increasingly sophisticated attacks. Some may even be hostile to efforts to better secure their code if it means slowing performance or changing the user experience.

    The result is that insecure code is increasingly making its way into enterprise applications that use these open source libraries. In fact, the Log4j vulnerability last year was due to a vulnerability in an open source Java logging library. Recognizing the national security importance of open source software, the Biden administration recently issued an executive order and met with cybersecurity professionals to better safeguard the federal government’s computer systems. The resulting recommendations included policies that would help prevent security vulnerabilities in open source packages, improve the process for identifying and fixing defects and reduce time to remediation for distributing and implementing fixes. 

    It’s imperative that the private sector take notice and make more of an industry-wide effort to secure open source software that makes up businesses’ most critical applications today.

    Three Steps for Better Open Source Security in the Enterprise

    The bottom line is that enterprises themselves need to take more responsibility for securing enterprise applications—especially as these applications rely more on open source libraries. They need to take a more proactive approach that spans the entire software life cycle, embeds security tools directly into development platforms and provides complete transparency into what makes up their most critical applications.

    Here are three things organizations can do to make sure their open source software is secure:

    1. Continuously conduct end-to-end application testing

    Modern applications are constantly evolving—making it more imperative than ever to continually test for vulnerabilities throughout the entire software life cycle. Starting with the planning stage, security should be embedded throughout the process—providing developers with a solid framework for building secure code before it goes through testing. Once pushed, application security testing should continue as an automatic, built-in step when pushing code to production. DevOps and security teams should work together to ensure security is no longer an afterthought to feature development.

    2. Embed enterprise security capabilities directly in development platforms

    Forcing developers to take an extra step to ensure secure code when they’re already under pressure to push code quickly is a recipe for failure. Security teams must make it as easy as possible by integrating security controls directly into existing development processes. Standardizing security testing and controls during development makes it more likely policies are recognized, understood and followed.

    3. Ensure transparency in every snippet of code you use

    Complexity is the enemy of good application security. DevOps teams need to know exactly what makes up their applications—including open source libraries and their dependencies. The federal government is pushing the open source community to standardize a software bill of materials (SBOM). Similar to regulations that require hardware manufacturers to know where every part is sourced, this would force both open source developers and enterprise developers to take more responsibility for the code they include from other sources. That way, if a vulnerability is discovered in a library, enterprises could easily determine if they are at risk and take appropriate action to fully mitigate the issue as quickly as possible.

    It’s Time to Take Greater Responsibility

    Open source software enables the kind of development agility that makes businesses thrive, but open source also greatly expands enterprise threat surfaces—leaving many organizations at risk of a breach. Organizations need to take greater responsibility for the security posture of the open source libraries they use to speed application development. This requires end-to-end application testing throughout the entire software development life cycle; embedded security tools and controls in development platforms and processes and complete transparency into the open source software that makes up critical enterprise applications. This proactive approach will ensure that vulnerabilities such as Log4j are identified and patched quickly before threat actors are able to exploit them and compromise applications.

  • GraphQL Vulnerability Analysis: The Top Threats

    GraphQL Vulnerability Analysis: The Top Threats

    Publicly available vulnerability data can be a goldmine for insights into how DevOps and DevSecOps teams can prioritize threats and improve security across the pipeline. With this in mind, Inigo recently performed a deep-dive analysis of known vulnerabilities affecting GraphQL components—including GraphQL clients such as Relay and GraphQL servers such as Apollo, Graphene, Ariadne, GitLab Enterprise, Magento and others. Our main data sources for this investigation were the MITRE CVE database and the HackerOne Hacktivity portal.

    Analysis and Findings From the MITRE CVE Database

    First, a few caveats about the MITRE CVE database. While it’s considered the source of truth for CVEs and the best data source available for understanding these vulnerabilities, it has its limits. Not every vulnerability gets reported, and not every reported vulnerability gets an assigned CVE identifier. Vulnerabilities generally receive a CVE identifier when an impacted software vendor or researcher recognizes a vulnerability and files a CVE request with MITRE. Large software vendors including GitLab, GitHub, Adobe and many more also serve as CVE Numbering Authority (CNA) partners, authorizing them to issue CVE identifiers themselves (often only for the scope of their own software). All this is to say that the MITRE CVE database is a strong data source for our analysis, but it shouldn’t be considered comprehensive.

    Inigo started its investigation by searching the MITRA CVE database for the term “GraphQL,” revealing 45 CVE records (at the time of the research) relevant to GraphQL clients, servers, and other components. Interestingly, the first tracked GraphQL vulnerability was CVE-2019-1000011 from 2019: Most likely not the first vulnerability ever discovered in GraphQL software, but the oldest available in this database.

    Researchers were curious to know which classes of GraphQL vulnerabilities were most common, and which GraphQL software has the most known CVEs. The following chart displays the results of the analysis answering the first question.

    Authorization bypass vulnerabilities are far and away the most common vulnerability class, and a majority representing 54.8% of all GraphQL vulnerabilities. At 16.7%, denial-of-service (DoS) vulnerabilities stand out as the second most common vulnerability class, followed by information disclosure (9.5%), code execution (7.1%), cross-site request forgery (CSRF) (7.1%) and injection (4.8%).

    Analysis into which GraphQL software has the most CVEs revealed the following:

    To be clear, these findings don’t necessarily speak to how hardened or how safe a particular GraphQL component is. Popular GraphQL servers simply draw more attention and have more eyeballs searching for vulnerabilities, whether they belong to attackers or security personnel. While this fact skews these results, viewing this data at a glance remains interesting.

    Analysis and Findings From the HackerOne Vulnerability Database

    The HackerOne Hacktivity portal offers a robust database resource that collects information on vulnerabilities as reported by researchers. The analysis looked at public reports of GraphQL vulnerabilities, finding 74 results since 2018.

    As the graph shows, identified GraphQL vulnerabilities fell mostly into the authorization class (87%), with DoS (7%) a far second and race condition and session management vulnerabilities each coming in at 2.8%.

    Bug bounties offer an interesting and likely influential factor here. Over the 2018-2022 timeframe, bug bounties granted for these vulnerabilities ranged from $250 to more than $20,000. At the same time, authorization vulnerabilities carry a high risk to sensitive data such as personally identifiable information (PII). This drives organizations to place premium bounties on these authorization flaws and motivates security researchers to focus on earning those prizes. Therefore, white-hat hackers will naturally test for authorization flaws first, perhaps leading to their overrepresentation in the data. It’s also important to note that bug bounty programs tend to prohibit testing for DoS vulnerabilities for obvious reasons, possibly reducing their representation here.

    Open-Eyed GraphQL Security

    For developers, DevOps and security teams tasked with safeguarding GraphQL deployments, the first step is knowing what you’re up against. The findings above should serve as an eye-opener that helps teams to prioritize threats, whether they be authorization, DoS and other classes of GraphQL vulnerabilities. As more and more organizations rush into GraphQL (increasingly migrating from REST APIs), security cannot be put on the back burner. There’s too much at stake, and ensuring the security of GraphQL deployments isn’t nearly as difficult or time-consuming as many teams currently think.

  • Cisco Adds Open Source Tool to Validate Serverless Functions

    Cisco Adds Open Source Tool to Validate Serverless Functions

    Cisco has launched an open source project, dubbed FunctionClarity, that makes it possible to verify signatures before code is deployed in a serverless computing environment.

    Vijoy Pandey, vice president of emerging technologies and incubation at Cisco, said that one of the application security issues that has emerged in serverless computing environments is the lack of validation capability to verify code signatures prior to deployment. As more organizations employ serverless computing frameworks, the overall software supply chain becomes less secure, he noted.

    FunctionClarity includes a command line interface (CLI) tool to invoke a verification function that can be deployed on the Amazon Lambda serverless platform to address that issue; support for Microsoft Azure and Google Cloud serverless platforms is planned, he added.

    The FunctionClarity project aims to close that gap by employing either a keyless approach using open source sigstore tools or a traditional encryption key, noted Pandey.

    The FunctionClarity project is the latest extension of a Cisco OpenClarity initiative that includes an existing project for securing application programming interfaces (APIs) using a service mesh, dubbed APIClarity, and a tool for detecting and managing software bills of materials (SBOMs) and vulnerabilities in container images and filesystems dubbed KubeClarity. All three projects are part of an ongoing Cisco effort to contribute code to the open source community that, while essential, does not provide a lot of differentiated value for any one vendor, said Pandey.

    The FunctionClarity project arrives at a time when concerns over the security of software supply chains is on the rise. Many of the software security issues that organizations are encountering stem from the simple fact that developers can provision cloud infrastructure without any kind of meaningful cybersecurity review. Code signing, within the context of a larger set of DevSecOps workflows, is now starting to gain traction to better ensure secure software supply chains. The challenge is that as more code winds up running on serverless computing platforms, a need to extend the reach of whatever approach to code signing an organization adopts becomes more evident.

    In general, the open source community is collectively trying to respond to an executive order issued by the Biden administration that required federal agencies to implement a series of steps to better secure their software supply chains. One of those measures includes wider adoption of code signatures to ensure the authenticity of code being incorporated into applications. The challenge is that incorporating code signatures into DevOps workflows has historically not been a trivial process to implement. Most recently, a free sigstore cloud service launched that promised to make it easier to achieve that goal.

    It’s not clear how widely or even how rapidly code signing will be adopted, but enterprise IT organizations are paying close attention to how federal agencies are responding to the executive order. Many of the tools and processes defined by those agencies will inevitably be copied by enterprise IT organizations that have thus far made limited use of code signing to verify the authenticity of software components. The challenge now is finding a way to achieve that goal without slowing down the rate at which modern software is developed.

  • GraphQL: Security by Obscurity Just Isn’t Enough

    GraphQL: Security by Obscurity Just Isn’t Enough

    The debate about how to secure GraphQL rages on. Many organizations are hesitant to adopt GraphQL for public-facing APIs as there is no precise method to handle authorization concerns as of yet. Without a role-based access layer to enable fine-grained permissions for each field (and underlying services that GraphQL might wrap), the query language can be prone to access control issues.

    One method to hamper GraphQL access is to turn off introspection features altogether. Some may assume that hackers can’t perform introspection on an endpoint if it’s not visible. But this isn’t entirely true—even though an “internal” endpoint may not be fully documented, any endpoint on the public web can be searched and introspected quite easily by brute-forcing queries or through field suggestions.

    I recently met with Karim Rustom, cybersecurity engineer, Escape Technologies. According to Rustom, “making something obscure isn’t enough to make it secure.” Leveraging a single slip-up in access control could be used as a doorway into these systems. Although it’s a best practice to limit introspection, it’s likely not enough to protect production GraphQL endpoints, he said. Below, we’ll consider some common GraphQL threats and alternative solutions to retain a safe GraphQL implementation.

    Common GraphQL Threats

    Having run thousands of scans on production GraphQL endpoints, Rustom found common trends emerge around GraphQL threats. First, he noticed the potential for denial-of-service attacks to be quite high. GraphQL, by design, is intended to query whatever data the client requires. But sometimes, these queries can return a mountain of data.

    If GraphQL owners don’t place a limit on what can be requested in a single query, the platform can easily fall victim to denial-of-service attacks and service interruptions. And limits aren’t only necessary for bulk read-only operations—although GraphQL is primarily used for fetching data, some methods might initiate intense server-side processing, which should be limited in some form. According to Rustom, such data manipulation methods are especially pervasive in FinTech, food delivery or health care-related applications.

    Another rampant GraphQL threat lies in access control issues. This comes as little surprise, as access control is ranked as OWASP’s most common web application security risk. Often, when creating new objects or new queries, a developer might forget to add the correct authorization, said Rustom. This can become a huge problem and lead to privilege escalation.

    Finally, too many production GraphQL implementations rely on security by obscurity. “Folks think that disabling introspection is a layer of security—we highly stress that it’s not,” said Rustom. He recalled performing penetration testing for a certain client; even though they had disabled introspection, the team was able to fetch ample open paths and discover an unsecured doorway to divulge secret internal knowledge.

    Solutions and Best Practices

    To avoid some of the vulnerabilities presented above, it’s recommended to first place request limits on overly complex GraphQL calls to prevent denial-of-service attacks. One nuance here that Rustom recommended is to consider request complexity—not in terms of the query size, but the overall processing required. He suggested assigning scores for every query and permutation to help inform the decision about whether or not to process the incoming call.

    Furthermore, it’s recommended to disable field suggestions as the feature could be prone to abuse. Using field suggestions, hackers can leak a lot of information to build a partial or complete introspection. These tactics are similar to the word-busting techniques black hats use to perform introspection on REST endpoints.

    Although it’s a good practice to limit the possibility of surveillance, hackers can still discover systems and leverage other common vulnerabilities like broken access control. Rustom suggested other tactics, such as luring attackers into a honeypot or logging them into a fake account. Or, creating error messages that are intentionally misleading for a attacker.

    To retain a safe GraphQL implementation, organizations can use pre-made free and open source tools to audit their surface area and scan for known vulnerabilities. For example, GraphQL.security quickly scans your GraphQL URL endpoint to discover vulnerabilities. Or, Graphinder can examine a subdomain to discover GraphQL endpoints, which could aid auditing purposes. There’s also middleware that wraps a GraphQL service with additional security, such as GraphQL Armor and GraphQL Shield.

    Future of GraphQL in the Market

    There appear to be many flavors of GraphQL throughout the market. We’ve seen it emerge as a mechanism to power backend microservices. We’ve also witnessed the technology adopted as a layer to centralize multiple REST services with a more usable data retrieval mechanism for frontend engineers. Some GraphQL endpoints also run on the public web to serve end clients and external partners.

    “GraphQL is a beautiful technology, just lacking in security,” said Rustom. And unfortunately, his outlook for API security looks grim—amid political turmoil and economic instabilities in regions like Europe, some companies may seek to cut cybersecurity investments to stay lean. For companies that haven’t yet suffered a breach, security is easy to ditch to slim budgets, but it should remain a priority, said Rustom. “Keep securing GraphQL.”

  • Federal Agencies Share DevSecOps Guidelines

    Federal Agencies Share DevSecOps Guidelines

    The National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), and the Office of the Director of National Intelligence (ODNI) have published a set of DevSecOps best practices based on the Enduring Security Framework (ESF).

    Developed by a public-private cross-sector working group led by NSA and CISA, the ESF framework was created in the wake of the breach of the SolarWinds software supply chain that led to malware being distributed downstream to a number of organizations that relied on the company’s IT management platform.

    The Securing the Software Supply Chain for Developers set of best practices published by NSA, CISA and ODNI takes the ESF a step further. The guidance walks organizations through the processes required to develop secure code, verify third-party components, harden build environments and deliver code.

    The best practices provided are the latest dividend of an executive order issued by the Biden administration that requires every federal agency to review the security of its software supply chains. The expectation is that enterprise IT organizations will conduct similar reviews using the best practices and frameworks defined by the federal agencies that specialize in cybersecurity.

    The challenge, of course, is embedding those best practices within existing DevOps workflows. In theory, more responsibility for cybersecurity is shifting left toward application development teams. However, the level of cybersecurity expertise that exists today among application developers is limited at best. Cybersecurity was an elective in most developers’ training and education programs, so it should come as no surprise that few of them ever attended a cybersecurity class.

    There’s a clear need to improve cybersecurity training for developers, but the real work involves automating cybersecurity processes within the workflows managed by the tools developers employ to write code and the platforms that DevOps teams use to deploy applications, said Mitch Ashley, principal analyst for Techstrong Research, an arm of Techstrong Group that is also the parent company of devopsy.kinsta.cloud. “Security needs to be part of the toolchain, workflows and how the software is designed,” he said.

    Ideally, organizations should appoint a security champion that will work with development teams to consistently implement a set of DevSecOps best practices, added Ashley.

    Of course, the security champion doesn’t eliminate the need for cybersecurity professionals. Rather, it reduces the pressure when there is a chronic shortage of cybersecurity professionals. In the absence of any formal cybersecurity review during the application development process, it’s simply too easy for developers to inadvertently introduce malware into a software component or misconfigure a cloud infrastructure service. In either case, cybercriminals are increasingly finding it easier to compromise software supply chains at multiple points.

    It’s not clear how much the federal government’s guidance might impact the overall state of application security. However, one way or another the level of security scrutiny being applied to how applications are built and delivered is only going to increase in the months ahead. The challenge is finding a way to deliver secure code without necessarily slowing down the rate at which applications are currently being built and deployed.

  • How DevOps Teams Can Defend Against API Attacks

    How DevOps Teams Can Defend Against API Attacks

    Remember when ransomware was the main security threat that DevOps teams needed to worry about?

    Those days are over. Ransomware attacks are certainly still happening, but API security breaches—which increased by a whopping 600% in 2021—are now poised to become the top attack vector for threat actors, according to Gartner.

    That’s the bad news. The good news is that, in many respects, the security practices that DevOps teams already have in place to defend against ransomware can be repurposed to deliver API security, too—with a few tweaks.

    Keep reading for a look at the state of API security today, along with tips on expanding upon DevOps’ existing ransomware defense techniques to protect your APIs.

    The Preponderance of APIs

    Although it may seem surprising that APIs have suddenly become an attacker’s best friend, it’s actually not when you step back and think about how deeply dependent we’ve become on APIs over the past half-decade.

    APIs have been around for a long time. But until relatively recently, APIs were used mostly for specific types of applications, B2B or infrastructure integrations. It wasn’t until the pivot toward microservices and distributed architectures that internal (or east-west) APIs became the glue that holds application environments together and carries information (which is sometimes sensitive) between the components and micro-components of an application.

    As for external APIs, publishing public APIs has become a basic expectation for virtually any business with a software product—to the extent that there are now something like 22,000 public APIs out there as well as several orders of magnitude more internal APIs.

    The result is a world where APIs create potential attack vectors against virtually every application or service. It only makes sense, then, that the bad guys are increasingly focusing on exploiting APIs as a means of obtaining access to things you don’t want them to have.

    From Ransomware Protection to API Protection

    You might think that securing APIs requires fundamentally new security tools and practices. In reality, though, there are extensive parallels between mitigating ransomware risks and mitigating API security risks. And DevOps teams are a major line of defense against these.

    Here’s how to extend an anti-ransomware strategy to an anti-API-exploit strategy.

    Prevent Lateral Movement

    Like ransomware, which propagates from endpoint to endpoint laterally by exploiting flaws and vulnerabilities, API exploits also typically spread laterally across an environment.

    This means that even if you can’t prevent all API (or ransomware) attacks from breaching your perimeter, you can take steps to make it hard for breaches to expand. By detecting malicious activity inside your environment early on, you can stop lateral propagation of the threat before it leads to a largescale compromise.

    Focus on Data Security

    Ransomware attacks and API attacks are both focused on compromising the same crown jewel: Your data. Ransomware attackers want to hold that data for ransom. API attackers—such as those who stole sensitive information from compromised Peloton accounts, or others who breached LinkedIn’s API to scrape data about 700 million users—typically want to exfiltrate it, possibly to resell it or maybe just to harm your business’s reputation.

    Mitigating both ransomware risks and API security risks, therefore, boils down to securing your data. By enforcing strong access controls and segmentation over what both internal and public APIs can do, you mitigate the risk of data exfiltration due to API security breaches.

    Use Behavioral Security Models

    Investing all of your signature-based security controls in attack prevention doesn’t work well for either ransomware or API attacks, especially when they are zero-day or unknown attacks. While you certainly should do what you can to harden your environment, it’s impossible to guarantee that a breach won’t slip past your defenses.

    That’s why deploying behavior-based security models is key to protecting against both ransomware and API attacks. Behavioral security models detect anomalous activity inside an environment, such as unusual types of requests or strange request patterns. By modeling and baselining behaviors and detecting anomalies based on your model, you can prevent attacks from spreading once they are underway.

    Don’t Rely on Perimeter-Based Defenses

    Along similar lines, trying to protect the perimeter of your environment is not a surefire defense against either ransomware or API attacks. Instead, you need to distribute protections across all of your endpoints, applications, services and so on.

    Again, nothing will guarantee that attackers won’t get in. The success of your defense hinges, in large part, on your ability to make it hard for them to escalate their attack from a small-scale breach into one that impacts a wide array of resources.

    Look Beyond the Surface

    Ransomware and API attacks are similar in that both often involve attack methodologies designed to elude common security monitoring tools.

    For example, attackers might try to leverage ports 80 or 443 (the default HTTP/HTTPS ports), which will almost always be open on firewalls. It’s therefore imperative to avoid relying just on standard ports or on encryption to protect API traffic. Instead, you must look deep into the payload, then parse and understand the protocols. It is also important to monitor and collect data from multiple sources, then correlate and analyze them to a get a deeper understanding of what is actually going on within the environment.

    Conclusion

    To be sure, ransomware attacks and API security attacks are fundamentally different in some respects. They involve the exploitation of different protocols and the goals of attackers are usually a bit different.

    But in terms of how attackers operate, what they want to steal (your data) and the limitations of perimeter-based defenses, ransomware attacks and API attacks are actually pretty similar.

    That’s why developers and DevOps teams don’t need to rethink their entire security strategy to cope with the surge in API attacks. Instead, do what you’re already doing to protect against ransomware and use those techniques to help secure your APIs, too.

  • To Prevent Supply Chain Attacks, Build Secure Code

    To Prevent Supply Chain Attacks, Build Secure Code

    More than a year after the massive SolarWinds cyberattack, targeted companies continue to feel its ramifications in both reputation and financial cost. Moreover, the global software supply chain remains vulnerable to severe attacks, whether from a hostile nation-state like Russia–now increasingly in the cybersecurity spotlight due to fears of retaliation due to U.S. sanctions–or from any other cybercriminal party. 

    As long as the world continues to choose fast over secure, nothing is safe. No one knows how many potential backdoors the SolarWinds attack alone created, which could allow the persistent presence of malicious actors on a seemingly infinite number of networks; nor do we know when the next attack will happen with potentially more dire consequences. For example, six months after the discovery of the Log4j vulnerability and its associated patches, we know that networks and products all over the world remain unpatched, vulnerable and exploitable in all sorts of companies both big and small.

    This must change. And that change must start from the inside out; meaning programmers, developers and DevOps teams should start building code more securely in the first place. That also means that those who use cloud services, third-party black box software or the services of hub companies, whose networks connect both suppliers and customers, should better understand how code development affects security. This increased focus on the underlying technology itself will not completely prevent attacks, but it will reduce the number of attacks.

    There are signs that the industry is moving in this much-needed direction—or that there are at least more discussions about it. The White House recently hosted meetings with technology experts focused on this very topic. And this spring, the SEC announced that it may begin requiring some companies to report cyberattacks within four days and also provide details about their cybersecurity posture. This increased government attention is raising awareness and could also open the door to regulations, or at least universal best practices for coding protocols. But regardless of eventual, still-hypothetical regulation, developers—and cybersecurity professionals at hub companies—should give serious thought to the process they use to securely build their products. 

    Beyond Open Source Code

    Of course, an oft-recommended solution is to move to open source software (OSS). Although open source code is still vulnerable to attacks, the processes and practices involved in creating OSS code are transparent, which goes a long way toward crippling the ability of bad actors to conceal themselves. But such an approach will never work on a large scale in the private sector as there is no way to prevent programmers from simply copying others’ novel code, leaving no way to protect intellectual property among software developers.

    However, there are other steps that could be nearly as effective, including integrating security features and testing into development tools and processes. For example, making gray and black box penetration testing a routine part of the software production process would go a long way in helping find vulnerabilities in the code that outsiders could find and access. Ideally, developers could then also remedy or repair these vulnerabilities. Also, assessing security at every step of the development process could give crucial insights into vulnerabilities before they are discovered in the wild by malicious actors.

    Code-Signing and Scanning Innovations

    Implementing other methods to spot security flaws in code, including in open source code, would also help. Using innovations like code-signing would alert developers if any changes were made to the code before they use it, helping to spot hackers or backdoors before the code is implemented into the product. In addition, developing better source code scanning technology is important for flagging vulnerabilities. Developers should also undergo training focused on building a product with a secure life cycle and implementing security protocols for merging and accessing the product code; this could prevent cyberattacks from occurring as a result of a faulty (or nonexistent) SDLC process—the same way an electrical engineer couldn’t design a building electric plan without formal training and certification and participating in regular continuing education and recertification. 

    CISOs Need to Be Proactive

    CISOs and IT professionals also have an active role to play. They need to evaluate the security of their products’ underlying code , taking full advantage of the software bill of materials (SBOM), which lists all components of software (and that could soon be required by law) but that is only one side of it. This needs to be coupled with measures like code signing, scanning for flaws and keeping an updated list of components to spot newly-published weaknesses and vulnerabilities in libraries and frameworks. And it is increasingly important to make sure that contracts with software service providers specify they are adhering to secure development practices. 

    With the world on high alert and the private sector especially vulnerable to state-sponsored cyberattacks, there has never been a better time to focus on building more secure code. This does not mean that all of the other aspects of cybersecurity—including  threat intelligence, incident response plans and hiring and retaining talented professionals—will be any less important. But if the code underlying the software can itself become more secure, these attacks could become fewer in number and their damage less far-reaching. 

  • Security Compass Makes Visualizing AppSec Threats Simpler

    Security Compass Makes Visualizing AppSec Threats Simpler

    Security Compass this week updated its threat modeling platform for developers to make it easier to surface application security issues.

    The latest version of SD Elements 2022 adds support for developer-centric threat modeling diagrams, reusable components, more advanced reporting capabilities and 114 more just-in-time training (JITT) modules. In addition, Security Compass has now integrated its platform with the Black Duck software composition analysis (SCA) tool.

    Drew Koelemay, director of product management for Security Compass, said the goal is to make it easier for application development and cybersecurity teams to collaborate using a platform that visualizes cybersecurity threats within a DevOps workflow.

    That approach to application security is critical because it becomes easier for developers to understand how changes to applications improve the overall cybersecurity posture of complex app environments where there are lots of dependencies, he said.

    Once that visualization is achieved it then becomes possible to create reports highlighting the most prevalent threats and weaknesses across that portfolio, Koelemay noted.

    In the wake of a series of high-profile application breaches, organizations of all sizes are looking to better secure their software supply chains by implementing DevSecOps best practices. The issue that immediately arises is the cultural divide between application development teams and cybersecurity professionals. The Security Compass platform surfaces developer-centric visualizations of security issues to help bridge the historic divide that exists between those teams, said Koelemay.

    For the most part, cybersecurity professionals view development teams’ lack of cybersecurity expertise to be the root cause of many of the issues they encounter. It’s not that a developer deliberately sets out to build and deploy vulnerable applications. By the time the application is reviewed—often just a few days before it’s supposed to be deployed—it’s often too late to do much about most of the vulnerabilities that are discovered. Cybersecurity professionals and application development teams need to meaningfully engage each other much earlier in the application development life cycle.

    The simple truth is developers are not likely to reach out first simply because they don’t know what cybersecurity issues to look for in an application environment. Most of the time they are rushing to meet an application delivery deadline, which makes them perceive cybersecurity as a hurdle to overcome rather than an automated process integrated within their workflow. Cybersecurity professionals, therefore, need to find a way to more constructively engage developers. The onus is on cybersecurity teams to insert themselves at the front end of the application development process rather than waiting at the backend for an inevitable issue to arise.

    One way or another, application security is going to improve. The only thing yet to be determined is how painful the process will be. Tools that enable DevOps teams to see for themselves what issues are being encountered should go a long way toward reducing both the level of pain being experienced and the amount of time required to resolve the cybersecurity issue at hand.

  • Chip-to-Cloud IoT: A Step Toward Web3

    Chip-to-Cloud IoT: A Step Toward Web3

    During the first six months of 2021, IoT devices were breached 1.51 billion times, a significant increase from only 639 million breaches observed for the entirety of 2020. This problem can be attributed to the widespread adoption of the internet-of-things (IoT) and the Windows Server Message Block (SMB), and neither can be avoided in the age of remote work. 

    But while these technologies offer unprecedented levels of data mobility and oversight for many interconnected digital and physical systems in industrial settings, they also make it easier for malicious actors to penetrate the very fabric of our lives if left unsecured. 

    This makes it all the more important for DevOps teams and developers to prioritize cybersecurity while creating systems for the IoT. It is important to address the inherent flaws in security like easily-breakable usernames and passwords or saving data without protection on remote access servers. 

    There is a way developers and DevOps professionals can help curb the increasing instances of cybercrime, and it’s called chip-to-cloud IoT. Let’s explore how it is emerging as a viable way to construct a safer, more valuable and more decentralized system for everyone.

    IoT: Understanding the Inherent Security Challenges

    It’s best to investigate potential cybersecurity issues that may befall your organization before finding ways to secure your IoT platforms with solutions such as a shift left security approach (meaning security is embedded in the earliest phases of the application development process) or an IoT decentralization approach, as we’ll expand on below. 

    Some common security concerns include:

    Vulnerabilities in the Software and the Firmware

    It can be challenging to guarantee the safety of IoT systems because of the following security flaws:

    • Lack of computational capacity to provide adequate built-in security
    • Inefficient access control in IoT systems
    • Insufficient funds for adequately testing and further developing the firmware’s security
    • Lack of regular patching and upgrades as a result of IoT devices’ technical and budgetary restrictions
    • Unpatchable vulnerabilities because users don’t regularly update their gadgets
    • Older devices may not be compatible with newer software updates
    • Easy accessibility means attackers could insert corrupted chips or hack via radio waves

    Possibility of Cloud Breaches

    Hackers can gain access to the data processed by your IoT system by intercepting unencrypted messages. 

    Your device might contain sensitive information such as your location, bank account information and medical records. Attackers can access critical information in many other ways, including by exploiting weakly protected communications.

    Even if every piece of data is transported to cloud storage, intruders can potentially target cloud-hosted applications. Therefore, the risk of data leaks is not just from the devices themselves but also from the cloud environments to which they are connected. That is why DevOps pros, developers and software engineers must find ways to protect the technology from the start and prevent hackers from breaching the cloud.

    Risks of Malware

    A recent survey by Zscaler revealed that smart TVs, set-top boxes and smartwatches are most susceptible to malware attacks. 

    If attackers successfully infiltrate an IoT system or insert malware, they may be able to change its functionality, acquire personal data and carry out other malicious activities that can endanger device owners and users. 

    The trouble is that manufacturers struggle to maintain proper software security to keep their devices safe. Security often takes a backseat when these gadgets are built, leaving buyers to deal with the aftermath if they get infected with malware. 

    How Chip-to-Cloud IoT Minimizes Security Risk

    There are two ways for organizations to enhance their IoT security. 

    The first step is ensuring both device manufacturers and software developers adhere to sound security principles. If the value chain is exposed, the solution must be chip-to-cloud. 

    Second, they must take an in-depth approach to protecting key technology by layering security controls to create an iron-clad IoT infrastructure.

    The chip-to-cloud architecture enables the creation of secure, low-energy networks of IoT devices that can communicate directly with cloud hosting platforms. The collective effort to build a cloud-first technology stack has been costly, inefficient and unreliable.

    Traditionally, IT professionals have used non-machine-hosted security tools like firewalls to secure IoT devices. Chip-to-cloud architecture aims to fix this underlying flaw.

    Features of Chip-to-Cloud IoT

    Onboard security and computational power are two of the most significant shortcomings of IoT devices. In addition to being more powerful and safe than previous models, IoT devices built with chip-to-cloud security are also more energy-efficient.

    Here are the features that make the chip-to-cloud technology so effective:

    • An onboard cryptography engine
    • Generator of random numbers
    • Sufficient random-access memory (RAM)

    How It Works

    Reliable software design is essential for IoT devices and other internet-connected devices. It keeps hackers from stealing your identification or duplicating your device for their ulterior motives. Chip-to-cloud delivers on all fronts. 

    These chipset characteristics confer an extra security advantage. Each IoT node is cryptographically unique, making it nearly impossible for a hacker to impersonate it and access the more extensive corporate network to which it is connected. Chip-to-cloud speeds things up by eliminating the need for traffic delays between the logic program and the edge nodes that are ready to take action on the information.

    The chip-to-cloud architecture of the internet-of-things is secure by design. New tools are being developed to provide bespoke and older equipment with data mobility capabilities, just like the current IoT. 

    Nevertheless, chip-to-cloud chipsets are always connected to the cloud. As a result, the availability of assets and the speed of digital communication across nodes, departments and facilities will be significantly improved. Chip-to-cloud IoT is a significant step forward in the evolution of the IoT toward Web3. Experts predict IoT device customers and value producers will benefit more from these design principles than centralized providers.

    Chip-to-Cloud Enables IoT Decentralization

    The traditional approach to IoT is to cover an already-existing cloud of linked devices with third-party firewalls and other security measures. Its equivalent imagery would be a single umbrella covering a family of 12—or at least attempting to do so. The protocols that govern security must be central to decentralization.

    Chip-to-cloud IoT is a powerful, uniquely secured chipset that can be installed inside each device, giving it a far greater connection in the IoT chain than the average IoT gadget.

    The cloud manager or analytics application receives data from every node in real-time using the chip-to-cloud technology. The process does not add another layer of protection; instead, it reduces the latency and loss of data packets as they travel from one destination to another.

    The Future of IoT

    In the wake of recent global events, general cloud technology and chip-to-cloud architecture are receiving huge investments. IoT can supply the data that companies and organizations need to fuel their client engagement portals, machine maintenance platforms and enterprise planning tools.

    That said, the internet-of-things will not be entirely safe even with chip-to-cloud technology. Businesses must have a security-focused culture, standards for managing new IT investments and the expertise to pick the best technology partners.

    The Web3 transition will likely be coupled with future Web3 innovations such as blockchain to improve its utility and security. Seeing how the world’s genuine value-creators use these new solid tools will be intriguing.

    Conclusion

    Considering security at the very onset of any IoT project is critical. Maintaining comprehensive cybersecurity in IoT environments is challenging due to the rising frequency of cyberattacks and increasingly complicated system vulnerabilities. 

    The safety of IoT devices is essential to the operation of many businesses—and even entire economies. Engineers are under increasing pressure to ensure that the rapidly expanding number of interconnected devices is safe. This is why chip-to-cloud technology is poised to become the next big thing in this field. Are you ready to be the change?