staging-devopsy.kinsta.cloud

Tag: devsecops

  • How to Successfully Integrate Security and DevOps

    How to Successfully Integrate Security and DevOps

    As digitalization transforms industries and business models, organizations increasingly are adopting modern software engineering practices such as DevOps and agile to become competitive in the modern marketplace. DevOps enables organizations to release new products and features faster, but this pace and frequency of application releases can conflict with established practices of handling security and compliance. This leads to the enterprise paradox to go faster and innovate but stay secure by avoiding compromises on controls.

    However, integrating security into DevOps efforts (DevSecOps) across the whole product life cycle rather than being handled independently or left until the end of the development process after a product is released can help organizations significantly reduce their risk posture, making them more agile and their products more secure and reliable. When properly implemented, DevSecOps offers immense benefits such as easy remediation of vulnerabilities and a tool to mitigate against cost overruns due to delays. It also enables developers to tackle security issues more quickly and effectively. Getting security right from the start is important due to the growing dependence of companies on digital technologies that can make them more susceptible to cyberattacks, in which an attacker can utilize a system flaw possibly created due to unfamiliarity toward security as a business priority.

    DevSecOps integrates various security challenges into the coherent approach of software delivery. Some best practices followed in DevSecOps throughout the software development life cycle are:

    • Planning and Designing: From the inception, teams are aware of their security responsibilities and trained to handle them. Since the start teams quickly model threats and risks. Product backlog items (PBI) are prioritized in a way to make the product secure and compliant. Architectural design is developed in collaboration with security experts.
    • Coding: Developers practice secure and resilient coding practices. Full advantage is taken of reusable coding patterns and microservices to meet common security requirements for encryption and authentication.
    • Reviewing: Both automated and manual checks are used to review codes as part of regular agile sprints. After that, peer reviews are conducted by senior developers to make sure that software meets appropriate standards.
    • Testing: Automated security tests are run alongside automated functional and performance tests to confirm that testing is consistent. Automated penetration tests look for security cracks in systems as part of every sprint and release cycle.
    • Deployment: Automated processes are used to deploy code securely and reliably into production-hosting environments that can be rapidly invoked through APIs.
    • Operations: In production, automated processes such as real-time monitoring, intrusion detection and compliance validation are used to detect vulnerabilities. Product reliability and security are constantly checked to detect vulnerabilities and prioritize resolutions.

    The success of adopting DevSecOps principles relies on avoiding common pitfalls. The mere implementation of DevOps tools across the organization cannot support the effectiveness of DevOps. To get it right, companies need to:

    • Create a more integrated operating model making privacy and security principles as integral parts of the company culture.
    • Build secure and reliable services.
    • Wherever possible, automate development and release processes.
    • Continually evolve product architectures.

    Leaders play an active part in steering the transformation by endorsing security and privacy at the board level. At the same time, CISO and compliance leaders need to make certain that greater agility does not come at the cost of higher risk.

    Often organizations focus on software security as a business priority only after they are affected by a data breach. But when an organization is impacted by cybercrime, along with the costs of data damage, IP theft and business disruptions, it incurs legal and PR fees, drops in share price and the potential loss of customers and competitive advantage.

    Companies that implement DevSecOps best practices benefit from numerous advantages. Substantial costs can be curtailed by detecting and fixing security issues in the early phases of development, which indirectly leads to an increased speed of delivery and recovery.

    A secure and reliable product has the potential to increase sales. Following best practices leads to the creation of immutable infrastructure and utilization of cloud-based infrastructure that helps improve overall security by reducing insecure defaults, increasing code coverage and automation.

    Automated application testing, automated security review of code and empowering developers to use secure design patterns ensure the “secure by design” principle. In DevSecOps the responsibility for security is shared and encourages a culture of openness and transparency from earlier stages of development and enables constant iterative improvements.

    A central belief of DevSecOps is that security is an integral and essential aspect of DevOps. By adopting DevSecOps best practices in their product development cycles and avoiding common pitfalls, companies can stay current, acquire agility and strengthen their security to withstand exposure to cyberattacks.

  • DevSecOps: Changing AppSec for the Midmarket

    DevSecOps: Changing AppSec for the Midmarket

    The midmarket space has always been prime for innovation and opportunity. In the DevSecOps space, that is no different.

    If you look at this report or others about DevSecOps markets, two things stand out:

    1. The market is expected to explode to $14 billion by 2026 from today’s nominal $2 billion.
    2. The biggest driver of the increase is the rise of security adoption by midmarket enterprises.

    Software is eating the world, as everything is becoming digitized. In response, midmarket companies are rapidly cranking up web and mobile apps to better compete and serve their customers. Along with the increase comes a dependency on apps for critical business functions and a need to secure them from attacks, which explains the surge in security demand.

    Current AppSec Offerings Are Not Geared for the Midmarket  

    AppSec Expertise Required

    Most incumbent AppSec products were built at least a decade ago when only large enterprises cared about AppSec. Naturally, they were molded for the characteristics of those enterprises. They are unnecessarily deep and monstrously complex and require a team of AppSec experts to begin operations. Midmarket companies don’t have the skills, resources or willingness to hire a team of AppSec experts, especially given their short supply.

    Extraordinarily Expensive

    Incumbent AppSec products are dreadfully expensive for midmarket companies. Annual prices reach millions of dollars and it’s difficult to determine ROI, making decisions murky for budget-conscious midmarket companies. They want to produce and deliver secure apps and certainly want to mitigate risk, but they also have a lower ceiling they can afford to pay.

    A New AppSec Approach for the Midmarket

    Being Cloud-native Requires SaaS AppSec

    Midmarket companies are quicker to adopt a cloud-native approach. Unlike large enterprises, they don’t have the baggage of legacy tech and can move to the cloud more easily. Being cloud-native saves a lot of money and comes naturally to the midmarket—when it comes to AppSec, they are likely to require that products be cloud-native and SaaS. Most security incumbents started on-premises, and although some now have a parallel SaaS offering, they are clunky and not designed inherently for cloud-native architectures.

    Rise of DevOps and CI/CD Automation

    As cloud adoption increases, automation of deployment to the cloud becomes a key factor, resulting in the meteoric rise of DevOps. DevOps uses many tools to automate cloud integration and cloud deployment, with CI/CD tools consistently at the center. AppSec must be part of this automation process, preferably in the CI/CD. The manual waterfall approach cannot work with the new speed and volume of application development. If scanning is not automated in the CI/CD, scans simply don’t get run. Therefore, because the automation workflow starts with DevOps, AppSec needs to be DevOps-first.

    Traditional AppSec scanners were not built for DevOps. Sure, some have caught up and added DevOps to their marketing material. Several have even added some integrations, but their core product remains much the same and it’s not DevOps-friendly.

    One significant offshoot of DevOps-first AppSec for the midmarket is that the tool cannot require AppSec expertise, simply because most DevOps don’t have significant AppSec expertise. Requiring that knowledge to get the security automation workflow started is a non-starter.

    Open to Open Source Scanners … With Management

    Midmarket companies are typically willing to use open source primarily because it is free. Unlike large enterprises with their tendency to complicate anything, midmarket companies have fairly standard requirements that can usually be met with open source. It is no different when it comes to application security scanners, and midmarket enterprises are fans of these tools. Often the scanning prowess of these open source scanners is better than their commercial counterparts, as they are tailored and specialized to specific languages and architectures. They also cover all scan types (SAST, DAST, SCA, etc.) and a combination of them can provide an efficient and affordable level of security.

    This midmarket love affair with open source scanners comes to a screeching halt when it becomes apparent that it is grossly unmanageable. There are so many available open source scanners that it takes time to decide which are relevant for your organization, application and development status. They are also notoriously difficult to set up, upgrade and maintain. Each of them does things differently. The output or reporting formats are not normalized across scanners. Without an aggregation layer to consistently cross-reference, normalize and present a consistent view of the security risk, consuming the output is nearly impossible. This often results in midmarket companies choosing to select only one type of scan.

    Imagine a tool that adds a common SaaS orchestration layer that crosses all these scanners and scan types, using their superior scanning prowess, but removing the management headache. Midmarket companies would improve their security posture with an investment they can afford. This sort of “Open Source + SaaS” model is not new. Applying the model to application security changes the game for midmarket companies.

    One Tool for all Scanning

    The multiple types of application security scans make application security complex. SAST scanners scan the source code for vulnerabilities, DAST scanners scan running applications from the outside in, SCA/OSS scanners scan third-party libraries included in your application, container scanners scan containers, API scanners scan exposed APIs, Secrets scanners scan for open passwords in the source code, and so on. Mentioning all these distinct scanners can make heads spin for those inexperienced with AppSec. This complexity is worsened for midmarket companies. For most, it is nearly impossible to keep up with the new pace of application development with unaffordable, piecemeal scanners from multiple vendors or the multiple open-source scanners needed to address each area of vulnerability.

    Security is only as good as the weakest link. Even if you do an exemplary job with one type of scanning but leave out other types you leave gaping holes in your security and risk. What midmarket companies need is one tool that tackles application security comprehensively by automating and orchestrating the use of all types of scans while abstracting the user from the underlying complexities.

  • Using PAM to Support the ‘Sec’ in DevSecOps

    Using PAM to Support the ‘Sec’ in DevSecOps

    Despite its reputation as slow and complex, PAM can be included in the DevOps pipeline effectively

    The introduction of DevOps practices has led to a revolution in software development. However, as companies adopt these new technologies, tools and methodologies, incorporating privileged access management (PAM) becomes increasingly complex. Nonetheless, corporate policies, industry standards and government regulations mandate that security and operations teams must manage and audit permissions and credentials for a growing number of user and service accounts. As a best practice, a least privilege access control model is a must.

    Compounding the issue is that traditional methods of securing developer environments involve manual interventions and restrictive controls that significantly hamper the agility of development and operations teams. Because of that, DevOps has eschewed PAM as too slow and complex to deploy and manage.

    Adding to the complexity, applications, virtual machines, services and workloads running in the cloud all have identities. In fact, non-human identities nowadays represent most “users” in many organizations. This proliferation of non-human identities exacerbates the difficulty of achieving least privilege.

    Like human identities, access for these identities must be strictly monitored and controlled so that unauthorized, unverified access is automatically denied. PAM solutions that support modern application-to-application password management (AAPM) approaches can achieve this. DevOps owners can take control of privileged access without impacting agility, leaving them to focus on what they do best while finally putting the “Sec” into DevSecOps.

    AAPM eliminates the need to store credentials in clear text in the application. Instead, developers introduce API calls in their code to access a vault programmatically and to check out the password. The password is stored in application memory and not written to disk. Once the application terminates, the memory is deallocated and the password is gone, leaving nothing for a threat actor to find. Using this approach, the vault secures the credentials and controls access to them. The vault can also automatically rotate passwords, making them more challenging to crack. Since dependent applications now make API calls to fetch them, DevOps teams are no longer concerned with updating their code whenever the passwords change.

    PAM and DevOps: AAPM in Action

    This is a fundamental approach to AAPM. Other options exist, however, distinguished by increasing levels of cyber-risk mitigation and operational efficiencies:

    Level 1: AAPM to Retrieve a Vaulted ID and Password

    As described, this is the traditional approach to PAM. While vaulting the passwords provides an extra layer of security by removing them from code, passwords remain the weakest form of authentication. Even with automatic password rotation, they persist until the next scheduled rotation (often days or weeks), giving an attacker ample time to attempt to crack. To check them out of the vault, each workload needs a service account. This can quickly amount to hundreds, if not thousands, of additional accounts, increasing administrative overhead and increasing the attack surface.

    Level 2: AAPM to Retrieve a Vaulted ID and SSH Key

    Human administrators and workloads present an added risk to organizations through the widespread use of shared privileged accounts for authentication. Secure Shell (SSH) keys are frequently implemented as a safer alternative, allowing the workload to check out a vaulted SSH key instead of checking out a vaulted password.

    The use of SSH keys includes similar risks and benefits to vaulted passwords. They’re also static, relying on a scheduled rotation. They, too, can be shared among developers and between workloads. Developers and IT admins are often given enough rights to create SSH keys at will without any oversight or central management. This makes them difficult to track and know how they’re being used, by whom and for what. If they’re lost or if a developer leaves, system and service availability can be impacted.

    On the positive side, however, the SSH protocol employs public-key cryptography. The SSH keys (public and private) are longer and more complex than any password. Unlike passwords, they’re not sent over the wire. All this makes them more difficult to compromise and, thus, more secure.

    That said, each workload still needs a service account to authenticate to the vault and check out an SSH key, each of which is a potential vector of attack.

    Level 3: AAPM to Retrieve Ephemeral Tokens

    Ephemeral tokens (e.g., OAuth2) can be created automatically by the vault on-demand and offer a modern form of secure access that is temporary, time-based and expires automatically. This releases DevOps from dealing with installation, configuration and rotation issues while contributing to a best-practice “just-in-time” access control approach. As with the earlier methods, however, each workload still needs a service account to authenticate to the vault to obtain a token.

    Although such tokens can persist, they’re generally short-lived for the duration of a session or transaction, greatly reducing the window of opportunity for a threat actor. 

    Level 4: AAPM Using Delegated Machine Credentials and an Ephemeral Token

    The prior methods are all characterized by a per-workload service account requirement. With a Delegated Machine Credential approach, a service account is only required per-machine.

    When the machine is enrolled in the PAM service, it establishes a mutual trust relationship. The PAM service creates a unique Delegated Machine Credential, machine identity and service account for that machine. Local workloads can then piggy-back off that machine identity, leveraging the delegated machine credential to authenticate to the vault, exchanging it for an OAUth2 bearer token it can use for subsequent API calls (e.g., to check out a password or obtain a token.) Since not all workloads are equal, OAuth scoping can limit which APIs each workload is allowed to access. Thus, by using a Delegated Machine Credential, the number of service accounts is reduced to practically zero, closing thousands of potential vulnerabilities.

    This approach also addresses the lack of desire to introduce PAM into DevOps, as I highlighted right at the start. This method can be fully automated and inserted naturally into the CI/CD pipeline.

    All these approaches give organizations more choice, based on their existing PAM maturity, risk tolerance, and compliance pressures. They ultimately allow DevOps teams to automate, simplify and centralize PAM security management while improving the organization’s security posture, without sacrificing agility.

  • Snyk Brings AI to DevSecOps

    Snyk Brings AI to DevSecOps

    Snyk today at its SnykCon 2020 conference announced a static application security testing (SAST) dubbed Snyk Code that incorporates an interpretable machine learning semantic code analysis engine the company gained through its acquisition of DeepCode earlier this year.

    The company also announced it has extended its alliance with Docker Inc. to become the exclusive provider of security insights for both Docker Official Images and future content certification programs from Docker. Available via Docker Hub, Docker Official Images are a collection of 166 curated container images that developers frequently reuse.

    At the same time, Snyk today announced it has integrated its vulnerability database with the IT monitoring service provided by Datadog as well as the IBM Cloud service.

    Snyk President Guy Podjardny said Snyk Code is aimed specifically at developers as part of an effort to advance the adoption of best DevSecOps practices. It provides visibility into application source code, open source libraries, container infrastructure and infrastructure as code to enable developers to better secure applications as they are being built.

    The company claims Snyk Code is up to 50 times faster than traditional SAST solutions, which would represent a major boost in productivity for developers who often don’t have the patience required to scan code as much as IT security teams would prefer.

    Snyk Code also curates machine learning models using the company’s curated vulnerability database to significantly reduce false positives. It also automatically models application programming interfaces (APIs) based on the best practices observed by the platform.

    Snyk Code is also designed to be integrated with CI/CD platforms to streamline DevSecOps workflows.

    Podjardny said Snyk went beyond simply productizing the Deep Code tool to incorporate capabilities that would specifically appeal to developers rather than cybersecurity teams. Given the volume of code that needs to be scanned before and after code is deployed in a production environment, Podjardny said it’s apparent that DevSecOps isn’t going to be achieved without augmenting developers with artificial intelligence (AI) tools.

    It’s not clear at what rate responsibility for IT security is shifting left toward developers. Beyond simply providing developers with the tools required to analyze code, workflows that DevOps and cybersecurity teams currently rely on must be better integrated. That’s a challenge, because the current rate at which DevOps teams are updating applications typically exceeds the ability of a limited team of cybersecurity professionals to keep pace. The days when cybersecurity teams could have weeks to review an application before being deployed are all but over.

    It may take a while for DevOps teams to gain confidence in AI tools. However, it’s clearly not feasible for human developers to identify every potential vulnerability within thousands of lines of code running on multiple platforms that can have any number of vulnerabilities which developers are not likely to know much about. As such, it’s not so much a question of if AI will play a major role in enabling DevSecOps as much as when.

  • Accelerate Your Digital Transformation with IBM

    Accelerate Your Digital Transformation with IBM

    DevOps practices, processes and solutions help businesses accelerate their digital transformation by improving the speed and quality of software development. DevOps tools enable teams to do their job more efficiently by embracing automation, increasing agility and building speed, versatility and security into the framework.

    At the IBM DevOps Virtual Summit, attendees will learn how to keep their applications running smoothly with automation and data-driven solutions that can reduce mean time to resolution and explore IBM solutions to help innovate hybrid environments, disrupt cloud native development and transform existing mainframe infrastructures. The free virtual event will take place on Oct. 29 from 10 a.m. to 2 p.m. ET.

    IBM leaders will discuss the benefits of DevSecOps, how to increase business value, SRE best practices and how IBM Cloud software and services can help organizations succeed on their DevOps journey.

    The virtual event will feature four educational sessions from leading DevOps technologists:

    • “Application Modernization Enabling Hybrid Cloud with IBM Z,” by Rosalind Radcliffe, distinguished engineer and chief architect for DevOps at IBM.
    • “The Modern DevOps Manifesto,” by Andrea Crawford, distinguished engineer at IBM.
    • “DevSecOps in a Hybrid Multicloud World,” by Sunil Joshi, executive architect at IBM.
    • “Common Tooling Approaches from Kubernetes to the Mainframe,” by Eric Minick, program director at IBM.

    For more information about the virtual summit or to register, please visit the IBM DevOps Virtual Summit website.

  • ZeroNorth Extends DevSecOps Orchestration Reach

    ZeroNorth Extends DevSecOps Orchestration Reach

    ZeroNorth has extended its namesake software-as-a-service (SaaS) platform for orchestrating DevSecOps toolchains to include integrations with Scout Suite, Aqua Trivy, Gitlab and BitBucket Server and the configuration management database (CMDB) from ServiceNow.

    The company is also adding application portfolio reports to surface the security policies applied to each application, scan results and progress of remediation work and the ability to customize both alerts and vulnerability data compression parameters, such as rate of compression, name and type of vulnerabilities and libraries.

    Finally, filtering and search tools that can be applied to vulnerability datasets have been added.

    ZeroNorth makes it possible to centrally orchestrate and manage both commercial and open source application security scanning tools via a SaaS application platform.

    Christian J. van den Branden, senior vice president of engineering and product management, said that as DevSecOps processes continue to evolve and mature, most application development teams will employ multiple scanning tools because not every tool discovers every vulnerability. This defense-in-depth approach to vulnerability scanning requires an orchestration tool to integrated multiple scanning tools within a DevOps pipeline, he said.

    That orchestration tool also makes it easier for DevOps teams to prioritize vulnerabilities based on their severity discovered by various static application security testing (SAST) and dynamic application security testing (DAST) tools, noted van den Branden. Tools from vendors such as Qualys, Snyk, Palo Alto Networks, Synopsys and WhiteSource are supported across multiple DevOps platforms.

    In general, van den Branden said a “perfect storm” of security issues is forming in the wake of the COVID-19 pandemic. Organizations are rushing to build and deploy digital business applications that will appeal to end users who increasingly are working from home using largely unsecured networks. Cybercriminals are looking to both compromise applications as they are developed in addition to targeting end users with weak credentials that could be employed to inject malware into applications after they are deployed in a production environment, he said.

    Most IT organizations will clearly need to up their application security game, given the sensitive nature of the digital business processes that need to be protected, he added.

    Ideally, DevOps and cybersecurity teams will meld their workflows to achieve that goal. In many cases, however, DevOps teams will simply extend their existing pipelines to address security issues of their own accord as part of an effort to reduce the number of remediation issues they might need to allocate time to remediate after an application has been deployed in a production environment. That becomes easier to accomplish using a SaaS-based platform to orchestrate DevSecOps processes and pipelines, noted van den Branden.

    Regardless of how IT organizations improve application security time is of the essence. More applications than ever are being deployed across an extended enterprise that now stretches from public clouds to multiple classes of edge computing platforms. Defending that attack surface relying on legacy tools and processes is all but impossible if the code deployed on those platforms is fundamentally insecure.

  • Sonatype Advances Open Source Code Quality, Security

    Sonatype Advances Open Source Code Quality, Security

    Sonatype today launched an Advanced Development Pack service that surfaces dependencies between open source components in a way that makes it easier for developers to know which ones to employ to build the most secure application possible and what components offer the simplest upgrade path.

    Company CTO Brian Fox said the Advanced Development Pack service is an extension to the Nexus Lifecycle platform the company currently makes available to identify vulnerabilities in open source code.

    The Advanced Service Pack was created after studying development and cybersecurity practices across 30,000 software teams that Sonatype was able to analyze in its Maven repository, said Fox. The goal is to eliminate a vicious cycle that emerges as organizations develop applications using components that too often need to be either replaced or updated depending on the security and quality issues uncovered later in the development life cycle. By making it easier to identify the highest-quality modules available, the Advanced Development Pack serves to increase developer confidence in the quality of the open source components being pulled as they develop their application.

    A Component Chooser tool, currently in beta and slated for availability next year, will also make it possible to employ project hygiene ratings based on security and license compliance as well as identify where else that component may already be in use.

    The Advanced Service Pack makes it possible to evaluate open source components based on factors such as project quality, ease of upgrade and advanced knowledge of abnormal committer behavior, said Fox. Other factors evaluated include the cost of migrating to a newer or safer version of a module and whether it is possible to do so without breaking code, release frequency, the cadence of dependency updates, development team size and popularity.

    The Advanced Development Pack also furthers the adoption of best DevSecOps practices by identifying which dependencies have become vulnerable and have been remediated, as well as suspicious behavior involving project code commits that might be indicative of a malicious injection attack. It also applies machine and deep learning algorithms to automatically identify and block software supply chain attacks based on typosquatting and malicious code injection. In the past 90 days alone, the malicious code detection bots created by Sonatype have discovered 43 new malicious packages including electorn and loadyaml.

    Sonatype has also included a transitive solver capability that provides comprehensive remediation advice for solving both direct and transitive dependencies without violating policies or failing builds.

    Fox said that while there’s a lot of focus these days on making sure individual application components are secure, it’s also become apparent that cybercriminals are now targeting application development platforms as part of an effort to compromise the entire software supply chain. As such, DevOps teams now need to focus on securing both the components they employ and the platforms used to construct their applications.

    In the meantime, there may never be such a thing as absolutely secure open source code. However, it is becoming possible to greatly minimize the risks associated.

  • Strengthen API Security With These Tips and Patterns

    Strengthen API Security With These Tips and Patterns

    If you haven’t noticed, digital organizations are building more and more APIs. ProgrammableWeb tracks more than 23,000 public web APIs at the time of writing, and the API market is estimated to be worth $5.1 billion by 2023. Building with APIs increases internal interoperability, reduces development time and can extend product functionality tremendously. In short, the value of APIs is rising. However, opening up with APIs brings security caveats that, if not addressed, could result in serious breaches that negate these benefits.

    I recently spoke with Roey Eliyahu of Salt Security to get his take on the top security concerns for API-enabled companies, and how organizations can safeguard their services. In short, he recommends thoroughly cataloging and understanding your API inventory, designing for legal challenges and mitigating OWASP’s top 10 API security vulnerabilities.

    Challenges for API Security

    APIs have been called “the next frontier in cybercrime.” Rightly so, as API breaches continue to pop up nearly every day. Take the recent API vulnerabilities at Cisco Systems, Shopify, Facebook, U.S. presidential campaign apps, and GCP as evidence. The most infamous was likely the Equifax breach—not enforcing formats on incoming API calls resulted in a massive data breach, which cost the company a $700 million lawsuit.

    So, why have API breaches increased recently? Well, a few years ago, there were simply fewer APIs. And, these older services exposed less sensitive data. Nowadays, companies typically have many more APIs. Banking applications, for example, might expose hundreds of highly valuable endpoints that are very appealing to hackers.

    Companies also build APIs for different audiences: A 2020 study by SmartBear found 72% of companies develop both internal and external-facing APIs. These APIs could easily hold hundreds of parameters, and with every new method added, a company’s potential attack surface grows considerably.

    3 Steps To Secure APIs

    To mitigate the above API security issues, Eliyahu suggested three main steps: Understand your API inventory, audit against privacy policies and data privacy regulations, and track the most pressing API vulnerabilities like a hawk.

    Know Your API Inventory

    “You need a great inventory of APIs to know your attack surface,” said Eliyahu. Many API providers document their APIs with OpenAPI definitions. But, these files don’t always match the production realities—they may be manually generated or leave out certain methods. “In every organization, there is up to a 40% gap between APIs that are actually deployed versus what has been inventoried,” he said. By maintaining a clearer API inventory, organizations can avoid unprotected shadow IT.

    Include Legal Auditing

    A change to an API could result in a change in how it collects user information. Updates involving sensitive data could break privacy policies or regulations such as GDPR. “After you have an inventory, you need to map all parameters manually,” said Eliyahu. He recommended performing a legal audit against your API inventory and establishing a repeatable testing process that plugs into a continuous delivery pipeline.

    As API teams release new updates, they must consider security and legal implications earlier on in the development flow. “Now, with CI/CD, these changes have to happen very frequently,” he noted.

    Watch the OWASP API Security Top 10

    There are many known API security gaps. For example, there may not be proper authorization in place, keys could be exposed, unexpired tokens could be hijacked and so on. Thankfully, OWASP has compiled a resource of top API security vulnerabilities, which Eliyahu and many others in the API economy have rallied behind. “The world should move to adopt the OWASP issues,” he said. These vulnerabilities are as follows:

    1. Broken Object Level Authorization
    2. Broken User Authentication
    3. Excessive Data Exposure
    4. Lack of Resources & Rate Limiting
    5. Broken Function Level Authorization
    6. Mass Assignment
    7. Security Misconfiguration
    8. Injection
    9. Improper Assets Management
    10. Insufficient Logging & Monitoring

    Using AI To Go Beyond ‘Whac-A-Mole’

    Plugging these above holes is a good start. However, these are only defensive measures against known patterns; they aren’t helping you keep guard for nuanced attack types. Ideally, security systems should stop cyberattacks before they even get started.

    Yet, Eliyahu recognizes a big gap in how APIs are monitored. Organizations “don’t have proper tools to know who is looking for vulnerabilities,” he said. “Tools are typically not that advanced. They mainly look for injections and known patterns.”

    Imagine a hacker probing an API. They will likely do so by trial and error, testing undocumented endpoints, sending malformed requests and so on. “They need to probe for hours or days before they find something,” said Eliyahu. If an AI could detect these odd attempts in minutes or seconds, IT could significantly reduce risk.

    Security solutions should thus leverage big data and AI to create baselines of typical behavior, then deter malicious activity the millisecond any nefarious probing begins. Eliyahu said such a security AI must consider dozens of behaviors such as, How is the API being accessed? What parameters are being used? What are the relationships between parameters? What is the flow of API calls? What type of data can be exposed?

    Instead of waiting for a breach to occur, an AI-enabled API security monitoring could instantly pause behavior deemed “out of the norm” by referencing a knowledge base that’s constantly refined using machine learning. Because, if you are only blocking malicious actors without knowing how you need to improve API security posture, “you are just playing Whac-A-Mole,” said Eliyahu.

    DevSecOps Requires API Security Forethought

    Mark O’Neil, analysis at Gartner, predicted that by 2021, 25% of organizations with public APIs will have discontinued or rebooted their public API strategy, citing security concerns as a common breaking point. APIs are now at the core of many application developments. Yet, without the proper DevSec proposition, teams risk wasted efforts and costly breaches.

    To summarize, here are our tips on API security:

    • Ensure everything is well-documented: API inventories cannot be audited if undocumented. Shadow APIs increase the likelihood of an attack.
    • Watch the top 10 OWASP vulnerabilities: These points are foundational to API security. Though not a cure-all, they present a starting point.
    • Build a security and legal review process: Ensure APIs are never deployed without the proper security review. Create validation systems that plug into continuous development processes, so new versions are never breaking privacy policies.
    • Each API is unique: Another thing to keep in mind is each API is unique. Therefore, API security monitoring also requires more context into unique business logic.
    • Continuously monitor your APIs: Continuous search for anyone looking for vulnerabilities.
    • Remove deprecated APIs: Remove old API versions. “You need a mechanism to identify and remove old API versions.” Otherwise, “zombie APIs will bite you!”
    • Learn from the attacks you block: Don’t just play Whac-A-Mole. “You need a mechanism to learn from attacks you block.”
  • Survey Surfaces Lots of DevSecOps Friction

    Survey Surfaces Lots of DevSecOps Friction

    A survey of 560 application security professionals and software developers in North America and Western Europe conducted by WhiteSource, a provider of tools for securing open source software, finds there’s a long way to go before most organizations can claim to have fully implemented best DevSecOps practices.

    Only 20% of respondents said their organization had a mature set of DevSecOps practices in place, while 62% said they were improving. Only 18% described their organization’s approach to DevSecOp as being “immature.”

    There is considerable disagreement concerning how long those efforts have been underway. While 60% of security professionals said they have had an application security program in place for at least a year, just over a third of developers (37%) said they are aware of an application security program running for longer than a year inside their organization.

    Regardless of the length of the program, nearly three-quarters of all respondents (73%) said they feel forced to compromise on security.

    Among application security professionals the top DevSecOps challenge identified was vulnerability prioritization (41%), followed by lack of application security skills (35%), budget (34%), lack of cooperation between developers and security teams (31%) and scanning performance (31%). Less than a third (31%) have a formal process in place to prioritize vulnerabilities.

    There’s also considerable disagreement over whether an application security champion gets designated. Many application security professionals said they have one (60%), while only 40% of developers agreed. The survey also finds well over one-third of developers said their organizations (37%) don’t provide any secure code training. A mere 22% of developers said their organizations provide training regularly with another 20% reporting they have tools that allow for “ongoing independent training.” In contrast, only 27% of application security professionals said their organization does not offer secure code training.

    Lilach Aviad, director of product marketing at WhiteSource, said the survey makes it apparent there are still lots of gaps when it comes to DevSecOps. Most organizations have embraced the concept but are still a long way from unifying workflows to better prioritize which vulnerabilities to address first.

    Priorities are even fundamentally different when it comes to what features are most important in an application security tool. Application security professionals prized integration (48%) most of all, followed by accuracy and ease of use ties at 39%. Developers, in contrast, leaned toward accuracy (25%), followed more closely by integration (22%) and ease of use (21%).

    Overall, the survey found the most widely employed application security tools are penetration testing, web application firewalls and application programming interface (API) gateways. The acquisition of these tools is most often justified to achieve either vertical industry regulations (25%) or industry standards (22%).

    In general, Aviad noted when it comes to security there is still a lot of resentment among developers. Too often security tools have been selected by application security professionals with little regard to how those tools might fit within the context of a larger DevOps workflow, he said.

    Obviously, it’s going to take time and effort for most organizations to merge workflows and culture. The good news is that process has begun in a lot of cases. Less clear is exactly how long it will take to complete.

  • VMware Looks to Meld IT and Security Operations

    VMware Looks to Meld IT and Security Operations

    VMware has acquired SaltStack as part of an effort to unify IT and security operations management. The announcement was made during the online VMworld 2020 conference this week.

    SaltStack has developed an open source IT automation platform to automate IT operations. In recent months it has been extended to also address security and compliance management.

    At the same time, VMware released a bevy of updates to its security portfolio, including VMware Carbon Black Cloud Workload. That offering combines vulnerability reporting with workload hardening software for both legacy platform and microservices-based applications deployed on Kubernetes clusters. It also includes elements of AppDefense, which VMware developed to harden workloads running on VMware vSphere platforms.

    VMware also announced VMware NSX Advanced Threat Prevention, which combines NSX Distributed IDS/IPS with malware detection software and network traffic analysis (NTA) technologies acquired from Lastline Inc.

    Finally, VMware announced it has committed to reselling a secure web gateway from Menlo Security as part of the VMware SD-WAN portfolio and formed an alliance with Zscaler to manage security as a service.

    SaltStack provides VMware with an IT automation framework that can be applied across multiple clouds running virtual machines and containers. The current vRealize IT automation framework is optimized for instances of VMware vSphere.

    Tom Corn, senior vice president for the Security Business Unit for VMware, said VMware’s entire approach to security is predicated on making it easier for IT operations teams rather than cybersecurity professionals to implement security controls. There are simply not enough cybersecurity professionals available to implement cybersecurity controls when DevOps teams are rolling out and updating application workloads multiple times a week, he said.

    Cybersecurity teams will continue to define what controls will need to be put in place, but it will be left to the IT operations teams to implement those controls in much the same way responsibility for application security is now also being shifted left as part of best DevSecOps practices.

    Corn said it’s clear IT security is a team sport that requires greater collaboration among IT operations teams, developers and cybersecurity professionals. VMware has been investing in security technologies with an eye toward making it easier for IT operations teams to automate security operations in much the same way any other IT task is being automated, he noted.

    That convergence isn’t going to occur overnight. There are many challenges including culture. Many cybersecurity professionals view IT operations and developers as being equally responsible for many of the root causes of a cybersecurity breach. It may be a while before cybersecurity teams have enough confidence in the ability of IT administrators and developers to proactively address cybersecurity issues before and after applications are deployed in production environments.

    Of course, there’s no alternative. The days of waiting two months or more for a security review as part of a waterfall development process are over. Security, like it or not, needs to become as agile as the rest of IT.