Sep 14 2024

How to make Infrastructure as Code secure by default

The article explains how to enhance the security of Infrastructure as Code (IaC) by default. It emphasizes integrating security policies into CI/CD pipelines, automating IaC scanning, and using the application as the source of truth for infrastructure needs. It highlights the risks of manual code handling, such as human error and outdated templates, and discusses the challenges of automated remediation. The solution lies in abstracting IaC using tools that generate infrastructure based on application needs, ensuring secure, compliant infrastructure.

Read more here.

Making Infrastructure as Code (IaC) secure is crucial for maintaining the security of cloud environments and preventing vulnerabilities from being introduced during deployment. Here are some best practices to ensure the security of IaC:

1. Use Secure IaC Tools

  • Trusted Providers: Use reputable IaC tools like Terraform, AWS CloudFormation, or Ansible that have strong security features.
  • Keep Tools Updated: Ensure that your IaC tools and associated libraries are always updated to the latest version to avoid known vulnerabilities.

2. Secure Code Repositories

  • Access Control: Limit access to IaC repositories to authorized personnel only, using principles of least privilege.
  • Use Git Best Practices: Use branch protection rules, mandatory code reviews, and signed commits to ensure that changes to IaC are audited and authorized.
  • Secrets Management: Never hardcode sensitive information (like API keys or passwords) in your IaC files. Use secret management solutions like AWS Secrets Manager, HashiCorp Vault, or environment variables.

3. Enforce Security in Code

  • Static Code Analysis (SAST): Use tools like Checkov, TFLint, or Terraform Sentinel to analyze your IaC for misconfigurations, like open security groups or publicly accessible S3 buckets.
  • Linting and Formatting: Enforce code quality using linters (e.g., tflint for Terraform) that check for potential security misconfigurations early in the development process.

4. Follow Least Privilege for Cloud Resources

  • Role-based Access Control (RBAC): Configure your cloud resources with the minimum permissions needed. Avoid overly permissive IAM roles or policies, such as using wildcard * permissions.
  • Security Groups: Ensure that security groups and firewall rules are configured to limit network access to only what is required.

5. Monitor and Audit IaC Changes

  • Version Control: Use version control systems like Git to track changes to your IaC. This helps maintain audit trails and facilitates rollbacks if needed.
  • Automated Testing: Implement continuous integration (CI) pipelines to automatically test and validate IaC changes before deployment. Include security tests in your pipeline.

6. Secure IaC Execution Environment

  • Control Deployment Access: Limit access to the environment where the IaC code will be executed (e.g., Jenkins, CI/CD pipelines) to authorized personnel.
  • Use Signed IaC Templates: Ensure that your IaC templates or modules are signed to verify their integrity.

7. Encrypt Data

  • Data at Rest and In Transit: Ensure that all sensitive data, such as configuration files, is encrypted using cloud-native encryption solutions (e.g., AWS KMS, Azure Key Vault).
  • Use SSL/TLS: Use SSL/TLS certificates to secure communication between services and prevent man-in-the-middle (MITM) attacks.

8. Regularly Scan for Vulnerabilities

  • Security Scanning: Regularly scan your IaC code for known vulnerabilities and misconfigurations using security scanning tools like Trivy or Snyk IaC.
  • Penetration Testing: Conduct regular penetration testing to identify weaknesses in your IaC configuration that might be exploited by attackers.

9. Leverage Policy as Code

  • Automate Compliance: Use policy-as-code frameworks like Open Policy Agent (OPA) to define and enforce security policies across your IaC deployments automatically.

10. Train and Educate Teams

  • Security Awareness: Ensure that your teams are trained in secure coding practices and are aware of cloud security principles.
  • IaC-Specific Training: Provide training specific to the security risks of IaC, including common misconfigurations and how to avoid them.

By integrating security into your IaC practices from the beginning, you can prevent security vulnerabilities from being introduced during the deployment process and ensure that your cloud infrastructure remains secure.

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot

