Category: Webinar

Zero Trust (ZT) has been the source of hope and confusion for many organizations looking to improve and modernize their security program. 

It is not a new concept, but President Biden’s 2021 Executive Order has recently highlighted it. The order cites Zero Trust, Software Supply Chains, and SBOM as critical pieces toward better securing American institutions and people against cyber attacks.

There is wide agreement that ZT concepts lead in a positive direction toward better security. Implementing it requires fundamental changes and raises questions: How does it really work? How do I apply it? What are its implications?

In this webinar,  Jerry Hoff and Julius Musseau break down Zero Trust’s fundamental concepts and resources. Also, they looked at Zero Trust’s implications for Applications, SBOM and Software Supply Chains.

Watch it now:

Webinar Highlights

Concept

Zero trust is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.

Put more simply, zero trust security is a way of thinking about cybersecurity that trusts no one until they can be proved worthy. This proactive approach is designed to cut down on the number of breaches that occur by preventing access to systems and data until it can be guaranteed that the user is who they say they are and that they have a legitimate reason for wanting to access the data.

Definition

ZT provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privileged per-request access decisions in information systems and services in the face of a network viewed as compromised.

Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a ZT enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan.

How Does Zero Trust Address Cybersecurity Challenges?

Zero trust security is an approach that addresses the inherent lack of trust in today’s networks. Because users can access resources from anywhere, companies have to rely on security measures that can’t be circumvented or ignored.

It addresses this challenge by verifying users and devices before granting access to any resource. This helps to ensure that only authorized users have access to the data they need, and it also helps to prevent unauthorized access, theft, or corruption of data.

ZT is an important part of today’s cybersecurity landscape, and it’s quickly becoming the new norm for companies of all sizes.

Strong Identity, Authorization & Data

Which effectively means

• Strong Authentication / Identity is paramount
• Identity based access control for all connections
• Encryption on all connections
• Consistent application of security rules
• Cloud and on prem workloads
• Remote and on prem workers
• Device Control / Inspection
• Deliberate access granting / strong governance
• Enriched monitoring

Base Pillars to build ZT

High-Level ZT Maturity Model

New Capabilities

• Need for unified, centralized, overarching authentication
• Need for centralized authorization & decision-making capabilities
• Need for device information
• Updated SOC capabilities (EDR)
• Updated Training for Staff (design, implementation, deployment, production)
• Internal delegation (who oversees centralized auth, authz, etc…)
• Policy design, update, implementation (who ?)
• Updated Governance (Many more decisions)

Implications for Application Security

• Identity
• Internally facing / externally facing paradigm breaking down
• Secure connections
• ZT is getting grouped together with new appsec regulations.

Conclusion

Zero trust security is an emerging cybersecurity paradigm that enables businesses to protect their data and resources by verifying the identities of all users, devices, and applications before they’re given access. In other words, with zero trust security, there are no trusted networks or users—everyone is treated the same, regardless of their past behaviour.

Are you relying on your container scanning to secure your applications? You might be exposed!

Containers have taken IT by storm. They increase delivery speed and stability. To secure them, you just run a scanner, right? Perhaps…

Metal detectors cannot detect plastic explosives. Similarly, many container scanners (e.g., Quay, Docker Hub, and even Snyk) are unable to detect the most vulnerable libraries inside Docker containers or Kubernetes clusters.

Do you want to know what your container scanner might be missing?

Watch this live streaming event with the heavyweight security expert Julius Musseau, where he highlights the issues and presents solutions. Learn about the typical container scanning shortfalls.

What you learn (takeaways)

• Where most container scanners fall short (and can seriously hurt you).
• A methodology to evaluate container scanners
• How to simplify application security AND improve container scanning (too good to be true?)

Webinar Highlights

Container Images

Container Scanning – The Actual Results

It turns out most container scanners are police officers where if you say, “oh, sorry, officer, I seem to have misplaced my driver’s license,” they just let you go!

This could be a problem because:

1.  Some libraries don’t include metadata files – either on purpose, or by accident, or by historical happenstance (e.g., the metadata format had not been standardized back in 2005 when the Jar was created).
2.  Open source logic can be mixed and imported in different ways (open source licenses usually don’t forbid this), and metadata might get altered or omitted during such transformations.  Copy/paste, anyone?
3.  Finally, what if someone maliciously removes or alters the metadata?

Conclusion

When evaluating scanners, it’s very important to examine them with a pre-seeded known-vulnerable sample (preferably one you create yourself) during your tool selection process (and perhaps during an annual check-up/review).

