devopsy.kinsta.cloud

Tag: AWS security

  • Orca Security Achieves AWS Security Competency Status

    Standout Achievement Demonstrates Orca Security’s Technical Proficiency And Customer Success in Detecting and Prioritizing Critical Security Risks in AWS Environments

    Los Angeles, CA, May 18, 2021 – Orca Security announced today that it has achieved Amazon Web Services (AWS) Security Competency status. This key designation recognizes that Orca Security has demonstrated proven technology and deep expertise to help AWS customers achieve their cloud security goals. As an AWS technology and co-sell partner, Orca is committed to working closely with AWS customers to secure their cloud estates from increasing threats.

    Orca Security is one of only nine companies in the cloud vulnerability and configuration analysis category to achieve the AWS Security Competency. This differentiates Orca Security as an AWS Partner Network (APN) member that provides specialized software designed to help enterprises adopt, develop and deploy complex security projects on AWS. To receive this designation, APN Partners must show that multiple customers have validated their technology for the specific competency, possess deep AWS expertise with a well architected infrastructure and deliver solutions seamlessly on AWS.

    “We’re proud to be one of the fastest cybersecurity companies to achieve the AWS Security Competency status, furthering our commitment to help customers accelerate their AWS migrations and confidently expand their AWS estates,” said Avi Shua, CEO and Co-Founder, Orca Security. “Orca Security is dedicated to helping organizations achieve their security goals by combining our SideScanning™ technology with the powerful security tools AWS provides to give customers full visibility into every aspect of their cloud estate.”

    AWS is enabling scalable, flexible, and cost-effective solutions from startups to global enterprises. To support the seamless integration and deployment of these solutions, AWS established the AWS Competency Program to help customers identify Consulting and APN Technology Partners with deep industry experience and expertise.

    Orca Security on AWS

    Orca Security provides cloud-wide, workload-deep, context-aware security and compliance for AWS without the gaps in coverage, alert fatigue, and operational costs of agent-based solutions. The Orca Cloud Security platform  protects AWS workloads including EC2, EKS, ECS, Fargate, and Lambda as well as finding configuration issues in the native services.

    Orca Security integrates through the AWS runtime storage layer and combines this with metadata gathered from AWS APIs to detect risks across both the workload and control plane. Customers can easily scan S3 buckets for personally identifiable information (PII) and malware without moving or storing the underlying data. Orca Security also enables AWS customers to leverage CloudTrail events to trigger new scans and update risk levels as configurations change in near real time. With Orca Security, customers can inspect Identity Access Management (IAM) policies, generate alerts, and visualize issues simultaneously via an access risk map.

    Key Developments of the Orca Security + AWS Partnership:

    • Available on AWS Marketplace: Orca Security is listed in the AWS Marketplace and customers are able to procure its solution as a private offer or through a consulting partner.
    • Integration with AWS Image Builder: With AWS Image Builder support, Orca Security directly integrates with customers’ CI/CD pipeline to ensure DevOps teams ship secured and verified images to production.
    • Service Ready for AWS Linux 2: Through quality assurance and security tests, Orca Security has been validated to provide support for Amazon Linux and Amazon Linux 2 platform of discovery.

    AWS Co-Selling Program: Orca Security is part of the technology partner co-selling program that works together with AWS teams to maximize joint customer value.

    Live Oak Bank Finds Multiple Tools in One with Orca Security

    Orca Security’s patent-pending SideScanning™ technology reads workloads’ runtime block storage out-of-band to detect all essential security risks across every layer of the cloud. Orca Security eliminates the need to cobble together disparate tools, and replaces legacy vulnerability assessment tools, CSPM, CWPP solutions, and more.

    “We plan to replace several one-off solutions with Orca Security, because Orca Security does much more than just vulnerability scanning,” said Thomas Hill, CISO, Live Oak Bank. “It looks for data loss prevention. It does virus scanning. It performs an inventory. Orca does it all, while saving us both time and money.”

    Additional Resources

    About Orca Security  

    Orca Security, the cloud security innovation leader, provides cloud-wide, workload-deep security and compliance for AWS, Azure, and GCP – without the gaps in coverage, alert fatigue, and operational costs of agents.

    Unlike competing tools that operate in silos, Orca treats your cloud as an interconnected web of assets, prioritizing risk based on the severity of the underlying security issue combined with environmental context, including its accessibility and potential damage to the business. This does away with thousands of meaningless security alerts to provide just the critical few that matter, along with their precise path to remediation.

    Find critical attack vectors before your adversaries without having to cobble together disparate tools for cloud security posture management, compliance assessments, and workload and data protection. Delivered as SaaS, Orca Security’s patent-pending SideScanning™ technology reads your cloud configuration and workloads’ runtime block storage out-of-band, detecting vulnerabilities, malware, misconfigurations, lateral movement risk, weak and leaked passwords, and unsecured PII. SideScanning™ covers all your workloads–VMs, containers, and serverless.

    Orca Security deploys in minutes – not months – because no code runs within your cloud environment. With Orca, there are no overlooked assets, no DevOps headaches, and no performance hits on live environments.

    Connect your first cloud account in minutes and see for yourself. Visit https://orca.security.

  • Common Cloud Security Mistakes and How to Avoid Them

    Common Cloud Security Mistakes and How to Avoid Them

    Over the last few years, it’s become apparent that traditional on-premise security policies are not a good fit for newer cloud-native environments. Even though the writing has been on the wall for a long time, the brewing security crisis still hasn’t been resolved. Far too many organizations continue to use security measures that are ineffective for cloud-native environments, along with inconsistent policy enforcement that leads to huge oversights and gaping organizational loopholes. The sad truth is that today, it doesn’t take a master hacker to infiltrate most cloud-native deployments.

    Many of the most infamous security breaches would have been extremely difficult to prevent even with an ideal security environment, but the weakness of the system is endemic, reaching far beyond a handful of vulnerable organizations. Even if some malicious actors could still get through, there’s no reason for organizations to leave their attack surface so blatantly unprotected.

    Here are increasingly common cloud security mistakes DevOps teams still make, and our suggestions for how you can stop them in your organization.

    Ignore Zombie Workloads

    Many organizations ignore zombie workloads that run on their architecture. When your team is stretched and you’re facing a number of serious security issues, it’s easy to dismiss zombie programs as nothing more than a harmless irritation.

    In actuality, having zombie resources scattered around your deployment blocks your ability to spot serious cryptojackers. Zombie workloads are often an indication of, and an invitation to, more significant invasions into your infrastructure. A report by SkyBoxSecurity revealed in 2018, cryptojacking was the leading attack vector. DevOps teams need to recognize the threat of hosting a program mining your resources for cryptocurrency, and take immediate steps to block them.

    Turn a Blind Eye to Leaky S3 Buckets

    AWS service buckets, particularly the S3 bucket, is one of the oldest cloud-native services. As a result, many S3 buckets are still governed by very old rules and regulations that leave many ways for someone to accidentally make the bucket public, open up access to unauthorized users and expose sensitive data.

    A study by HTTPCS reports 58% of AWS S3 buckets are accessible to the public, and 20% of them aren’t write-protected. Not only can malicious actors get to your sensitive customer data through S3 buckets, but often they can access your cloud credentials as well. Some of the most disastrous data breaches began from unrestricted access to S3 buckets, and it’s one of the most common causes of data breaches overall. It’s vital to regularly check your AWS console for public buckets.

    Allow Runtime Updates to Bypass the CI/CD Pipeline

    Every DevSecOps team agrees that your deployment is more secure when runtime updates are passed through the CI/CD pipeline, but that doesn’t mean the policy is always enforced. Developers will repeatedly ignore your security policies through practices, such as using open-source libraries, to avoid the security process of the CI/CD pipeline and speed up deployment.

    While this saves developers some time on releasing updates, it places a heavier burden on security teams, who have to run extra scans for these rogue workloads. What’s more, it builds complacency among DevOps teams, who assume there is no way to prevent unauthorized workloads and end up simply accepting them. Eventually, your security posture erodes to the extent that malicious actors can run harmful workloads without attracting your attention–until it’s too late.

    Permit Unrestricted Network Access

    Instead of spending hours on segmentation and separate access permissions, all too many DevOps teams fall back on a blanket set of network configurations that fall far short of the necessary access restrictions. They often place all their workloads into a single VPC, opening up access to third parties in the process.

    Without restrictions on public network access, it takes far longer for security teams to identify and isolate negligent and malicious activities. In a short space of time, DevSecOps teams find themselves overlooking serious oversights like unrestricted public root access, opening up enormous holes in their security profile.

    Faulty Rule Configurations for Micro-Segmentation

    When DevOps teams use micro-segmentation in containers, they face unique challenges. The more granular you get with your segmentation, the greater the risk you’ll miss faulty policy rules.

    Even your most familiar rule sets can create massive vulnerabilities. For example, if you allow your developers to use a specific IP to connect to the production runtime environment through SSH, you could unwittingly end up permitting unrestricted public access to sensitive areas. Sometimes, these faulty rule configurations go overlooked for as long as several months. To avoid supporting faulty rules, it’s important to audit them regularly with a tool such as Amazon Inspector’s Agentless Network Assessment.

    Avoiding AWS cloud security mistakes requires a shift in mindset. The harsh truth is a significant number of cloud-native deployments commit not just one, but several of the mistakes listed above. Cloud environments are deliberately decoupled from the network infrastructure in order to enable agile business practices, but DevSecOps teams continue to use network security techniques that aren’t capable of meeting the unique challenges of the cloud.

    The only way to fix these mistakes is to turn to new technologies designed for cloud security, such as using cloud workload identities to bridge the chasm between business logic and network infrastructure. Until ACLs and security groups are untethered from the network infrastructure and join cloud-agile business logic, they’ll fail to provide adequate cloud-native security.

    — Ran Ilany

  • Top 5 AWS Security Mistakes: Leaky S3 Buckets

    Top 5 AWS Security Mistakes: Leaky S3 Buckets

    As we get ready to discuss our list of the Top 5 AWS Security Mistakes in the upcoming devopsy.kinsta.cloud webinar, we wanted to provide a preview of the type and depth of information we’ll be discussing. Since the most-talked about, and likely the most vulnerable, aspect of AWS security is inevitably those leaky S3 buckets, it’s a given we’ll tackle S3 first.

    In this article, we’ll dig into S3 buckets, explain how they become vulnerable, cover eight different ways they can inherently become open to the public and how to find and protect any public facing S3 data.

    The S3 Bucket

    S3 is one of the oldest services in AWS—so old that parts of it still support XML-based policies instead of the JSON you see everywhere else. S3 also has a lot of features that aren’t as commonly known or used anymore, such as allowing someone else to host put objects in your bucket yet still maintain ownership of them.

    Think of an S3 bucket as a server that can have subdirectories and files. Because S3 buckets can have a different root url (e.g. “dops.s3.amazonaws.com”) and have their own life cycle and settings, we tend to think of buckets as servers, not directories. Also, directories in S3 allow you to organize objects, but don’t have any distinct settings of their own, other than a name.

    AWS has a wide range of use cases it needs to support, which is why we have all these mechanisms. Sharing publicly, within an account, between accounts, hosting websites and so on, creates complexity. The good news is S3 always defaults to secure and private. The bad news is AWS allows human beings to use it (and therefore weaken security) and can be confusing to manage. For example, S3 supports both read and write permissions (and list, for buckets). It’s possible to have no public read but public write permissions, which could lead to people placing bad files in your directories.

    8 Ways AWS Data Becomes Public

    There are at least eight different ways an AWS S3 bucket can inadvertently become open to the public and be exposed to a data breach.

    • Bucket ACLs (Access Control Lists): This is an XML document that defines the first layer of access. By default, only the account owner has access, but this can be opened up to other AWS accounts or the public at large. Amazon recommends against using these at all, but it’s also the easiest way to make something public quickly, so we see it all the time.
    • Bucket Policies: These are super-flexible JSON policies that allow you to set things such as IP-based and other conditional permissions on a bucket. While this should be the primary way for managing public access, ACLs are the first tab and about three clicks to make something public. It’s this flexibility that leads to mistakes such as opening up to a wider range of IP addresses than intended or using a negative to block access to some IPs but inadvertently granting access to everyone else.
    • IAM Policies: These are the normal IAM permissions you use to control access throughout your AWS account. You can’t make a bucket public with them, since they only govern AWS users, but you can open up access to the bucket by authorizing another AWS service access, and then that service exposes the content.
    • Object ACLs: These are the primary object-level controls. It’s just like a bucket ACL and uses XML to allow access from other accounts or the public. Objects do not necessarily inherit bucket ACLs. You can totally make an object public even if the bucket is private.
    • Explicit IAM or Bucket Policy Statements: IAM policies and bucket policies can have explicit statements referencing the object, which will override the object ACL (if you own the object), since they are evaluated first.
    • Pre-Signed URLs: These object-level policies must be created using code (not the console) and provide temporary access for anyone with the URL. It’s used, for example, to share files for a few minutes or an hour for someone using your app to download a media file.
    • CloudFront Origin Access Identity: CloudFront is the AWS content delivery network and can serve as the front end to S3. You can create something called a CloudFront origin access identity to write an IAM policy that allows CloudFront to access the S3 content. If the CloudFront allows public access, it can access the S3 content and that won’t show in a bucket policy or ACL.
    • Cross Origin Resource Sharing (CORS) Policies: CORS is required if you use S3 in a website and don’t want the browser to break due to same site security settings. CORS in S3 won’t override an ACL or bucket policy but could mask public access in limited situations where the data is exposed in the web code through the authorized site.

    All put together, AWS evaluates IAM permissions first. Within those, the only one to make a bucket public over the web is the CloudFront Origin Access Identity. AWS then turns to the bucket ACLs and policies for any explicit deny statements. Then it looks at the object ACLs for public access. If you make an object public and the bucket policy doesn’t have an explicit deny, it is still public, but otherwise a good bucket policy will block everything. Besides, a lot of the problems are open bucket ACLs, not object ACLs.

    4 Ways to Find Your Public S3 Buckets and Protect Your Data

    What’s the best way to find public buckets? It’s relatively easy.

    1. Log into the console, click on S3 and look for the Public tag. AWS uses some advanced back-end math to evaluate all the bucket policies to figure out if something is public, which catches most of the fringe cases, but it does not show if the bucket is private and objects in it are public.
    2. Check CloudFront to see if you use any origin access identities. It’s easier to look here than in all your bucket policies (usually). This saves you from looking through object ACLs as well.
    3. Check any CORS policies, if you use them. This is the least common situation and I even hesitated to complicate this post by mentioning them.
    4. The bad news … there is no easy way to find public objects. Even finding them programmatically can be difficult if you have a large number. Also, changing a bucket ACL doesn’t cascade to the object ACLs so you need to run through and fix them one by one. However, if the bucket is locked down the attacker would need to know the full URL/name of the object to find it. It’s not perfect, but it’s better than nothing.

    That’s it. Although, if you know of any other fringe cases, please don’t hesitate to let us know. While conducting assessments, we find well over 90% of the problems are just basic bucket ACL and policy mistakes. Object ACLs are also an issue, but slightly lower risk since you need the exact URL to find them if your bucket is otherwise secured properly.

    If you are curious about the other 4 Top AWS Security Mistakes, sign up for the Aug 14 webinar.

    — Mike Rothman