Lightlytics enables cloud operation teams to incorporate their tribal knowledge into our system in the form of predefined and custom rules to ensure the collective experience of the team is taken into consideration for any configuration change at any time. Additionally, Lightlytics provides predefined guardrails for security, availability, and cost management right out of the box.
These rules will be applied and enforced after the initial connection of the AWS account into our system, and will show the violations throughout the entire pipeline -
Starting from the moment a change is planned (Discovery) through the pull request phase (Simulation) to the real-time events change log (Events).
In today’s landscape, There are many IaC analysis tools that cover the build, and cloud scanners (CSPMs) that cover the runtime.
DevOps are required to analyze who made the change, the impact radius and the actual severity of the alert. This becomes extremely difficult and time-consuming as the organization grows and expands its infrastructure. If a fix is needed, it is necessary to consider what will happen to all the related resources that utilize the problematic resource, which is a difficult task by itself.
Due to the fact that Lightlytics integrates into your existing pipeline, DevOps engineers can now understand how a certain change will impact existing infrastructure while examining violations according to the predefined and custom rules that are configured in the system. Combining these capabilities with Lightlytics Events, DevOps engineers can perform Root Cause Analysis completely by themselves in a short period of time.
This ability can save a lot of time handling internal cycles within the DevOps departments - an infrastructure change might lead to issues in multiple vectors, such as Security, Cost, Availability and others. Today, in case of an issue, a ticket is opened by the relevant team to the DevOps team, which made the infra change originally.
Lightlytics allows DevOps engineers to avoid these various misconfigurations before they become actual issues and eliminates the time consuming internal process between the various departments.
In addition, the fact that these rules are constantly being enforced, Infrastructure engineers can delegate more responsibilities and abilities to other teams like developers, so they can create, modify and destroy infrastructure with confidence.
Lightlytics introduces a new and efficient method to increase confidence and reduce time while keeping your organization’s architectural standards enforced:
Lightlytics Architecture standards - Enforce misconfigurations, availability and security violations
Out-of-the-box, Lightlytics provides best-practice policy rules that are enforced both in the Terraform simulation phase and in real-time.
In the Simulation (Pull request) phase, Lightlytics will inspect the Terraform’s code proposed change and will alert when a violation is detected according to the existing rules in the system.
In addition, if a violation was detected in the Simulation phase, Lightlytics has the ability to automatically fail the Pull request and alert accordingly.
In real-time, after deploying the code or even creating/modifying something via the AWS UI, Lightlytics will inspect the actual CloudTrail events and alert if a violation was detected.
Lightlytics is also capable of sending notifications to Slack/ Email/ any other 3rd party tool in case of a violation.
Here are some examples that can be picked up before/after deploying the IaC code by using Lightlytics:
The greatest advantage of using Lightlytics - Context! on every violation we provide the full context (dependencies) of the resource and the overall impact of the violation, including all the activity and past changes to the resource.
Efficiently understand downstream dependencies to decide how severe the exposure is (resources is exposed on port 22 and has downstream access to OpenSearch)
This ability allows various cloud operation teams to create and enforce custom rules according to their business logic.
Lightlytics also enforces these rules cross accounts and regions.
You can create rules based on specific source, destination, intermediate components and even based on tags, locations and ports.
There are two types of rules that can be created in the system -
Path based rule:
With path-based rules, you can define rules based on source, destination and intermediate components while combining resources specific attributes, location, tags and ports.
For example, you would like to restrict all traffic between a production vpc and a development vpc:
Resource-based rule:
With resource-based rules, you can define rules based on a resource type with specific attributes and tags and enforce them on a specific action.
For example, you want to be alerted in case an instance that is running Jenkins in a certain vpc does not use the dedicated tested ami:
Violations and Alerts:
Inspect the various violations across your entire pipeline, from planning to the execution phase:
You can examine resource violations in the Discovery screen and handle them appropriately :
Examine violations in real-time events - Inspect violations according to the rules configured with each API call in your cloud environment:
Examine violations in the Simulation phase - Inspect violations of every commit when Lightlytics Simulation is triggered
Combining the Lightlytics simulation with custom rules and policies enforcement, we can help you save time, reduce cycles and make time for the work that matters before tasks add up.
Cloud, Kubernetes, Entitlements, and all their dependencies are managed in one platform at Build (Infrastructure-as-Code (IaC)) and Runtime.
