Intro

Lightrun enhances its enterprise-grade platform with the addition of RBAC support to ensure that only authorized users have access to sensitive information and resources as they troubleshoot their live applications. By using Lightrun’s RBAC solution, organizations can create a centralized system for managing user permissions and access rights, making it easier to enforce security policies and prevent security breaches.

In addition, Lightrun’s RBAC new solution helps improve efficiency and reduce the administrative burden associated with managing user access rights. With the new solution, administrators can define roles and permissions for different groups of users across dedicated debugging agent pools, rather than managing access on an individual basis. This makes it easier to assign and revoke permissions as needed, without having to manually manage access for each user.

As illustrated above, with the new Lightrun’s RBAC implementation, organizations can benefit from added values to organizations that adopt it. From compliance, resource allocation, separation of duties, and risk management, the implementation of RBAC can be the determining factor between an organization that is riddled with security vulnerabilities and disorder, and one that is well-managed and secure.

Introducing Lightrun RBAC 

To ensure each team member as well as development leadership within DevOps teams have the right access and permissions to each of their applications, Lightun is launching its RBAC support. With this new enterprise security component, the entire Lightrun platform is now fully governed within the organization. 

Lightrun’s Role Based Access Controls are divided into 3 main pillars that are controlled, manageable, and configurable through the Lightrun management portal as well as the command line interface (CLI). Customers that wish to upgrade their IDE plugins and management server to the latest version with RBAC support, should contact the Lightrun account executive team to get this capability enabled. 

Once the groups, users and agent pools are in place, that’s when they can be matched through different configurations. As an example, if an administrator would like to group the agents that are used to troubleshoot the production environment and make these agents available only to a specific team (e.g. DevOps team), he would define the Production agent pool and then the DevOps user group while defining its access to the Production agent pool.

By utilizing the mentioned features, an organization has the ability to assign various roles to developers, testers, Ops, IT, and other professionals within specific Lightrun agent pools and groups, while ensuring adequate security measures and governance

As illustrated below, the group managers would create, maintain, and modify the roles and privileges of the different team members from the management server user interface. They can create new groups, add new users, modify privileges, create agent pools and more to properly manage the organization.

The users within the different groups will then get a reflection of their allocated agent pools directly from the Lightrun IDE plugin (JetBrains IDEs and VSCode) where they can troubleshoot their apps across production, staging, QA, and any other environment by simply selecting the relevant agent pool from the RBAC dropdown list in the plugin (see example below).

Bottom Line

As organizations scale and mature, there is a need for proper security and governance within their teams. Specifically in distributed workloads where developers are disconnected from their remote applications running remotely (serverless, container POD, etc.), it is imperative to provide them with the right level of control so they can perform their troubleshooting activities properly, and without any security risk to the organization. 

With the launch of Lightrun RBAC support, customers can now enjoy the following benefits:

1. Ability to restrict users access through the user groups, and permissions based on the role within the organization and user groups
2. Logically organize all of Lightrun debugging agents into pools to:
   1. Continuously and simply maintain environment debugging through a secure and centralized system
   2. Easily scale and manage the troubleshooting efforts as the team grow 
   3. Compartmentalize the agents and the troubleshooting data to limit user access and control

To learn more about Lightrun RBAC support please visit our website.

The post Lightrun Bolsters Security Measures with Role-Based Access Control (RBAC) appeared first on Lightrun.

I’m not a security expert. I’d like to think of myself as a security conscious developer, but this is a vast subject with depth and breadth. What I understand is Lightrun and Debugging. In that capacity, I can show some creative ways you can use it as a security tool. A “proper” security expert could take this to the next level.

What is Lightrun?

Lightrun is a developer oriented observability tool. Like a production debugger without the security risks. Lightrun is a tool that’s flexible enough to fit into multiple molds, just like the debuggers that birthed it. 

With Lightrun, you can inject logs without code changes. Add snapshots (breakpoints that don’t stop the code execution) and use metrics to get observable insight at the code level.

Security Tool Use Cases

There are several reasons I would reach for Lightrun as a security tool. Here I’ll focus on:

• Verify that a security vulnerability exists
• Check if someone actively exploited a security vulnerability
• Verify that we deployed a fix correctly 

There’s a lot more that needs to be done in order to secure your application. Lightrun is a generic tool, it isn’t a replacement for existing security tools like Snyk, etc. It’s complimentary, filling in the gaps at the code level.

Finally, I will discuss how Lightrun secures itself. We can’t have a vulnerable security tool… We can’t consider Lightrun as a security tool if it isn’t inherently secure…

Enough with the high level theory. Let’s show the code!

Verify a Security Vulnerability

Security tools are like observability tools. They provide high-level alerts of potential risks. But they rarely communicate at the code level. As a result, a developer might have a hard time with actionable security tasks and validation. If the security issue reproduces locally, that’s great. You can often fill in the gap with a debugger.

But some security issues are tough to reproduce outside of a production environment. 

Lightrun won’t find a vulnerability out of thin air, for that you need a dedicated security tool. However, if you have a suspicion, Lightrun can help in the investigation and prove the vulnerability. 

E.g. let’s take this obvious bug:

This is an obvious SQL injection bug. But is it exploitable?

Do we need to be hysterical, or can we take our time adapting the code?

BTW, notice I’m using Java because that’s the platform I’m most comfortable with. This applies to all Lightrun supported platforms/languages equally. So everything here easily applies to NodeJS, JavaScript/TypeScript, Python, Kotlin, Scala, etc.

This is trivial to test in Lightrun. We can just add a log or a snapshot that will be triggered when an invalid request happens. Then we can try sending invalid values via a curl command to see if our log is triggered.

Notice that we use a regular expression to validate the name value. If we receive a log, it means the problematic value is exploitable. This also means the risk of the security vulnerability is high.

Is it Actively Exploited?

So we found a security vulnerability like the one above. Should we panic? Are there hackers already in the system?

What do we do?

Well, we can do something similar to what we did above and add a snapshot with a similar condition and a few “tune ups”:

This image contains a lot, so let’s try to unpack it.

Why Snapshot and not Log?

Logs are great to see if something happened. They’re quick and they handle high volume well. But if someone is actively breaking into our system, we want to get all the information that’s available. Possibly even things we haven’t thought about. We want to know the vector of attack, which means knowing the call stack etc. Snapshots are an ideal security tool.

Targeting a Tag

Notice that the “Agent” entry points at “Production”. We can apply the snapshot to a group of machines based on tagging. So in this case, we can target all potentially vulnerable machines with one swoop.

Max Hit Count

Unlike a log, snapshots fill up the UI and storage. So we have a default limit of snapshots we can take before expiring the snapshot. This defaults to one normally. Here I raised it to 20 but we can probably go even higher if we’re willing.

Notice that if we see this happen and exploits are happening, we might want to switch to logs since they don’t have a hit count.

Ignore Quota

This option might not be available to you since it requires special permissions. If you’re in this situation, ask your manager for this permission.

This is a risky feature, which is why it’s guarded. But with an exploitable hack, it might be a risk worth taking.

The quota limits the amount of CPU a condition, or expression can take per Lightrun action. The risk here is that an exploit might happen and some information would be “dropped” because of CPU usage. This will mean the snapshot won’t be paused at any point and we won’t “miss” a potential exploit.

This might affect your server performance though, so it isn’t without risk.

Expiry

Lightrun actions default for one hour of expiry. We want to keep your servers fast and nimble so we expire actions that aren’t needed. In this case, we want the action there until we get the fix out. So I set the expiry value to 60 hours.

With these in place, we will get actionable information on any exploit coming our way.

Verify the Fix

Verifying the fix is pretty similar. We can place a log or a snapshot in the problematic area of the code and see if that code is reached with problematic values.

You can also add additional logging to verify that attempted exploits reach the area they’re expected to reach and are handled as you would expect.

Lightrun Security

A security tool that’s vulnerable defeats its purpose. So understanding the security measures in Lightrun is an important part of this post. Following are the high level features in Lightrun that make it so secure.

Architecture

Lightrun made several architectural decisions that significantly reduced attack vectors.