Tags: Secure By Design, Secure Code, Secure Infrastructure


Sep 15 2022

Organizations should fear misconfigurations more than vulnerabilities

Category: Security vulnerabilitiesDISC @ 8:43 am

Censys launched its State of the Internet Report, a holistic view into internet risks and organizations’ exposure to them.

Through careful examination of which ports, services, and software are most prevalent on the internet and the systems and regions where they run, the research team discovered that misconfigurations and exposures represent 88% of the risks and vulnerabilities across the internet.

“Assessing the state of the internet is crucial in understanding an organization’s own risks and exposures,” said Zakir Durumeric, Chief Scientist of Censys.

Key findings

  • Misconfigurations â€“ including unencrypted services, weak or missing security controls and self-signed certificates – make up roughly 60% of observed risks. When analyzing the risk profile of organizations across industries, missing common security headers accounted for the primary security error.
  • Exposures of services, devices, and information represent 28% of observed risks. This includes everything from accidental database to device exposures.
  • Critical vulnerabilities and advanced exploits only represent 12% of observed risks. When analyzing organizations by industry, the Computer and Information Technology industry had the widest spread of different risks, while Freight Shipment and Postal Services had the second widest.

Researchers also conducted a holistic assessment of the internet’s response to three major vulnerabilities – Log4j, GitLab and Confluence – to understand mitigation strategies based on how a vulnerability is perceived. From this analysis, Censys learned how the internet responds differently to vulnerability disclosures.

Three distinct types of behavior in response to vulnerability disclosures

  • Near-immediate upgrading: Systems vulnerable to Log4j acted quickly based on the widespread coverage of the vulnerability. By March 2022, Censys observed only 36% of potential vulnerable services were left unpatched.
  • Upgrading only after the vulnerability is being actively and widely exploited: While the GitLab vulnerability was being exploited, the remediation process acted slower than others until researchers discovered a botnet composed of thousands of compromised GitLab servers participating in DDoS campaigns.
  • Near-immediate response by taking the vulnerable instance off the internet entirely: Rather than upgrading, users chose to remove assets entirely from the internet after Confluence’s vulnerability became public between June 2021 and March 2022.

The internet constantly evolves as new technologies emerge, vulnerabilities are discovered, and organizations expand their operations that interact with the internet. Security teams have the responsibility to protect their organizations’ digital assets and need proper visibility into the entire landscape to do so.

Although vulnerabilities often garner the bigger headlines, it’s undetected misconfigurations and exposures that create the most risk for an organization, making it important to regularly assess any new hosts or services that appear in your infrastructure. Regardless of vulnerability type, providing organizations with the visibility and tools needed to strengthen their security posture introduces a proactive, more vigilant approach to digital risk management.

World

Secure By Design

Tags: misconfigurations, Secure By Design


Dec 16 2021

While attackers begin exploiting a second Log4j flaw, a third one emerges

Category: App Security,Log4j,Security vulnerabilitiesDISC @ 9:54 am

Experts warn that threat actors are actively attempting to exploit a second bug disclosed in the popular Log4j logging library.

American web infrastructure and website security company Cloudflare warns that threat actors are actively attempting to exploit a second vulnerability, tracked as CVE-2021-45046, disclosed in the Log4j library.

The CVE-2021-45046 received a CVSS score of 3.7 and affects Log4j versions from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 (which was released to fix CVE-2021-44228).

The Apache Software Foundation (ASF) has already released a patch for the Log4Shell vulnerability (CVE-2021-44228), but this fix partially address the flaw in certain non-default configurations. An attacker with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) can craft malicious input data using a JNDI Lookup pattern triggering a denial of service (DOS) condition.

Both issues were assessed with the release of Log4j 2.16.0 version that addresses the CVE-2021-45046 by removing support for message lookup patterns and disabling JNDI functionality by default.

“Hot on the heels of CVE-2021-44228 a second Log4J CVE has been filed CVE-2021-45046. The rules that we previously released for CVE-2021-44228 give the same level of protection for this new CVE.” states CloudFlare.”This vulnerability is actively being exploited and anyone using Log4J should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0. The latest version can be found on the Log4J download page.”

