“If everything seems under control, you’re not going fast enough.”

With the recent rise in cloud-native technologies, everything is going faster than ever. Development cycles are shorter than before, and teams are deploying to production continuously. Business demands and time-to-market are the main drivers in the need for speed, and as development teams try to keep up, the risks are much higher since a simple change can reach your entire customer base within minutes.

One of those cloud-native technologies is Infrastructure-as-Code (IaC) which automates the entire process of provisioning and deploying your infrastructure at the speed of DevOps. Beside the known benefits, this presents major risks to your applications and underlying infrastructure. It means that a single change in your IaC will reach production in a matter of minutes and can expose you to new attack vectors as well.

Based on recent research, which was done by analyzing vast number of KICS scans, here are the top IaC misconfigurations you should be aware of.

Top 5 Misconfigurations

1. Open ports – open TCP/UDP ports remain the top misconfiguration to date. Those include HTTP ports, SSH ports, ELB ports, or any other unnecessary ports. The best example to give here is SSH (port 22), which is usually used for remote debugging and is notoriously known for being left open for no good reason. Probing through open ports is probably the first step of every attacker’s TTPs. We also know that attackers use bots to scan for open ports, and once they find an open one, they simply brute force the password and often gain access to servers and other devices. Make sure you leave unnecessary ports closed, or have a good reason for why they may be open.
2. Excessive permissions – as previously written in this blog, providing a cloud resource with the wrong permissions can create the attack surface attackers are hoping for. Configuring your S3 bucket with read permissions, attackers can probe into the bucket looking for unprotected content and gain access to private information. Make sure you understand what least-privilege permissions your cloud resources need, and don’t leave anything to chance.
3. Lack of proper definitions – this affects observability (e.g., lack of proper logging), encryption (e.g., S3 objects without server-side encryption), or anything in between. Make sure you understand which resource requires which property, and make sure they are configured correctly in all cases.
4. Hard-coded secrets (in your IaC) – while not limited to IaC only, this remains a top challenge for all code (application source code as well). Once exposed, attackers can leverage the keys to obtain sensitive information, shut down services, or create whatever resources they need.
5. IaC security drift – we have all been there, we work perfectly through the process, our pipelines are all green, then something happens in production, and we must make a “small” change. Those small changes can have a huge risk on your environment, and you should not make those directly but through code. Using drift detection tools (e.g., Terrarfomer or Driffty), you can get a static file which represents your current production environment, then scan it with KICS to make sure you didn’t introduce any new risk.

Leveraging Infrastructure-as-Code is a critical part of achieving true infrastructure agility, but you should be aware of all the risks. Running fast is important, but don’t become blind to what may surface from errors and omissions. Be aware of the potential misconfigurations listed above and make sure you tackle them from the very beginning.

If you want to automate your IaC security scanning – you can easily integrate KICS into your pipeline and make sure you are appropriately managing your IaC risks.

More about KICS

KICS finds security vulnerabilities, compliance issues, and infrastructure misconfigurations in popular IaC solutions and OpenAPI 3.0 specifications. KICS is open source and always will be. Both the scanning engine and the security queries are clear and open to the software development community. With 2000+ fully customizable and adjustable heuristic rules, or queries, KICS can be easily edited, extended, and added to. What’s more, our robust but simple architecture allows for support of new IaC solutions.

Almost 500,000 people are already taking advantage of KICS. Download KICS for free here and start securing your IaC today!

According to their website, “The Center for Internet Security, Inc. (CIS®) makes the connected world a safer place for people, businesses, and governments through our core competencies of collaboration and innovation.  We are a community-driven nonprofit, responsible for the CIS Controls® and CIS Benchmarks, globally recognized best practices for securing IT systems and data.”

In our connected world, the need for collaboration, innovation, and best practices are vastly needed. In fact, CIS has four world-renowned, best practices and expert communities.

Going a little deeper into one particular area of interest, “CIS SecureSuite Membership provides integrated cybersecurity tools and resources to organizations of every size. Security IT teams can automate configuration assessments, conduct remote scans, implement security best practices, and more.”

Why is CIS Important to Checkmarx and the Developer Community?

KICS is an open-source project backed by Checkmarx that is purposely designed to scan infrastructure as code (IaC). KICS has had an incredibly successful launch with over 450K downloads as of date!

More importantly, Checkmarx is a CIS SecureSuite® Product Vendor Member, and our KICS solution has recently been awarded the following certifications from CIS:

KICS 1.4.4 (version)

• CIS Amazon Web Services Foundations Benchmark v1.4.0, Level 1
• CIS Amazon Web Services Foundations Benchmark v1.4.0, Level 2

We are extremely proud to have been awarded these certifications, and achieving Level 2 certification is a very notable achievement. Level 2 means that a technology provides “measurable defense in depth” protection.

From a static tool perspective, KICS performed exceptionally well in all evaluation criteria. Although some may say that not being a dynamic solution (testing code while running) is a limitation, KICS scans code much earlier than any dynamic testing solution ever could. KICS gets results and solves issues in IaC way earlier in the pipeline – from the first line of code written – long before the first docker, first container, or first asset were even provisioned. This is a huge differentiator in comparison to dynamic testing solutions.

According to Ori Bendet, Head of Product Management at Checkmarx, who helped spearhead the KICS project, “KICS supports the philosophy of shifting left by testing and securing code as early in the cycle as possible. Developers carry so much responsibility these days—from source code to integrating open source libraries, to containers and Infrastructure-as-Code. Each of these tasks possess its own security risks. From the first line of code developers write, Checkmarx delivers SAST, SCA, and KICS to shore up security on static code, open source code, and infrastructure as code. Combing these solutions, and using them early and often, organizations can feel confident that the code they deploy is secure.”

“As of yet, KICS is the only, completely open source project that has achieved any CIS Certification”, says Erez Yalon, Head of Security Research at Checkmarx. “This serves as a testament to what the open source community is capable of achieving. Checkmarx is very happy to have initiated the project, then opening it up to the community for their contribution. Our list of contributors should receive many thanks for what they have accomplished.”

Want to Know More About KICS?

Just like SAST that scans application source code, finding vulnerabilities and security issues within, KICS scans infrastructure code to finds issues that may lead to potential vulnerabilities as well. Since KICS is open source, you don’t need any licenses to use it. You can just go to the repository or download it from Docker Hub, and you can have it up and running in as little as a few minutes, to start scanning your infrastructure code. Also, KICS integrates into a wide variety of CI/CD solutions.

KICS finds security vulnerabilities, compliance issues, and infrastructure misconfigurations in popular IaC solutions and OpenAPI 3.0 specifications. KICS is open source and always will be. Both the scanning engine and the security queries are clear and open to the software development community. With 2000+ fully customizable and adjustable heuristic rules, or queries, KICS can be easily edited, extended, and added to. What’s more, our robust but simple architecture allows for support of new IaC solutions.

Download KICS for free here and start securing your IaC today!

However, the devil is in the details and trying to implement those tools in real life often comes with risks. In this article we explain those risks with using IaC, coming from a developer’s point of view.

Biggest Risks of IaC

Steep learning curve

To start with, using IaC tools without taking the dedicated time to learn some of their quirks and limitations can become not just an inconvenience, but a serious problem.

Many of the most prevalent IaC tools like – Terraform and CloudFormation – are incredibly simple to start. But they become very complicated as your requirements change over time. For example, trying to utilize custom resources in CloudFormation requires some insight into how CloudFormation works under the hood. Failure to delve into the inner details will put your organization at increased risk of configuration drift, pushing the wrong infrastructure components or obtaining a system in an incomplete state.

Another example that requires some deep insight of how Terraform works is with Terraform Imports. The official page mentions in the warning box that:

“If you import the same object multiple times, Terraform may exhibit unwanted behavior“

However, you will need to delve into the details in order to understand the nature of this unwanted behavior. What does it really mean? Does it create configuration drift? Does it break the local tfstate file? How can you prevent importing the same object multiple times? All of those questions need time and dedication to answer. As a developer, you should reserve that time as part of the process of learning the tool while using it for real projects.

Human mistakes

Some IaC tools have a distinct set of phases that you need to perform in a specific order. For example, in Terraform we have the following steps:

1. terraform plan : Creates an execution plan for what terraform will perform against the infrastructure.
2. terraform apply : Applies the plan.

Failure to perform a plan review before using apply can result in destructive changes. This is because a visual inspection beforehand gives you one more chance to review the changes before applying. The caveat here is that, by default, there is no requirement to follow the order. Directly applying the changes, skipping the first step, could lead to unfortunate mistakes.

The repercussions of missing a destructive change can be excruciatingly painful. It is recommended that you invest in establishing automated protections to apply changes to infrastructure. For example, instead of manually reviewing terraform plan outputs (which could be lengthy), you should invest in PR (pull request) automation tools like Atlantis to help in discovering any unintentional destructive changes early.