And one final caveat:  I suspect the scanners were all carefully tuned to detect log4j (e.g., special one-off logic).  I would be pleasantly surprised if they did as well against less infamous (but similarly vulnerable) samples.

MergeBase actually looks at the class files.  And so MergeBase detects the vulnerable version in “Hard Mode” regardless of the metadata present or not present.

Ready to try our SCA tool and avoid problems when scanning your container?

Want to check out our next live event? Click here and find out more about it.

Real-world supply chains can involve planes, ocean freighters, trains, trucks, and even bike couriers. So it’s no surprise that software supply chains also involve a wide variety of complementary production, distribution, and deployment channels. 

One of the challenges with securing software supply chains is that solutions must be combined to address each conduit supporting the entire chain. Patching the libraries your software engineers copied into your final build is insufficient—you must also consider your base images, the packages and platforms brought in via provisioning scripts, and even possibly plugins deployed by admins post-deployment!

Unfortunately, these disparate channels often have different weaknesses and vulnerabilities and require different security approaches. 

Watch this webinar with our special guest speaker and expert in open-source software ecosystems, John Speed Meyers,  and the vulnerability scanning implementor, Julius Musseau, as they discuss the important perspectives on software supply chains.

What they will go through:

• An understanding of today’s sophisticated and multi-channel software supply chains
• What are the risks, and how to manage them
• Software Supply chains security best practices

Take a look at the big picture and discuss specific techniques tailored to protect some of these critical pieces better.

Open Source Research 

A lot of people will claim that open source is everywhere, but how much open source software is actually out there? In this paper, we propose a methodology and associated tool that can analyze Java binaries and determine the proportion of open source that comprises them. The result of our research shows that around 80 to 90% of the software is made from open source.

Ready to start to mitigate risks in your software supply chains?

The unofficial, unauthorized retrospective, 9 months later.

If it was not clear before, after Log4j, it certainly is now! Everybody uses open-source software in their applications. There are no exceptions, and as a result, we are all at risk of being breached by vulnerabilities in open-source software. The Log4J bug was a wake-up call.

The Apache Log4j vulnerability was one of the most significant breaches in recent history. Its impact was felt worldwide, and the repercussions are still being felt today.

In this live event, Lunasec founder and CEO Free Wortley, AppSec Expert Jim Manico, and vulnerability scanning implementor (and Apache committer) Julius Musseau come together to discuss the 2021 Log4J debacle.

It’s been nine months since the Log4j vulnerability was disclosed! Aside from Minecraft, have any serious breaches dropped in the last 9 months? Or did everyone fix it in time? And what was so special about this bug?

To understand the issue and prepare for the future, we need to analyze the root causes of the breach and come up with a set of recommendations that can help prevent similar issues.

• What did library developers learn from the incident?
• What have common app developers learned?
• How should the software industry prepare for future incidents of this scale?

Learn from the past and prepare for the future.

Live Event Highlight

Log4J Timeline

1999 – Log4J 1. x is born

2014 –  Log4J 2. x is born (includes: JNDILookup.class)

2015 – General purpose JNDI exploit technique demonstrated at BlackHat

2021 – November 24th – Vulnerability shared (privately) with Apache

2021 –  December 4th –  An interesting commit lands

2021 –  December 9th – First Annual Log4J Global Day of Celebration

2021 – December 10th – Version 2.15.0 Published

MergeBase’s Log4J Detector

With Mergebase’s Log4J Detector tool, you can accurately find the log4j vulnerabilities in any cloud system, situation, and context.

CSRB’s Report

A new report from the Cybersecurity and Infrastructure Security Agency’s (CISA) Cybersecurity and Infrastructure Resilience Bureau (CSRB) addresses the continued risk posed by vulnerabilities discovered in late 2021 in the widely used Log4j open-source software library, one of the most serious vulnerabilities discovered in recent years.

The report contains 19 recommendations for government and industry, focusing on driving better security in software products and enhancing public and private sector organizations’ ability to respond to severe vulnerabilities. The goal is to identify and share lessons learned to enable advances in national cybersecurity.

“Our nation’s cybersecurity depends on the security of the software we all use every day,” said Tonya Ugoretz, Director of the CSRB. “

Advice for library Developers

• Be more careful when preparing the fix. 
• GitHub has the capability to make the pull requests and the issues private even though you’re running on a public repo.
• Security audit code audit needs to be happening regularly with libraries that are used everywhere.

Advice for library consumers (a.k.a. Software engineers)

• Know the libraries that you have (SBOM)
• Keep your libraries updated and patched.
• Keep tabs on your SCA tool – for example: How quickly was your team able to become aware of the path and how quickly they are able to apply the patch?

