It is well known that IaC (Infrastructure-as-Code) is becoming an increasingly important strategy associated with DevOps and CloudOps practices. Tools such as Terraform and CloudFormation allow software-defined infrastructure to be deployed quickly and repeatedly to the public cloud infrastructure.
As a result of this emerging technology, IaC deployments are not always tested correctly, or sometimes not at all, leading to misconfigurations that reach production environments.
Misconfigurations can range from small to severe, potentially putting an organization at risk of downtime, data breaches or failure of compliance with regulations.
Static code analysis for IaC
Many teams review IaC by multiple functions (Ops and Sec) manually. However, in the past years, we have seen a proliferation of static code analysis tools that reduce the amount of work needed to verify security-related impacts. (such as Kicks by Checkmarx, Checkov by Bridgecrew, TFsec by Aqua, WIZ CLI, Orca CLI, Snyk, OPA and others ).
Static code analysis is a way for Infrastructure engineers to test their code without actually executing it — this is called a non-run-time environment. Static code analysis tools offer a nice way to find Infrastructure faults and display them to DevOps engineers. Using it, errors can be picked up long before they end up causing havoc when the code is released to our cloud account.
Despite their technological advances, there is a major downside to this method, which is the lack of context. These tools miss the ability to merge the build state with the run-time state. As a result, many issues remain undetected because they only provide a partial picture.
False positives become common as these tools do not understand the cloud posture (relationships between resources).
As an example, A violation was triggered when someone opened port 22 on 0.0.0.0/0 rule in a security group. A “CRITICAL” alert was triggered however the security group is not attached to any resource, and no actual security violation has been generated. Without taking posture into account, false positives and false negatives are generated. Both of these contribute to noise, as well as missing significant violations.
Another example might be a critical alert on the fact that an RDS instance has “publicly_accessible” set to true, however, the RDS instance is not exposed to the internet at all as it is located in a private subnet and its security groups allow specific internal IPs.
Another major pain point for cloud security and operation teams is the unnecessary cycles between them.
A DevOps engineer performed a change that caused a security violation. After the violation is detected, the security team investigate the violation and opens a ticket to the DevOps team that owns the infrastructure. Now the DevOps team is required to analyze who made the change, the impact radius and the actual severity of the alert. 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.
Lightlytics eliminates these unnecessary cycles and helps DevOps and Cloud security teams focus on the work that matters, allowing teams to easily adopt the shift-left approach to security (DevSecOps), availability, cost and overall impact analysis of terraform commits.
Our engine covers both build and runtime with the same rules while providing all the necessary context to reduce time and increase confidence.
Foresee the impact of every proposed change on your entire cloud posture and services. simulate changes at the posture level prior to deployment, as we take both build and runtime into consideration, by doing so we eliminate unnecessary noise, false positives, and detect dependencies that are unseen by static code analysis tools, while enforcing custom rules according to the organization’s business logic on top of out of the box best practices.
Efficiently understand downstream dependencies to decide how severe the exposure is (resources is going to be exposed on port 22 and will have downstream access to OpenSearch and RDS)
Build and Runtime are calculated against every commit:
With each configuration change, in real-time or in the build phase, Lightlytics provides the full context regarding who made the change, to what, and more importantly - how it affected your existing infrastructure across multiple verticals such as Availability, Security and even cost.
On top of the above Lightlytics is the only tool on the market that is capable of alerting on availability impacts based on current application behavior so in case a change is made to an actively used resource you will get all the data you need as part of the commit.