Agents only connect to the Lightrun server to fetch actions. Not the other way around. That means they are hidden completely from end users and even from the organization.

If the Lightrun server fails, an agent just does nothing. This means that even a DDoS attack that would bring down Lightrun won’t affect your servers. You won’t be able to use Lightrun, but the servers will work just fine.

Certificate pinning & OIDC

Agents and clients of the Lightrun server use certificate pinning to prevent elaborate man in the middle attacks. 

Lightrun uses OpenID Connect (OIDC) for secure proven authorization across its tools.

The Lightrun server limits user privileges based on assigned roles. Most importantly, every operation is written to an administration log. This means that a “bad actor” can’t be abusive without leaving a footprint.

Sandbox

All operations within an agent are sandboxed and have limited access. All actions are “read only” and can’t use too much CPU as we saw in the article above.

There are exceptions to these rules, but they need higher privileges to circumvent.

Block List

A malicious developer in the organization can use a snapshot or a log to get information from a running application. E.g. a snapshot can be placed in the authorization logic to steal user data before encoding. 

A block list can define files that are blocked inside Lightrun agents. These files won’t let a developer place an action within them.

PII Reduction

Personal Identifiable Information, such as credit card numbers, can be logged intentionally or unintentionally. PII reduction lets us define patterns that are risky and those will be implicitly erased from the logs. As a result, you won’t need to purge such logs and won’t expose yourself to potential regulatory liability.

TL;DR

We did not design Lightrun as a security tool. It shouldn’t replace existing security tools. But it’s a perfect sidekick to the tools you already have. It plays to their strengths and pushes the envelope of fast response to vulnerabilities/hacks.

Lightrun’s low level deep code observability lets us respond to potential threats faster and mitigate vulnerabilities sooner. 

I’m not a security expert. I’m sure that if you are, you can come up with even more amazing security related use cases for Lightrun. This is very exciting, I can’t wait to hear about them!

The post Lightrun For Application Security – Detecting, Investigating and Verifying Fixes for Security Incidents Using Lightrun appeared first on Lightrun.

But acts of testing is necessary – especially shift left testing.

Testing is often resisted by teams that are pressured by shorter release cycles tend to forgo testing altogether in order to meet deadlines. This results in lowered quality software, which can lead to security vulnerabilities and user experience due to defects.

The concept of shift left testing is popular in DevOps circles. According to an Applause survey, 86% of teams are already using a shift left approach early in the software development life cycle. It is also reported that shift left helped reduce the number of accidental bugs released and the ROI of using a shift left approach is better than fixing broken software that’s deployed.

But what is shift left testing? and why is it a vital component for your team and project’s success?

What is Shift Left Testing?

The goal of shift left testing is to find bugs as early as possible. By doing this, developers can fix these bugs before they cause major problems. By finding bugs early on, companies can avoid the costly process of fixing these bugs after they have been deployed.

In addition to this, shift left testing can improve the quality of the software. By finding bugs early, developers can make sure that they are fixed before the software is released. Shift left testing is not a new concept. However, it has gained popularity in recent years as companies have started to realize the benefits of this methodology.

Why implement a Shift Left Testing approach?

When it comes to software development, the earlier a problem is found, the cheaper it is to fix. This is the philosophy behind shift left testing, also known as shift left development or continuous testing.

The goal of shift left testing is to move testing earlier in the software development process. By doing so, problems can be found and fixed before they have a chance to cause major issues further down the line.

There are many benefits to shift left testing, including:

• Reduced costs: By finding and fixing problems early, the overall cost of development is reduced.
• Improved quality: Catch problems early, the quality of the final product is improved.
• Faster development: By testing continuously, development can move faster as there is no need to wait for a separate testing phase.
• Increased collaboration: By involving testers early on, they can provide valuable input to the development process.
• Security Remediation: Earlier detection of security issues prevents costly security breaches.

6 Essentials for successful Shift Left Testing implementation

1. Plan the testing framework