Advice for CISO’S & Executives

• Don’t let your developers pick any third-party library enrolled in production; you need a stronger vetting process and understand the business risk of choosing a third party.
• Running an SCA tool, like MergeBase, several times a day.
• Have the willingness to update your libraries. Suggestion: keep all your libraries updated but keep one month behind an update unless you need to be at the bleeding edge because there’s a security vulnerability. Otherwise, keep a month behind the top level and then update it to avoid supply chain issues.

Ready to start to mitigate risks?

APIs are everywhere, and their security is becoming challenging.

Gartner is seeing explosive growth of APIs and estimates that by 2025 less than 50% of enterprise APIs will be managed; the companies just don’t have the capacity to do it. So, API security is becoming a crucial topic.

It goes without saying that APIs are deployed everywhere. For instance, a website click quickly initiates a dozen REST calls directly from your browser and another dozen behind the scenes. Software engineers like you integrate with APIs more and more to develop new features and enhancements.

Are you able to secure your company’s API sprawl? 

As software engineers, we can divide APIs into two kinds: those we build & maintain ourselves (the homegrown); and those we consume (the 3rd-party externals). In this webinar, TeejLab Founder & CEO Dr. Baljeet Malhotra and MergeBase CTO Julius Musseau talked about API risks, API governance, and best practices for software engineers building and consuming APIs. 

They covered the following topics:

• Why it’s essential to think about risk when building APIs
• How to protect your company from the potential damage caused by a compromised API
• API Security best practices and standards

Why Do APIs Matter?

• The “REST Revolution” gave us all an important software architecture for free: front-end/back-end.
• And then back-ends started calling back-ends.
• And the rest is history!

What do we need to do?

APIs act as translators that allow communication between various devices and/or apps.

APIs must be: Discovered, secured, and governed systematically.

API Proliferation

The overall ecosystem of APIs at the global scale is already into millions of public APIs. We have indexed a lot of them that way, and we have built the world’s largest repository of APIs, more than what programmable web has, more than what rapid API has, or even that other organizations may have catalogued.  

For example:

• Microsoft in 2020: 60,000
• Google: 35,000
• Amazon: 30,000

How do you discover APIs?

It is a technologically challenging problem. It is a very easy concept to understand but very hard to solve because the information over the internet could be so unstructured.

There is a lot of unstructured information available on the internet, and a lot of this information is embedded in the software liability itself because a lot of times, a lot of companies have APIs, but they never published a report or a portal or a page which describes their APIs simply because either they don’t have a business functionality, they want to expose, or they just want to keep these APIs secrets for just their customers and partners.

There are various mechanisms we are applying that are curating this information at a global scale, mining repositories mining international web pages.

It is possible to get visibility into authenticated APIs?

How can you secure internal APIs?

Advice for building brand-new APIs

Do you want to know more about API Security?

How To Avoid “All Your Base Are Belong To Everyone!”

As you are probably well aware, access control is the biggest problem in Application Security. OWASP research in 2021 pointed this out, as did Verizon’s well-respected 2022 DIBR report.

Why is this important? The same report points out that web application attacks are the second most frequent attack pattern after DoS. So, if your organization has not been hit in this area, chances are you will be. Get ready!

The good, the bad, and the ugly

Be warned; there are no quick fixes! No magical tools resolve this for you. Developers’ first response is mostly to ignore access control as an issue and to make matters worse. Application frameworks rarely provide details about their functionality since it’s not particularly generalizable.

But don’t despair! Approaches to resolve this are mature and well-developed. Watch this webinar with Application Security experts Jim Manico (OWASP Top Ten contributor), Erwin Geirnaert (Co-founder & Chief Hacking Officer at Shift Left Security), and Julius Musseau (CTO at Mergebase) to learn about guidelines, patterns, as well as pitfalls to avoid it.

What will you learn in this course?

1 –  What defines the terms “access control” and “authorization,” and why are these still hard to get right?

2 – The building blocks developers need to know about it: 

• Learn how to apply the principle of least privilege when building access control in your applications.
• Learn how to use suitable data types for access control decisions
• Learn how to build a data-centric access control system to avoid Indirect Object Reference (IOR) issues.

We are going to look at some of the building blocks around good access control. Talk about principal lease privilege we want to look at, like what data we should be using at the point of making an ac decision.

3 – Best protection strategies to prevent it and then one of the more difficult things, indirect object reference. It is data-specific access control, and we’re going to come up with some protection strategies and design principles. 

So, if you want to learn more about what makes applications so vulnerable and what you can do about it, this is the webinar you won’t want to miss!