Configuration drifts

Terraform and other tools can help in maintaining infrastructure components and associated attributes, as long as they are managed solely by them. For example, Terraform cannot detect any drift of resources if you have applied while using other tools like Chef or Puppet. This could be a major problem for organizations still working on a variety of IaC tools that are unaware of each other or overlap their body of work.

Scanning for drift helps with figuring out those deviations between the IaC tool and the real infrastructure. Because each case is different, you will find there are virtually no public or private services that do that for you accurately. The best option for managing configuration drift for your organization is to make sure there is no overlap between the various IaC tools; any changes to the infrastructure are monitored by one IaC tool; and some sort of reporting and health checking are integrated. External checks can also sometimes help to verify that.

Difficulty protecting sensitive data and exposing ports

Although Terraform and CloudFormation can provision infrastructure components, there are some questions that need answering. For example, how would you know during the process if it leaked sensitive data? How would you know if the S3 bucket it manages in fact contains the security profiles you specified? Are you using a provider that leaks sensitive data to stdout? Did you unexpectedly open a port to the internet?  

These are only a subset of questions you need to answer when delegating your Infrastructure management to IaC tools. It’s easier to make a mistake and expose resources to the public web than the opposite, so there are a lot of things at stake here.

[In fact, in an analysis done by Checkmarx in August 2021, one of the most common IaC misconfigurations is having HTTP port 80 and ELB ports being left open to the public.]

How Should Developers Detect and Mitigate the Most Common IaC Risks?

As mentioned, most of the common risks can be mitigated by adhering to some common security best practices so it’s not all doom and gloom. Here is what you can start practicing:

• Spend some time with the tools: Spend time to fully understand how each tool works: its quirks, its open issues and its best practices. Participate in meetups and subscribe to events so you can learn from other industry experts. This will give you an advantage when trying to figure out how to perform tasks – simple and advanced – without compromising the security posture.
• Establish common engineering processes and best practices: Practice peer code reviews, CI/CD checks, linting, and verification. This can reduce the number of common accidents and mistakes that happen when you rush things.
• Use purpose-built IaC security tools: Look around for purpose-built tools like Checkmarx KICS (Keeping Infrastructure as Code Secure) that help you establish a secure and efficient infrastructure-as-code pipeline. The benefit of this tool is that you can configure it to match your organization’s policies due to its great extensibility and cloud provider coverage.

