devopsy.kinsta.cloud

Tag: app security

  • What is DevSecOps?

    What is DevSecOps?

    While traditional development practices have long separated security and compliance, DevSecOps as a series of best practices integrates security into every phase of the DevOps software development life cycle. DevSecOps introduces and automates security in the earlier phases of the software development life cycle rather than bolting it on at the end. The approach saves money, saves time on tedious manual tasks, helps organizations meet regulatory compliance requirements and significantly reduces the risk of critical security bugs being found after an application’s final build. DevSecOps promotes the use of, for example, active penetration testing, security audits and other security tools within an agile development process.

    The goal of DevSecOps is to create a collaborative environment between developers and security professionals that enables organizations to build secure code faster and more easily. By emphasizing security from the very beginning of the process, it becomes a priority in the app dev process rather than an afterthought. Over time, developers become more familiar with the common weaknesses in software that today result in more insecure applications being deployed than most anyone really wants to admit. The end goal is to create secure applications by making it easier for developers, security experts and operations professionals to collaborate throughout every stage of application development.

    Minimizing Application Vulnerabilities

    It may seem tedious and expensive to integrate security into the development process, but it’s become essential for organizations to embrace DevSecOps to minimize the number of application vulnerabilities that cybercriminals might exploit. When applied throughout the development process, scanning and reporting can take place within a matter of minutes rather than holding up deployment at the end of the process to review the entirety of an application.

    Leaving security to either the end of the application development process or, worse yet, after an application has been deployed only increases the total cost of ownership. It’s much more expensive to remediate a vulnerability after an application has been deployed than it is to address an issue during the application development process.

    Implementing DevSecOps requires organizations to set up workflows that are managed via a continuous integration/continuous delivery (CI/CD) platform. Most critically, developers must understand the role security plays in enabling organizations to identify vulnerabilities as early as possible in the application development life cycle.

    Inserting security audits and penetration testing into the development process, for example, helps ensure the security of an application. When changes are made in a project, scanning, architecture reviews and penetration testing can be triggered within the development flow to save time and resources.

    DevSecOps Adoption

    However, there are many technical and cultural challenges ranging from tool integration to a lack of trust between developers and security teams that can impede the adoption of DevSecOps. Security professionals are tasked with identifying and preventing vulnerabilities in applications. Acceptance test criteria, user designs and threat models should be created by security professionals. The development team then needs to define a code review system to ensure uniformity.

    Despite those concerns, the most important thing is to simply get started. Ideally, development and security teams should work together to create a safe application development and software development environment. There is no need to create separate teams or apply different policies.

    The biggest benefit of DevSecOps is that it eliminates silos between development and operations. As a result, software engineers integrate cybersecurity processes from the start of the development process. This includes ensuring that every component, configuration item, and installation process is securely patched and documented. This concept of shifting security to the left allows the security team to identify and remediate security threats early on.

    In the longer term, however, adopting DevSecOps best practices will ensure security remains a top priority in the wake of a series of high-profile cybersecurity breaches. In short, there is now more focus on DevSecOps with the goal of securing software supply chains.

  • Stopping Mobile Fraud With Automation and DevSecOps

    Stopping Mobile Fraud With Automation and DevSecOps

    Mobile fraud is a multibillion-dollar problem that’s only getting worse. One study showed that mobile click fraud alone rose 64% during the first few months of the COVID-19 pandemic. In fact, during the pandemic, about one in five mobile ad clicks were fraudulent. And that’s just one form of mobile fraud.

    Weaponized botnets, mobile malware, mobile Trojans and mobile cheat engines and dynamic instrumentation tool abuse—the methods that fraudsters use to defraud companies and consumers via mobile devices—are constantly expanding in number and scale. 

    Historically, organizations have fought against fraud through monitoring and data analysis. As transactions and data come in, analytics and AI work to discern legitimate events from fraudulent ones. These systems require training and a lot of data to become proficient at identifying fraud, and they can become very accurate. But fraudsters are always changing their tactics to evade these systems, and, as many of us have experienced, false positives are still a big problem. If you’ve travelled enough overseas, likely you’ve had your bank account or credit card frozen until you could call your financial institution to let them know that your purchases were genuine. 

    Another challenge with existing mobile fraud prevention solutions is that they are designed to protect networks and network resources first. As a result, while fraud is occurring and fraud prevention systems are learning, mobile end users are still being affected. Also, when a bad act is identified and a system enforces protections against fraud, these enforcement points typically block network traffic. That protects the network, but the consumer and their mobile app remain at risk. Once a fraudster compromises a mobile app, they may be able to attack through other vectors, even if one network is shut down. For instance, if a consumer unwittingly downloads and launches EventBot to their mobile device thinking it was a legitimate app, it may compromise multiple banking apps. If one bank shuts down its network after detecting fraud, EventBot may have other opportunities on the device.

    DevSecOps

    As this chart shows, once fraud takes place, damage to a brand, customers and the bottom line begins immediately. Even if it is detected and halted, the harm it has already caused can’t be undone. Mobile app publishers and developers need to stop mobile fraud where it starts, and that means implementing mobile fraud prevention inside the app within a DevSecOps framework. By blocking the technical methods used to carry out fraud via mobile apps, organizations can make massive inroads toward stopping fraud before it ever gets to the network level, preventing both customers and organizations from getting scammed.

    Why Traditional Security Approaches Don’t Work in Mobile Apps

    To achieve a multi-layered defense against fraud, a mobile app should include app shielding, anti-tampering, code obfuscation, data encryption (including strings, resources, preferences), jailbreak/rooting prevention and man-in-the-middle prevention (such as certificate pinning or certificate validation). Certainly, there are commercial SDKs and third-party libraries that can provide these functions, with some limitations. But these approaches typically still require extensive development work and introduce additional frameworks or programming language dependencies and incompatibilities. 

    They don’t solve the fundamental problem of implementing fraud prevention inside a mobile app—it’s too expensive and time-consuming.  The root of the problem rests in the way mobile apps are developed, released and updated in a modern agile organization. DevOps depends on processes that are dynamic, automated, agile, integrated, iterative and continuous. Mobile app security has traditionally been very different: Static with manual, line-by-line coding. This way of implementing manual security will never work in an agile delivery model.

    The promise of DevSecOps is built-in security, delivered as a fundamental part of a release process where security is designed into the process at each and every phase of the life cycle. The security model can be delivered and evolved atomically, iteratively and dynamically so that it adapts to fit the app.

    The future of fraud prevention lies in the mobile app, but to make this possible, the industry needs to apply AI and ML to automate fraud prevention and security implementation into mobile apps on time within an agile, fast-moving and iterative app life cycle and release process.

  • Organized Architecture

    Organized Architecture

    I’ve mentioned IT pendulums plenty of times before, but today I’m going to use them to explore a different angle on IT: The age of containers and microservices. It’s time to ask yourself if the current architectural design of the overall product offering of IT is the best one you can afford to offer.

    Agile and the whole “developer is king” movement brought us a whole lot of independent app teams running off and doing their own thing. While the core of that movement was short-lived, we got a lot of good and bad out of it. The good included breaking the traditional “We change at glacial rates” process that some IT shops had—because a team absolutely wants the tools that will make their job easier, not the ones pre-approved by committee or whatever process a given org used. And the bad included the very things those of us who’ve seen this type of thing play out before warned about. Suddenly, we had critical apps and infrastructure relying on tools that one dev used in his hobby development. Sometimes that was good, and for sure it happened before Agile came along, but now we had an avalanche of it. Stuff that hadn’t been through security; often code/libraries/apps that no one outside the team (or the individual) knew was running in the organization. Some of that stuff is still happening.

    And then we hit true uptake of microservices. That drove us to break things up in non-traditional ways. A lot of good came of that process, but a lot of complexity did, too. Complexity shared across applications with a huge spike in API calls and operations with a spike in deployed processes and routing. Perhaps the worst thing to come out of the combination of the two is “Who cares why it failed? Just spin up another!” That movement is mostly dead (thank goodness), but it only died because of the number of high-profile “Oops” issues that it caused. It allowed attackers to go unnoticed; it caused paying customers to spread security details across the web; it caused users to suffer crashes that would have been fixed in any sane development environment … and some of those are still out there. Cases where there’s a script to restart an app or service every X hours because it crashes randomly. Not acceptable. Make all the excuses you like, but if you don’t know what’s causing the crash, you’re wrong to leave the app or service running.

    And we introduced a huge amount of complexity. Now we have double the infrastructure—one physical, one virtual (container or cloud). We have applications spread across a lot more systems (be they instances or physical systems) and often across platforms; even across data centers. We live in a very cool time, with some sweet stuff going on. But complexity is a very real problem we need to solve. One app/app portfolio may have limited complexity, but we still allow teams too much leeway in defining the environment the application lives in. We need to offer a happy medium—a world where there are options, but those options are defined, manageable, and secure.

    So we’re likely to see a resurgence in the importance of enterprise architecture teams again, with their focus being on organizing the mess we’ve made. Indeed, I know this is underway in a couple of Fortune 500 companies I stay in touch with. And I know of one organization that isn’t doing this and has all their UI functionality running through a single container … for multiple applications. That is no better architecture than each using a completely different UI toolset. So, I expect they’ll want coordinated solutions also. Just so something like that can’t happen again.

    You all are doing it, day in and day out. As I often say, just don’t let this bit drag you down. Confront it head-on, approach standardization with “Yes, where it is good; no, where it is not” as your credo. Security is the big one, but maintainability is another. Even with tools like Ansible at their disposal, managing 50 different environments is a bit much for ops if it could be done with five. And keep rocking it. Through a pandemic, meeting increased demand, giving users more and more. Thanks once again, from all of those users who don’t know to thank you.

     

  • Dependencies in Cloud-Native Apps can Amplify Risks

    Dependencies in Cloud-Native Apps can Amplify Risks

    Hidden Dependencies in Cloud-Native Apps can Amplify Security Risks

    Cloud-native applications and modern development practices result in applications that are highly distributed and loosely coupled. In many cases, organizations have no control over or little insight into the different elements and software entities they use in their applications. The result often is hidden dependencies that can impact performance and add to security risks.

    The New York Times noted an example of the consequences of hidden dependencies. The article cited the work of researchers who observed that the quality of weather forecasting models declined as air travel dropped off during the pandemic. One might easily conjecture there was a physical cause and effect. Jet engine exhaust includes water vapor, soot, carbon dioxide, unburned fuel, and several oxides. Perhaps the diminished amounts of these particulates due to fewer commercial flights had some impact on lower stratospheric dynamics.

    It turns out that was not the case. The article reported that researchers found “that when a short-term forecasting model received less data on temperature, wind, and humidity from aircraft, the forecast skill (the difference between predicted meteorological conditions and what actually occurred) was worse.”

    Atmospheric observations made by instruments on commercial and cargo planes are “among the most important data used in forecasting models,” according to the article. The measurements are transmitted in real-time to forecasting organizations around the world, including the National Weather Service.

    The pandemic resulted in fewer flights. So, there was less or no data. A prediction’s degradation due to this data disruption not only impacted the primary forecasting application but had many downstream implications. For example, these short-term forecasts are used by many industries (logistics, agriculture, entertainment, public safety, and more) to make business decisions. Hence, the degradation of performance in that one application due to previously unknown dependencies could propagate to third-party apps that simply relied on the output of this one app as input for theirs. In a sense, this particular dependency (fewer observations leading to poorer quality forecasts) becomes yet a different hidden dependency in many other applications.

    Security implications

    As this example illustrates, small changes in complex systems can have unexpected application performance impacts. They also can impart unintended security problems.

    At the heart of the issue is the fact that today’s cloud-native applications are complex systems. And security in cloud-native systems can be impacted by small changes.

    It might be something as simple as reusing a component whose original permission setting gave a development team broad access to certain data for testing purposes only. With software component reuse being quite common, that point may be forgotten at some point, and the code might be made available to other groups. Those groups may just want anonymized records in that database or a subset of data that did not include records that should remain private. Use of that code in a larger cloud-native app for such purposes would not necessarily expose the data. But someone might discover the mistake later and exploit it.

    Another aspect of cloud-native application security is that many modular elements are linked together via APIs and microservice calls to form a larger application. Those software elements (be they open-source or commercial) often have security flaws.

    A report last year by the Laboratory for Innovation Science at Harvard and The Linux Foundation highlighted this issue, noting the need for an “understanding and addressing of the security complexities in the modern-day software supply chain.” With frequent reuse of components, even if a known vulnerability is taken care of with a patch, the problem may not be eliminated. Someone needs to know that piece of code is in a distributed cloud-native app, that there is a patch for the vulnerability, and that the patch was applied.

    Any small flaws like this can have a larger negative effect on the security of the entire cloud-native system.

    What’s needed

    The reliance on open source and third-party code in cloud-native applications requires that security be entrenched throughout an application’s lifecycle. It is no longer enough to test for vulnerabilities after the fact. Third-party or open-source code used in any one element of a larger application might be changed at any time. If a vulnerability is introduced, a developer might not know of it.

    The inter-dependent nature of discrete code working together in a vast cloud-native app thus requires a new take on security. The constant refreshing, updating, and replacement of applications dictate that security must be an integral part of the entire lifecycle of an application. As such, companies must bring security into the application lifecycle just as DevOps does for development and deployment.

    To find these impacts, stay ahead of them, and react effectively and efficiently when they show up, developers and companies need a deep understanding of the context of their systems and how all the parts work together. Just as the pandemic-related downturn in commercial flights impacted the accuracy of forecasting models, so to can a seemingly unrelated (or unknows) security flaw in one part of a cloud-native application impact the entire application.

    To avoid such problems, a DevSecOps approach is increasingly needed to find weaknesses and vulnerabilities due to hidden dependencies in today’s applications comprised of many interconnected parts.

  • Accurics Aligns DevSecOps Platform With GitLab

    Accurics Aligns DevSecOps Platform With GitLab

    Accurics today announced it has integrated its tool for discovering violations of security policies that occur when developers provision infrastructure as code with both the continuous integration and continuous delivery (CI/CD) platform and the static application security assessment testing (SAST) tools from GitLab.

    Om Moolchandani, chief information and security officer (CISO) and CTO for Accurics, said both integrations make it easier for developers to discover security issues earlier as part of a DevSecOps workflow using the company’s Terrascan tools.

    Many of the issues organizations are having with cloud security these days can be traced back to misconfigurations created by developers when configuring infrastructure using tools such as Terraform. Accurics created Terrascan to identify those misconfigurations.

    The integration with GitLab makes it easier to incorporate Terrascan into a DevOps workflow in a way that also aggregates data collected from both SAST and dynamic application security testing (DAST) tools, said Moolchandani. That approach effectively unifies what today are two separate cloud infrastructure and application development pipelines by enabling DevOps teams to employ threat scores to enforce security policies as code that are deemed too risky to deploy with block builds, he added.

    At the same time, the integration with SAST and DAST tools provides the context developers need to prioritize remediation efforts before applications are deployed in a production environment, noted Moolchandani.

    Organizations of all sizes are now trying to strike a balance between two conflicting agendas. On the one hand, infrastructure-as-code (IaC) tools such as Terraform have played a critical role in enabling developers to build and deploy applications faster. The issue is that developers lack the security expertise required to ensure infrastructure is secured properly at a time when cybercriminals are more aggressively seeking to compromise software supply chains. Organizations most likely won’t slow down the rate at which applications are being deployed to make sure software supply chains are not compromised. However, in the absence of best DevSecOps practices—which still are not widely implemented—there may be a backlash against shifting application responsibility left toward developers.

    The challenge that creates is most organizations don’t have enough security expertise available to review applications in a timely manner before they are deployed, which results in them hoping security issues will be discovered and remediated during the application update cycle before cybercriminals find a way to exploit a vulnerability.

    Of course, hope does not make for an application security strategy. Organizations will need to find ways to enable developers to better secure applications while simultaneously making it easier for cybersecurity teams to maintain a zero-trust IT environment that reduces the chances organizations will be breached via, for example, a phishing attack to steal developer credentials.

    Regardless of how DevSecOps workflows and zero-trust IT architectures are implemented, it’s clear organizations have run out of time to resolve longstanding security issues that are now making the kinds of headlines no one wants to see.

  • Is Low-Code Development a Security Risk?

    Is Low-Code Development a Security Risk?

    According to Gartner, the worldwide low-code development market is projected to be $13.8 billion in 2021, a whopping increase of 22.6% from 2020. Gartner also predicts that the surge in remote development during COVID-19  will continue to boost low-code adoption, despite budget cuts and efforts to optimize cost.

    Low-Code’s Popularity Among Professional and Citizen Developers

    Low-code is no longer the new kid on the block. From simple dashboards to complex applications, low-code applications are becoming more and more diverse, with mainstream adoption in the enterprise world. In essence, low-code is a visual paradigm of application development that involves drag-and-drop of pre-built components and integrations resulting in fast, easy and less-error-prone development.

    The advantage of low-code is that it enables users from a non-traditional development background to participate in the app development process, thus democratizing development and accelerating project timelines. It also narrows the demand-supply gap that arose as organizations catered to ever-rising digitization needs with limited resources and developer scarcity. Many low-code platforms make it easy for citizen developers (business analysts, line-of-business users, junior developers, for instance) to build applications while drastically reducing delivery time compared to traditional coding methods.

    But citizen developer productivity and speed are not the only benefits of low-code development. Today, low-code platforms also come with capabilities purpose-built for professional developers from enterprise IT teams to ISVs. These platforms are hardened for enterprise use, are able to leverage the scalability and security needs of a complex application and have integration capabilities mature enough to seamlessly fit in with existing tools and technologies. During the COVID-19 pandemic, many businesses reinvented themselves through adoption of low-code platforms and applications that helped them adapt to the sudden shift to a remote work scenario and enable the necessary modern application needs that came with it.

    Security Challenges with Low-Code and Remote Work

    Compared to traditional development, low-code involves a variety of personas working together to build applications while dealing with automatically generated code, ready-made components and built-in default configurations. This shift in environment revealed some unique challenges that need to be addressed. There are a few common security challenges with remote teams building on low-code.

    Application Development and Remote Team Collaboration

    • Lack of security awareness: Low-code users come from both business and tech backgrounds. Some practitioners aren’t familiar with application security best practices and lack awareness and understanding of potential vulnerabilities and security holes.
    • Platform access and admin controls: Low-code is deployed centrally and available for users across an enterprise via browser access. This introduces a risk of network intrusion; providing access to unauthorized developers and opening up greater permissions to users that do not need it when accessing the platform remotely.
    • Code repository and team collaboration: Low-code platforms must ensure that the automatically generated code can committed to enterprise-sanctioned repositories. This code access shouldn’t be misused, and ought to have sufficient protocols in place for code control and upgrades.

    Code Generation and DevSecOps Best Practices

    • Securing custom code: Low-code tools allow for writing custom code to extend and enforce platform coding guidelines and design patterns to protect sensitive data from unauthorized access.
    • Adhering to secure release practices: Integration with the existing enterprise CI/CD pipeline is important so that dev teams can extend the same release governance protocol to the auto-generated code before going to production.

    End User Application Access and Data Protection

    • Preventing malicious attacks: Today, both web and mobile apps are becoming constant targets for security breaches. Automatically generated code, and citizen developers working remotely, can make low-code applications more prone to vulnerabilities. Platforms should generate apps that are fully protected against phishing attacks, SQL injections, brute force attacks and DOS attacks.
    • Secure data and application access: Low-code platforms should provide a comprehensive access control mechanism preventing unauthorized access to data and app functionality. With remote teams accessing apps from anywhere, at any time and from any device, data breaches can be prevented with the right controls in place.

    Low-Code and Security – The Future of Development

    As enterprises and ISVs turn to low-code for more serious use cases, the larger question still remains. Can low-code platforms enable modern development teams to deliver applications faster, while still enabling a secure and tightly governed environment?
    The answer is, yes, they can! However, development teams must consider the following security checklist when considering low-code platforms:

    1. The chosen low-code platform must be set up within an enterprise secure DMZ or secure private cloud, and must effortlessly pass cybersecurity clearances.
    2. The platform must enforce best practices in programming (coding conventions, design patterns and data encryption) for automatically generated code as well as custom code written by the developer, facilitating easier integration with existing CI/CD processes and tools.
    3. The platform must offer full protection against the top 10 OWASP vulnerabilities for web and mobile apps, and have third-party certifications to guarantee code quality and security. Also, organizations should ensure that there are no vulnerabilities in their chosen platform’s binaries, as well as all third-party dependencies (including open source libraries) as listed in the CVE library.
    4. The solution must support multiple authentication providers (database, LDAP, AD, SSO, SAML, Open-ID, multifactor, biometric) to build applications with strong user security. For user authorization, ensure support for both coarse-grained as well as fine-grained access control policies to protect various aspects of the application based on RBAC.

    Development teams can embrace low-code technology while ensuring security best practices are in place. Low-code is here to stay, and with the right platform, enterprises and ISVs can make sure security is shifted left and addressed by developers much earlier in the development process. The result is a highly productive, remote workforce churning out applications that are modern, scalable and secure.

  • How to Mitigate Low-Code Security Risks

    How to Mitigate Low-Code Security Risks

    Gartner predicts that by the end of 2025, over 65% of development projects will use low-code builders. The field of low-code continues to expand. But what security implications does low-code introduce?

    Low-code refers to tools that enable application construction using visual programming models. Adopting drag-and-drop components instead of traditional code, no-code and low-code platforms enables non-technical folks to construct their own workflows without as much help from IT. Yet, handing power to citizen developers with less security training can be risky. Plus, low-code platforms may hold compromised propriety libraries or leverage APIs that may unknowingly expose sensitive data to the outside world. There’s also the possibility that low-code could increase shadow IT if not governed well.

    Low-code opens the door to more producers. But, does it open the backdoor, too? I recently met with Chris Wysopal, CTO and cofounder of Veracode, to discuss the growing security risk posed by low-code applications. According to Chris, hardening low-code environments involves a combination of compartmentalization, dynamic and runtime techniques, and adopting the “least privilege as possible” rule across the board. Below, we’ll expand on potential low-code risks and see what other methods Wysopal recommends organizations employ to secure the emerging low-code paradigm.

    Low-Code Security Concerns

    Verizon’s 2020 Data Breach Investigations Report (DBIR) found 43% of all breaches are connected to a vulnerability at the application layer. Thus, securing these applications, or in the case of low-code, the layer that generates them, is essential for business to function smoothly.

    When it comes to low-code, Wysopal notices a few key risk areas:

    Proprietary libraries with hidden vulnerabilities. By their nature, low-code platforms typically use a good deal of proprietary software, making securing them a bit opaque. These systems could involve a proprietary language, proprietary libraries and proprietary frameworks. If you trust a low-code platform, you place a lot of faith in the low-code vendor to have a strong security process in place.

    Some platforms do generate traditional code, which organizations can export to run on a Node.JS or Java server. Yet, this often involves a mix of code and proprietary libraries, says Wysopal. While you could run traditional static analysis on the generated code, you may miss some context.

    Lack of citizen developer security training. Citizen developers have little technical knowledge, let alone DevSecOps training. If runtime applications present vulnerabilities, expecting no-code users to mitigate them is unrealistic.

    API integrations. If low-code platforms expose an API or generate a web application via an API, the platform could be exposing sensitive data.

    Ways to Harden Low-Code Environments

    To respond to these areas, Wysopal offers some advice for securing low-code environments:

    • Perform static code analysis: Perform your own static analysis on any generated code and test for common errors. “Look at the code, and understand where it interacts with the outside,” Wysopal recommended.
    • Audit proprietary libraries: Whenever possible, Wysopal said he recommends pushing back on the vendor to question them on their application security standards and examine proprietary libraries for potential risks.
    • Verify partners: Similarly, take precautions when working with third-party partners around low-code tools. Partner tools should be carefully vetted and hold some sort of application security certification from the low-code platform.
    • Secure the API layer: Understand what APIs the application interacts with. These connections should be tested dynamically and automatically with an API scanner. Along your journey, consider these API security testing best practices.
    • Compartmentalize: Wysopal also recommends traditional isolation techniques. Consider more than just the application layer; Wysopal recommended isolating the app and running it in a virtual machine or a container.
    • Security training for citizen developers: Since citizen developers are typically not trained on appsec practices, hold security exercises to train them on fundamentals. A helpful demonstration could involve directly attacking an app to find flaws.
    • Apply the least-privilege-as-possible rule: When assigning user capabilities, whenever possible, use secure-by-default settings and allow access only to those that need it.

    By applying dynamic and runtime techniques, you may catch vulnerabilities, such as a cross-site scripting error. However, if you’re working with proprietary low-code systems, you may not be able to fix it immediately! You may have to send a request to the vendor and wait for the bug to be patched. Thankfully, most technology providers take more immediate action in response to bugs than to feature requests, Wysopal noted.

    Change the Attitude Toward Security

    On the low-code spectrum, there is the attitude that “people aren’t really doing mission-critical applications — they’re mainly doing prototyping, or back office automations,” Wysopal said. Or, since low-code applications often do not publicly expose an application, they are deemed low-risk and fall to the bottom of the security team’s inbox and list of to-dos. “We’re still in a world where people don’t secure all applications,” he said.

    However, these attitudes are a bit short-sighted, since “applications aren’t islands,” Wysopal said. Even if applications are intended for internal use only, phishing attempts could expose credentials and gain access to the network. Here, attackers could leverage sensitive resources or steal infrastructure for compute power.

    Thus, all low-code users should be aware of potential threats and change habits to address these risks accordingly. However, the onus is also on low-code vendors to sufficiently arm their systems. Having a vulnerability disclosure, bounty program and an easy means to accept bug reports from white hat security researchers will be necessary to continually patch issues.

    No-Code ≠ No-Bug

    Low-code continues to permeate more and more digital operations, opening up novel potential for citizen developers. While the low-code movement promises impressive returns, it also brings potential risk.

    To mitigate these concerns, we must level up our security understanding and evolve our approaches, Wysopal said. “Any application can have flaws and security bugs in them.” Just because you’re not writing a function in C and are relying on a visual programming model doesn’t mean you’re not introducing flaws.

    Disseminating the real risk of resources and dependencies, along with helpful consumer-facing documentation, will set the superior low-code platforms apart from the rest. Otherwise, putting faith in proprietary libraries will be a tough pill to swallow.

  • A Security Vulnerability Management Guide

    A Security Vulnerability Management Guide

    Living in a container-native world is not easy. Containers have a reputation for being a point of entry for security vulnerabilities for many organizations. In 2015, according to a research paper, over 40% of Docker images distributed through Docker Hub had high-risk vulnerabilities; at that time there were more than 95,000 container images hosted on Docker Hub. Today, there are over 3.5 million container images on Docker, and container security is of even greater concern. In a more recent 2020 study by a team of researchers at the Norwegian University of Science and Technology found container image vulnerabilities in certified and popular packages.

    This is just one example of one kind of security vulnerability. This article will share an introduction to security vulnerabilities and the role of vulnerability management for containers and other artifacts in a continuous integration and continuous delivery (CI/CD) pipeline.

    What is a Security Vulnerability?

    A vulnerability is a weakness or flaw present in software. Security vulnerabilities can be present in application dependencies or operating system (OS) packages. Common vulnerabilities include missing data encryption, buffer overflows, missing authentication for critical functions and insecure interactions between software components.

    There are different risks associated with different types of vulnerabilities. With critical or high-risk vulnerabilities, an attacker who exploits your software has the potential to seriously impact your organization. Risks associated with data breaches impact not only an organization, but also its end users and customers.

    Vulnerability Management Techniques

    Vulnerability assessment practices and tools exist to make detecting vulnerabilities simple, accurate and fast. Some of these practices include:

    • Penetration testing – Penetration testing, or pen testing, allows you to identify security vulnerabilities by attempting to break into your own systems to identify weaknesses.
    • Configuration management – Configuration management involves managing infrastructure configurations and identifying missing patches that leave your software service vulnerable to errors and risks. There are tools that provide infrastructure scanning as-a-service to help detect outdated or misconfigured instances.
    • Container and application Scanning – Allows you to detect vulnerabilities in deployable artifacts and running applications. Some available tools for container scanning include Twistlock, Clair and Trivy.

    These practices help build solid, repeatable vulnerability management techniques across your security and delivery teams. One way to scale these security practices is through security automation. Security automation is the use of technology that performs tasks with reduced manual assistance. It ultimately enables users to apply security decisions automatically and secure processes to deliver more robust applications and infrastructure.

    Security Practices in your CI/CD process

    Security automation is a core tenant of DevSecOps. DevSecOps is short for development security and operations, and it describes how organizations deliver and make security decisions and actions within the development life cycle of their valued deliverables.

    DevSecOps is a way of continuously integrating security in the software development life cycle. It’s a way of working and thinking so that security is at the forefront of how security teams deliver business value.

    One way to enable DevSecOps is through your CI/CD pipeline. Today’s enterprises can use CI/CD to accelerate better software delivery, but with that speed it becomes even more important to enable robust security. Vulnerability scanning improves software security while giving individuals across engineering and product teams accountability for each of the processes these teams own.

    Don’t let Security Vulnerabilities Ruin your DevSecOps

    This is a simple, basic introduction to security vulnerabilities and the risks they pose for your organization. There are practices and tools for detecting and reducing security vulnerabilities, and finding ways to incorporate those processes into a CI/CD pipeline is a great way to accelerate your DevSecOps.

  • Orchestration Emerges as Crucial DevSecOps Enabler in 2021

    Orchestration Emerges as Crucial DevSecOps Enabler in 2021

    As DevSecOps best practices continue to evolve and mature in 2021, security orchestration is emerging as a cornerstone of a solid defense-in-depth approach to application security.

    DevSecOps assumes organizations will shift responsibility for application security further left toward developers. If this assumption is correct, then developers clearly need access to a range of code analysis tools to achieve that goal. The challenge they face is incorporating tools from multiple vendors within a DevSecOps workflow. At different points in the development process, it may make sense to employ a static application security tool (SAST) versus a dynamic application security tool (DAST) that stress-tests the application just before it is deployed.

    Not surprisingly, providers of these tools are starting to align with security orchestration engine providers. ZeroNorth, for example, recently added ShiftLeft, a provider of a SAST tool, to the list of security tools that can be orchestrated via its software-as-a-service (SaaS) platform.

    Joanne Godfrey, director of product marketing for ZeroNorth, said organizations that have embraced DevSecOps are standardizing on two to three security tools. This mitigates the risk of becoming overly dependent on a single tool to discover vulnerabilities, Godfrey said. No single security tool can uncover every possible vulnerability in a timely manner, so DevOps teams must work to integrate multiple security tools into their workflows.

    Developers need tools capable of identifying vulnerabilities as they write code. They should also construct tests to proactively flag vulnerabilities before those are incorporated into a larger build. New vulnerabilities, however, are discovered all the time and it’s not uncommon for a container build deemed safe yesterday to suddenly need an update as quickly as possible. DevOps teams also need to secure the runtimes and hosts on which application builds are deployed, which typically requires more collaboration with the security teams usually responsible for managing platform security and DevSecOps.

    Despite this need to collaborate closely, the cultural divide between DevOps and cybersecurity teams is often wide. While there’s a lot of interest in DevSecOps best practices, developers don’t always prioritize application security when there are delivery deadlines to be met. This often results in security issues being addressed late in the application development process or, worse, addressed after the fact as part of an update delivered after an application has been deployed in a production environment.

    As application development accelerates, it’s imperative that the current divide between DevOps and security teams is bridged. Short-handed cybersecurity teams simply can’t keep pace with the rate at which applications are being built, deployed and updated. The need to shift more application security responsibility left toward developers increases daily.

    The challenge now is, rather than simply delivering an empty DevSecOps sermon, IT leaders need to practice what they preach and provide developers with the tools and processes required to secure their applications.

  • DevSecOps Implementation: Static Analysis

    DevSecOps Implementation: Static Analysis

    One of the things I’ve done for Accelerated Strategies Group recently is looking into DevSecOps toolsets. This is a fun area for me, as development and security fit together well in my mind. Having a separate security group is useful, even necessary in some scenarios, but letting developers crank out code and looking for vulnerabilities only after has always seemed terribly inefficient. Whenever I’ve managed developers, security training is just part of the package I bring. It’s far easier to write it well the first time (the equivalent of shift-left) than rewrite it.

    I won’t name names here—this is work I did for ASG, it is not mine to give away—but I will talk about DevSecOps today, and moving into the future. I’m planning three to four installments for this series, discussing the different aspects of DevSecOps tools.

    For clarity, we’re defining DevSecOps tools as “developer-enabled security tools.” This means that in some way, they help developers improve overall security posture while leaving them to be developers. We all know security has to shift left in every way if it’s to be useful in a DevOps world, but most organizations haven’t seriously started the move to shift security. Hopefully, this series helps.

    Depending upon which financial analyst firm you prefer, projections are that the DevSecOps market will grow 28% to 33% a year for the next few years. While this is good news for DevSecOps vendors, it implies very few organizations have systemically adopted DevSecOps, or there would not be room for that level of growth.

    Whether a traditional team or a DevOps team, the static analysis portion of DevSecOps is (generally) easy to set up and configure and most products offer feedback at both coding time and build time. IDE plugins have come a long way, some even offering advice as-you-code and others allowing developers to run on-demand static scans of their work. The industry as a whole has worked hard to lower the false-positive rates that made most organizations reluctant to deploy them broadly, and prioritization of issues is possible in the best products, making identification and remediation pretty easy. Try a pilot out: Pick a vendor and project, grab the IDE plug-in and check out what they can do. Most do not yet directly support code smells, but I suspect that is coming rapidly, as the systems are already designed to look at source and determine issues. Adding to the collection of possible issues will be a differentiator that quickly turns into a market requirement.

    Things to check for:

    • Language support: Do the languages you use have a scanner? While most of the tools on the market offer support for a breadth of languages, there are differences, so check the corner cases. This truly is a make or break decision—the best product on the market is useless to your org if it doesn’t support the languages you use.
    • IDE integration: This is pretty straightforward, are the IDEs your developers use day in and day out supported? Most of these tools offer command-line variants also, so it is possible that even without support directly in the IDE, the security functionality of a given product dictates that command-line is better. In that scenario, a process to ensure developers are even running scans is a good idea.
    • Vulnerabilities detected: At a minimum, support for whatever is currently in the National Vulnerability Database (NVD) should be required, along with OWASP compliance. Most vendors offer support beyond the NVD, so a bit of research to see what types of vulnerabilities are detected will be in order.
    • Click-through support: With IDE plug-ins, one of the great strengths of scanning is the ability of the developer to simply click on the vulnerability in the results list and go to the offending code. Make certain this works—and works as advertised.
    • False-positive rate: This has historically been a problem, but the industry has brought it down overall. Ask your prospective vendors to share their numbers. Our experience shows low single-digits for a percent, which is far better than the past, but still leaves room for improvement.

    The other part of static analysis is plugging static analysis into the build process. Most of these products have integrations into the most popular build management tools. Scanning the entirety of the application allows the static analysis to see a broader vision of the app and note issues with interactions between portions written by different developers. Reporting for build-time scans is generally at the application/team level, and the best tools will show results of development-time scans side by side with build-time scans if you want them to.

    Things to check for:

    • Language support: Again with the languages. It’s pretty simple here: The core of the application may be built using languages a given vendor supports but critical parts might not. Integration is where that becomes a real issue. Make sure what needs scanning can get scanned.
    • Integrations: Most of these tools offer automated scans through integration with build tools or manual scans that the build manager can kick off. Automation is preferred by a long shot, so check if your tool of choice is integrated into your organization’s build tooling.
    • Depth: We’re not going to get into source composition analysis (SCA) here—that’s for another blog—but we are going to observe that vulnerabilities can come from your source’s sources. How far does the scanning tool trace in a static analysis situation? Is it deep enough to cover a given application’s integrations and inter-relationships? While SCA will detect a lot that static scanning won’t, things such as “unsafe values sent to [insert external API]” should be available in static code analysis.
    • Reporting: This is where you’ll find the most variety in popular tools. Look at their reporting and click-through support to find what best suits your needs.
    • False-positive rate: Same as IDE integrations above—make certain it is low enough for your organization’s comfort.
    • Scan run location: This is becoming a differentiator in the space—do you want your scans run in the cloud? In the data center? Some mix of both? Check your vendors; there are significant differences in the level of support for these options.

    This is just the tip of the iceberg, of course. It is an entire market segment, and static analysis tools have been around a long time. Many organizations have not taken dev-time security seriously yet, even though we all know we need to; I’m just offering a place to get started.

    DevSecOps just makes sense. Static scanning is mature and generally well-integrated. This is a great place to start shifting security left. We get it: Developers don’t want to be security analysts or they’d have filled one of those many security openings. But IDE integration makes these scanning tools more interactive and less intrusive, showing developers how to do it securely as they code. This is great to me because good coding practices will become second nature with real-time, on-the-spot reminders and pointers. It also means that if the developer acts upon the tool’s recommendations, the code is developed more securely the first time and there will be no need to revisit it for security proofing.

    You’re all keeping the lights on in a terribly tough time. DevSecOps attempts to make it more likely that your astounding work isn’t interrupted. It just makes sense to get these tools to protect your organization’s portfolio and your hard work.