Webinar’s Highlights

What are Access Control and Authorization?

AC is about selectively restricting access to a piece of software, right various features, and various resource access. Authorization is when you give permission to a particular user or entity to access certain features or data again. In other words, access control is the act of restricting access, and authorization is the act of giving someone access to a specific part of your software.

How do most people do access control?

They use Role Based Access Control (RBAC), which is the most common access control implemented in most web frameworks. Usually, you check in a hard-coded way what role the user is correct. This is a policy enforcement point somewhere in the software where you can check if the user has permission to execute this feature.

However, hard coding has some problems:

• It makes “proving” the policy of an application difficult for audit or Q&A purposes.
• Any time the access control policy changes to be updated, new code needs to be pushed.
• It does not support horizontal ac.
• It is often not “automatic” and needs to be “hand-coded” for each application feature. 
• It does not support multi-tenancy.

Why is it still difficult? What is the challenge?

• It is difficult for developers to build. Frameworks rarely provide detailed ac functionality.

• It is difficult to test from automated tools. Scanning tools are rarely aware of your custom access control policies.

Best Practices

• SQL Integrated.
• Access Control Sequence: If you have a big sequence and it is hard to look down everything, protect the steps that will hurt your business
• Data Context considered in Permissions
• Centralize ACL Control (CanCanComunity)

Is your application safe?

SCA+SAST+DAST+IAST+RASP+.. = JOY ?

spoiler alert: probably not

In this webinar, application security experts Jim Manico (OWASP top 10’s contributor), Farshad Abasi (OWASP Chapter Lead), and Julius Musseau will go over best practices for rolling out an effective Application Security Toolset to your software development and security teams.

How can you best get started, and how can you best optimize your AppSec toolset over time? Watch this webinar NOW!

How can you best get started, and how can you best optimize your AppSec toolset over time?

Are you just thinking of implementing AppSec tools, or are you looking at optimizing your existing toolset? Watch Jim, Farshad and Julius in this webinar to hear:

1. What combination of tools gives you maximum protection?
2. What tool gives you the highest value out of the box?
3. How are threats likely to evolve, and how to use your AppSec tool set to stay one step ahead of cyber advisories?

Webinar’s Highlights

Definition / Acronyms

1. SAST –  Static Application Security Testing

It looks at the source code. The scanner will investigate the source code of the system, looking for bad coding practices. For example, static application security testing can spot SQL injection or hard-coded tokens and hard-coded passwords.

2. DAST – Dynamic Application Security Testing

It looks at the running applications. If you have to running applications, perhaps production, a pilot, or a staging environment, the DAST tools enable you to detect security vulnerabilities in running applications using penetration tests. However, it tends to be a very slow process.

3. SCA – Software Composition Analysis (Third-Party Library Scanner)

It is specifically about open source libraries. It looks at all the open source libraries in a software system. For example, protect your business against the Equifax attack or the log4j problem back in December. In other words, It looks at bad software components and lets everyone know you need to upgrade; you need not. The SCA tools are essential because open source reusable libraries are here to stay; everyone’s using them. MergeBase has research work about open source uses. The results show, for example, that Jira has around 80% at this point.

4. IAST – Interactive Application Security Testing

It is about installing a runtime agent in the programming language, which is usually like the profiling or monitoring API of a core runtime engine and instrumentation API, and you will install an agent at the level of instrumentation to see how objects and classes and the like are executed by the runtime engine. So you are installing an agent at the runtime level of the software and watching how the program runs, not from an external point of view, but from an agent that you have installed within the application itself. Get more visibility supposedly into how the app is running.

5. RASP – Runtime Application Self Protection

It provides personalized protection to applications. It uses the app’s data and state to enable it to identify threats at runtime. It automatically isolates and identifies vulnerabilities.

Matrix – Categorize Cybersecurity tools and Information Security Tools

What are common/typical challenges teams face when implementing these tools?

The challenges faced are:

• It lights up a lot of false positive number
• It requires an expert operator.

Normally, they get flooded with findings right, like thousands of findings; what do you do, and how do you prioritize them? And the solution is to bring in an expert to tune.

Application Security Best Practices

Three approaches with a different focuses:

• SCA – > External Libraries/ Supply Chain

Analyze applications for known vulnerabilities, and secure your software supply chain.

• DAST – Test Application Surface

Try to break it into production applications. It will catch configuration issues and some of the above vulnerabilities.

• SAST – Source code, developed in-house

Analyze source code for bad coding practices

These tools complement each other, and the best practice is for us all there.

Ready to start securing your applications?