[If you are looking to get a quick look and better understanding on your current state, you can also quickly upload your IaC into Checkmarx new KICSaaS and get immediate results without having to download anything. Give it a try at: https://kics.checkmarx.net]

How and Where Can Developers and Security Teams Learn More About the Risks?

First and foremost, you can learn more about the risks of IaC by asking local IaC experts or official communities about some of their experiences with IaC. You may find that many of the issues they encounter prepare you for what to expect and what to look out for.

Furthermore, you should subscribe to reputable email lists and blogs from vendors that specialize in those areas, and offer tailored solutions like KICS for tackling most of the problems explored in this article.

Lastly, you should perform your own investigation to assess the pros and cons of each tool based on your own requirements and success criteria. The one-size-fits-all approach isn’t suitable for all lines of business. By performing all the necessary steps, you can hopefully mitigate most of the critical risks of using IaC tools.

—

Theo Despoudis is a Senior Software Engineer, a consultant and an experienced mentor. He has a keen interest in Open Source Architectures, Cloud Computing, best practices and functional programming. He occasionally blogs on several publishing platforms and enjoys creating projects from inspiration. Follow him on Twitter @nerdokto. He can be contacted via http://www.techway.io/.

Download our Ultimate Guide to SCA here.

Orchestration, in this context, deals not only with the way microservices communicate or are composed, but also with infrastructural needs or specific configurations. While not long ago the provisioning of infrastructure and configuration was mostly a manual process, nowadays, and with the advent of the DevOps mindset, automation is pervasive and defined in code. Welcome to the era of Infrastructure as Code (IaC).
IaC establishes a methodology with tools and technology for infrastructure configuration and provisioning through code. It brings advantages such as: automation, idempotence (e.g., replication of infrastructure for testing and production), consistency, self-documentation, cost-reduction, to mention but a few. However, similarly to traditional software development, it is prone to issues like misconfigurations or security vulnerabilities which may jeopardize not just a specific application, but on a much larger scale, the entire business and its underlaying infrastructure.

Did anybody mention code and vulnerabilities?

Introducing KICS (Keeping Infrastructure as Code Secure): An open-source standalone engine powered by Checkmarx – a market leader in static code analysis – for detecting vulnerabilities, compliance issues, or misconfigurations from IaC in the context of cloud-native applications.  As of its launch date, KICS comes with 1000+ security rules (queries in Cx language), supporting Terraform, Kubernetes, Docker, AWS CloudFormation, and Ansible across multiple cloud providers (e.g., AWS, Google Cloud or Microsoft Azure).

How we made KICS!

In the beginning, KICS had only 50 queries, resided in a private repository, and existed as a standalone engine. At this time, the engine was able to read just a few IaC file types, convert them into an internal representation, and produce results in a JSON format.
To make it a product, an ambitious goal was set with the objective of reaching 1K REGO/OPA queries in less than three months, and making it completely open source in less than two. It could have been easy if the full team were already on board, but we were far from it.

KICS Rules – the Students Taskforce

Within two weeks we were able to recruit a group of talented students to join the team and focus on creating more rules developed using REGO.
REGO/OPA is a high-level declarative language for querying structured documents. For this reason, it was chosen to be the method for obtaining the IaC scan rules. The students picked up the development with ease using REGO and in less than a week of training, they were crafting rules and IaC samples – one true-positive and one true-negative per query –, following the recommended list of vulnerabilities and descriptions provided by the Checkmarx application security research team.

• Our target of creating 1000 rules was a major challenge. We adapted our processes and designs and created reusable libraries to avoid replication in our REGO code.

Ironically enough, with these in place, the bottleneck became the approval of Pull Requests rather than the development itself. By the deadline, not only the 1K queries milestone was reached, it was surpassed (~1.2K).

KICS Core – The Open-Source Quest

The initial focus of the core team was to make KICS completely open source.
With the close supervision and valuable pieces of advice from our OSS consultant, Lior Kaplan, who accompanied the project, we broke the dependencies with the private repository, rewrote the commit history to make it agreeable, and moved it to the public GitHub repository https://github.com/Checkmarx/kics, under Apache 2.0 license.
During this process, we created CI pipelines with GitHub Actions, keeping all KICS infrastructure within the Github environment. In no time, a battery of verifications was running, per Pull Request, in the pipeline. It addresses several quality aspects:

• Test coverage (with Codecov)
• Code quality (with SonarCloud and Codacy)
• Security (with CxSAST by Checkmarx and KICS itself, via KICS GitHub action)

All these verifications are surprisingly fast, taking about one minute – the time needed to have KICS ready for release after each successful Pull Request.
Provided that the quality grade passes in each CI step, KICS can be released at any time. Following open-source best practices, we produce:

• One nightly release, named with the hash of the corresponding commit.
• One official release every two weeks, using the SemVer standard.

Each KICS release includes bare sources, binaries for Windows, Linux, and MacOS, as well as a docker image made available on DockerHub.

KICS Documentation – Sharing the wealth

KICS works. It has a strong core able to analyze many types of IaC files and it has thousands of security rules. It is consistently released every two weeks; it is open source, and the team is proud of it! We just need to spread the word to the world!
For that matter, we built a website, and stored it in AWS. But that is only the beautiful landing page. The documentation site is generated on the fly, via MkDocs, from markdown files, and made available via GitHub pages.
We try to make KICS documentation as crystal-clear as possible, containing everything about the project, including roadmaps, tutorials on how to use, or how to contribute. Moreover, we set up a KICS community using Gitter. Some fellows started commenting outward, asking questions, and providing feedback right away.

KICS Management – Taming the beast

The team works in an agile way, following a Kanban approach. Managing the work this way becomes easy as we can naturally take advantage of GitHub integrated management capabilities.
We divided the work into projects and defined milestones to better organize the issues and requests to handle. Labels are applied to each opened issue allowing an easy understanding of their nature: bugs, features, security, query, enhancements, you name it.
To guide and better manage contributions from KICS users, we defined templates for bugs, features, new queries, and pull requests. With templates, we require important information and ultimately standardize the quality with which work is described.
Overall, KICS involves a multidisciplinary team of architects, developers, DevOps, and managers. It already has a few followers’ contributions and many more are expected soon.  And you, dear reader, are more than welcome to contribute as well. It does not matter whether it is by just following the project, providing feedback, opening issues or feature requests, submitting code changes, or just using KICS to keep your IaC secure.