There are several ways to plan the testing framework for a shift left implementation. One approach is to use a model-based testing tool, such as Test Driven Development (TDD) or Behavior-Driven Development (BDD). These tools allow developers to write tests that are based on the behavior of the software, rather than its implementation. This makes it easier to catch errors early before they make it into the code.

2. Define coding standards

As organizations begin to adopt a shift left mentality in their development processes, it becomes increasingly important to establish and enforce coding standards. These standards help to ensure that code is consistent, readable, and maintainable.

It is also important to establish a mechanism for enforcing the coding standards. This enforcement can be done through a combination of tools and processes. Tools such as static analysis can be used to check code for compliance with the defined standards automatically. Processes such as code review can also be used to ensure that code meets the defined standards.

3. Develop a feedback process

In order to ensure that a shift left implementation is successful, it is important to develop a feedback process. This feedback process should include input from all stakeholders, including those who will be using the new system, as well as those who will be responsible for maintaining it. It is also important to solicit feedback at different stages of the implementation process, in order to get a comprehensive picture of how the system is working.

Once the feedback process is in place, it is important to act on the feedback received. This may mean making changes to the system or providing additional training to users. It is also important to keep track of the feedback received, in order to identify any trends.

4. Automate testing where possible

There are many benefits to automating testing, particularly for a shift left implementation. Automated testing can help to speed up the testing process, as well as improve the accuracy of the results. It can also help to reduce the number of manual tests that need to be carried out, which can free up time for other activities.

When deciding which tests to automate, it is important to consider the ROI (return on investment). Automating a test that is run frequently and takes a long time to complete can save a lot of time and money in the long run. Conversely, automating a test that is only run occasionally may not be worth the effort.

There are a number of tools available to help with automated testing. These include open source tools such as Selenium and Watir, and commercial tools such as HP UFT (Unified Functional Testing). The choice of tool will depend on the technology being used and the preferences of the team.

5. Bring testers into the initial SD stages

Bringing testers into the initial stages of development can be a challenge, but it is essential for a successful shift left implementation. Here are a few tips for getting started:

Define what you need from testers.

Before you can bring testers into the fold, you need to know what you need from them. What types of testing will they be doing? What are your expectations for turnaround time? By being clear about your needs upfront, you can avoid any confusion or frustration later on.

Communicate the benefits of shift left.

Once you know what you need from testers, make sure to communicate the benefits of shift left to them. Explain how moving testing earlier in the process can help to identify and resolve issues more quickly. emphasize how this will ultimately lead to a better experience for users.

Train testers on the new process.

If you want testers to be successful in the new process, it is important to provide them with training. Teach them about the different types of testing that will be conducted and how to best go about it. Also, be sure to give them plenty of opportunities to practice so that they are comfortable with the new process before go-live.

Set up a feedback loop.

As with any new process, it is important to set up a feedback loop so that you can continuously improve. Make sure to solicit feedback from testers after each round of testing. What went well? What could be improved? By constantly tweaking and improving the process, you can ensure that it is as effective as possible.

Bringing testers into the initial stages of development can be a challenge, but it is essential for a successful shift left implementation. By following these tips, you can set your team up for success.

6. Make use of observability platforms

Observability platforms like Lightrun are tools that help developers monitor their applications in real-time, identify issues, and quickly fix them.

There are many different observability platforms available, each with its own set of features. However, all observability platforms share some common features that can be used to implement a shift left strategy.

Some of the most common features of observability platforms include:

• Logging: Collect and store application logs for analysis.
• Monitoring: Monitor application performance and identify issues in real-time.
• Tracing: Trace the path of a request through the application to identify bottlenecks.
• Alerting: Set up alerts to notify developers of issues as they happen.

Summary

It’s easy to get lost in the benefits of shift left testing – from shorter timelines, fewer bugs, increased software integrity, and lowered long-term costs – shift left testing is a vital component in a devOps team toolkit.

There are many platforms that implement different processes inside a shift left methodology with Lightrun being the platform for implementing observability.

Why leave the surface bubbling up of bugs up to chance? It’s easy to be proactive and give your devOps team internal visibility with the help of Lightrun. 

The post Shift Left Testing: 6 Essentials for Successful Implementation appeared first on Lightrun.