Watch this webinar about how Dependabot applies to you and find out how to fix this :).

Why should you care about using Dependabot?

Because if you’re using industry-standard software leader Dependabot, then your devs didn’t fix the recent Log4J problem properly.

If you’re using it, then the tools you’re using now aren’t getting the job done.

In practice, it has a serious implementation flaw: it can only see transitive dependencies (aka sub-dependencies) in languages and dependency managers that support lock files.

Dependabot: Theory vs Reality

In theory, Dependabot is exactly what the world needs to keep software dependency chains safe from known vulnerabilities: tightly integrated with Github; auto-generates pull requests, plugged into Github Security Advisories (GHSA); it also supports a wide range of programming languages and dependency managers.

But in practice, it has a serious implementation flaw: it can only see transitive dependencies (aka sub-dependencies) in languages and dependency managers that support lock files.

Do you know any languages that currently DO NOT support lock files?

Java / Maven!

Dependabot History

• 2017 – Started by Grey Baker & Harry Marr

Initially, a “bot” would automatically create pull requests to keep NPM dependencies up-to-date.

• 2019: Acquired by Github

Now claims to support: C#, Java, Python, PHP, Rust, Go, etc…

Dependabot’s Problem

It can only find all the vulnerabilities, including the dependencies of the dependencies, if there’s a log file. So if you have a package lock.json or a gem lock or a yarn.lock if you have those in your git and you’ve committed them to get and push them up to your git server to GitHub, then dependabot can is able to use those lock files to examine the complete dependency tree, and then it can find the vulnerable libraries deep in that dependency tree.

When is there a lock-file?

A lock-files are pretty much out-of-the-box standard usage with javascript, PHP, Go and Ruby.

 If there’s no a lock-file?

When there’s no log file, but dependable is not really going to tell you about that dependabot; it’s not going to say: “alert! I’m in severely degraded instead the dependabot is going to look in this case what we’re saying is that this

the particular software system has six direct dependencies, and then those six direct dependencies bring in 50 or 60 additional sub-dependencies (indirect dependencies)

So dependabot, it’s only going to look at those six libraries, and “uh; oh,” there’s the bad ones; the depentabot’s gonna miss those because those are in the transitive or in the indirect right.

What is a lock file?

It’s funny lock-files themselves have nothing to do with application security, and they have nothing to do with the open source problem lock files solve a different problem; they solve build repeatability. We use these lock files so that everyone on your team is able to build the same software system with all the same libraries, so you auto-generate this lock file.

• Ensures Repeatable Builds across a software

team.

• Examples: yarn.lock, composer.lock, package-lock-json

• Idea: auto-generate (e.g.,”npm update”) and store in Git to ensure everyone is working from the same libraries.

The nice thing about the package-lock is it’s going to also take the full tree and write the full dependency tree to disk in this file so that everyone on the team has the exact same dependency tree in their software system.

Why doesn’t Java have lock-files?

• Because lock-files are born from chaos
• Do you remember how “npm install” circa 2013 was absolute utter mayhem?
• Any dependency system that supports “Give me anything that matches 1.2.x” or “Gives me anything ›= 3.2.1” is going to have lock-files.

What about DotNet?

• Classic case of “If it’s not enabled by default”
• Also, DotNet implementation is a little clunky (one lock-file per *.csproj / * voproj file, so usually, that means hundreds of lock-files).
• On that note, lock-files are available with Java Gradle builds these days! (But the same problem is not enabled by default!)

Note: Lock-Files Make SCA Easy!

• Recall that SCA – Software Composition Analysis – is the industry term for tools that
• “help you fix your vulnerable libraries.
• SCA is essentially 2 problems:

1. Identify all the libraries in the software.
2. Determine safe upgrade versions.

Both are hard, except #1, if a lock-file is present!

Why does MergeBase find transitive dependencies at this level when other industry-leading tools do not?

The reason that MergeBase is able to find the transitive rate is that we’re not relying on lock files exclusively; certainly, we’ll look at the lock file and consider it, but we’re also, you know, we’re going to ask maven to tell us maven like what do you think the full dependency tree is.

Does Dependabot Know About This?

• They certainly do!
• Dependabot team wrote a blog post about Log4j
• “You can use GitHub Dependabot to surface all locations Log4j is explicitly declared as a dependency”

Side Note / Sad News / Re: DotNet

• We tried to research the “direct” vs. “indirect” situations with DotNet projects as well.
• Bad news: Dependabot failed to identify transitive vulnerabilities.
• Sad news: Also failed to identify direct vulnerabilities.
• If anyone knows how to scan DotNet, tell us!

Want to know more?