The bad news are not ended, because researchers at security firm Praetorian warned of a third security vulnerability the Log4j version 2.15.0 that was released to fix the initial Log4Shell.

This third vulnerability can be exploited by attackers to exfiltrate sensitive data in certain circumstances.

“However, in our research we have demonstrated that 2.15.0 can still allow for exfiltration of sensitive data in certain circumstances. We have passed technical details of the issue to the Apache Foundation, but in the interim, we strongly recommend that customers upgrade to 2.16.0 as quickly as possible.” states the post published by Praetorian.

This image has an empty alt attribute; its file name is image-13.png

Secure By Design

Secure Software Development Fundamentals Professional Certificate

Tags: Log4j, Log4shell, Secure By Design


Dec 15 2021

Log4Shell: A new fix, details of active attacks, and risk mitigation recommendations

Category: Log4j,Security vulnerabilitiesDISC @ 1:22 pm

New versions of Log4j

The recent discovery of a second Log4j vulnerability (CVE-2021-45046) has shown that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.

This vulnerability could allow attackers to craft malicious input data using a JNDI Lookup pattern, resulting in a denial of service (DoS) attack.

“Note that previous mitigations involving configuration such as to set the system property ‘log4j2.noFormatMsgLookup’ to ‘true’ do NOT mitigate this specific vulnerability,” the Apache Log4j security team noted.

“Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).” The team advises users either to upgrade to version 2.12.2 (for Java 7) or 2.16.0 (for Java 8 or later), in which the Message Lookups feature has been removed and access to JNDI has been disabled by default, and explained why some of the mitigation measures shared a few days ago are incomplete.

Active exploitation

PoCs are constantly popping up on GitHub and getting forked. GitHub is steadily working on removing them, but the proverbial cat is now out of the bag, and there is no going back.

Exploitation attempts detected so far in the wild can be tied to ransomware groups and access brokers, botnet herders (delivering coin miners), and nation-backed APTs.

“The way modern products are built is using a big hierarchy of dependencies, where developers use libraries written by third-party companies and engineers to speed up the software release process. Log4J is an extremely basic library that allows log writing in Java applications. The way CVE-2021-44228 affects comes in 3 layers – cloud products that directly use the Log4J, web applications that use libraries that use Log4J, and off-the-shelf software which is internally deployed on customer servers and endpoints,” says Michael Assraf, CEO at Vicarius.

“As fixing and deploying cloud applications can be fast, updating libraries that use Log4J can break functionality unless done with caution. The most problematic fixes are internally deployed software, which will have to wait for a vendor update or a security patch, in that scenario customers are advised to wait on further vendor guidance and as of right now are helpless in reacting. Examples include: Elasticsearch, Intellij IDE, Jira Confluence, Apache Tomcat, Minecraft, Apache Hadoop, Eclipse IDE, and many more.”

Gallagher says that the most immediate priority for defenders is to reduce exposure by patching and mitigating all corners of their infrastructure and investigate exposed and potentially compromised systems.

“Where systems have been identified as vulnerable, defenders should run an incident response process and monitor for signs of remote access trojans such as C2 call-backs. Secrets stored on exposed systems should also be rotated, particularly if they are exposed in environment variables. Lastly, consider critical third party vendors who may also be at risk,” he advised.

Mathew Eble, VP of Services at Praetorian, also warned the issue will be prone to false negatives.

“Externally there is no way to cover all the possible paths that exploitation can take. Even when external scanning tools get more sophisticated in how they identify the issue, we strongly advocate not relying on scan results as strong indicator of your risk,” he noted.

This recommendation is based on four issues the company has confirmed when working with customers. Based on this, they have expanded their initial recommendations for defenders.

Log4Shell mitigation

Secure By Design

Secure Software Development Fundamentals Professional Certificate

Tags: Log4j, Log4shell, Secure By Design