The challenge for organizations is how to safeguard sensitive information while adhering to the law, but without compromising innovation. Cyber threats loom large, affecting businesses in every industry. 

Financial services organizations, in particular, stand as prime targets for cybercriminals, given the lucrative nature of their data. Ransomware attacks, for instance, impacted a significant 74% of global financial institutions in 2021–2022. 

Attackers increasingly exploit poorly configured cloud services; a single security misconfiguration buried deep within a cloud stack can provide hackers with a gateway to unauthorized access.

Staying compliant with cybersecurity standards and governmental regulations is a daunting task that seems to grow more complex by the day. And, with the growing transition to cloud-based environments, security leaders must strike a delicate balance. How can they effectively address cloud security and compliance challenges without impeding product development and growth?

Navigating the complexities of compliance 

Managing compliance now means contending with a myriad of standards and regulations, some mandatory, some optional, some region-specific, and many overlapping. These include technical standards such as NIST and ISO, data security standards like PCI-DSS, and governmental regulations such as GDPR, SOC, and DISA, creating a veritable acronym soup of rules and regulations. Failure to meet these standards and regulations carries substantial risks, including damage to reputation and the aforementioned fines. 

Beyond compliance, cloud security remains paramount and to mitigate evolving threats and reduce risk, security leaders must embrace solutions designed for cloud-native environments. Prioritizing vulnerabilities, real-time threat detection, misconfiguration identification, activity auditing, and compliance measurement are critical components of securing cloud assets.

Meeting the compliance and security challenge

Point solutions that need to be integrated are no longer effective for the compliance and security requirements imposed by regulators. They provide too many opportunities for vital alerts to be missed and too many possible opportunities for breaches.

To fully harness the agility and speed offered by cloud technology, organizations require a robust cloud-centric security architecture and adaptable tools for enhanced visibility and control. 

Developers need integrated tools and security platforms that align with open standards, reducing the burden of alert fatigue and allowing them to focus on product development.

Adopting a cloud-native application protection platform (CNAPP), offers a comprehensive solution that provides enhanced visibility and control over the entire cloud-native application stack. CNAPPs facilitate real-time knowledge of your cloud environment, streamline workflows, provide data correlations, deliver meaningful insights, and support remediation efforts.

Implementing a CNAPP allows organizations to elevate security across all facets of their cloud infrastructure and cloud-native applications. Embedding CNAPP security from the earliest stages of development through production ensures the highest levels of security and compliance integrity.

How Sysdig can help

Sysdig helps organizations secure their cloud environments and accelerate innovation. With cloud and container security solutions that offer a unified view of risk, security teams can prioritize and address issues proactively, ensuring both compliance and security. With Sysdig, organizations can harness the benefits of cloud services while mitigating cyber threats effectively.

• Cloud Detection and Response: Multilayered threat detection, incorporating Falco-based policies and Machine Learning (ML) detections, empowers organizations to respond confidently to threats targeting workloads, cloud services, and identities.
• Compliance and Posture Management: Sysdig provides built-in compliance tools that help organizations assess their security posture, swiftly identify and rectify misconfigurations, and adhere to best practices.
• Vulnerability Management: Security teams can leverage Sysdig’s tools to identify and prioritize vulnerabilities based on real risk exposure, expediting the path to security and compliance.
• Entitlement Management: Sysdig enhances visibility into cloud identities and permission management, eliminating excess permissions and enforcing least privilege access.

In conclusion, the cloud has ushered in a new era of business operations and innovation. Businesses are successfully capitalizing on cloud technology to achieve unprecedented agility. However, the key to this success lies in ensuring compliance and security while minimizing risks. Sysdig’s platform empowers modern organizations to embrace cloud and cloud-native applications securely, effectively preventing, detecting, and mitigating cloud threats while maintaining compliance.

The post Ensuring Compliance in an Ever-Evolving Cloud Security Landscape appeared first on Sysdig.

Regardless of your cloud adoption maturity (whether you’re PoC-ing some services in the cloud, running a few applications, or fully embracing this new era), we’re sure you have likely already noticed that cloud-native security is different from IT-managed data center security. But how exactly is it different? A recent Gartner survey found that 50% of participating organizations indicated a lack of internal knowledge about cloud-native security. That’s no surprise if we think about how rapidly things evolve in the cloud.

In this blog post, we are going to review some of the terms you keep hearing from vendors, cloud providers, and security training courses so you understand what to focus on to really protect your cloud environments.

Gartner, Forrester, IDC, and 451 Group are some of the most well-known analyst firms that identify and describe emerging trends in the market and create definitions for new technologies. They have coined terms you know, like SIEM, CRM, and WAF. But they’ve also coined Posture Management or CSPM, Vulnerability Management, CWPP, Entitlements and Permissions or CIEM, among others.

The 2023 Gartner® Market Guide for Cloud-Native Application Protection Platforms (CNAPPs) has generated a stir among security leaders. Do you need another tool? What is CNAPP? Where does this new term fit in? Is Posture Management no good anymore? Can we forget about CWPP?

The truth is that CNAPP is just the logical convergence between Vulnerability Management, CSPM, and identity-based security, plus some other goodies. With so many tools working in silos, it was getting harder and harder to prioritize risk within cloud-native applications and its associated infrastructure. CNAPP’s offerings are bringing together multiple disparate security and protection capabilities into a single platform.

Let’s find out step by step.

Vulnerability Management

It all started with DevOps teams moving their workloads to the cloud.

In order to secure the whole DevOps workflow, security teams needed to make sure those applications were safe for the final user, and that’s what Vulnerability Management tools focus on. They protect cloud workloads from security flaws, like vulnerabilities, that bad actors can abuse to gain access to sensitive data for their shady purposes.

Use cases behind Vulnerability Management:

• Vulnerability scanning: Detecting OS and non-OS vulnerabilities from running images in production.
• CI/CD and Registry scanning: Scan from container images stored in CI/CD and registries before deploying to production. Adopt in-line scanning to maintain control of images and only ship scanned results to production.
• Vulnerability prioritization: Prioritization of vulnerabilities tied to active packages.
• System hardening: Protecting Linux hosts or VM-based workloads running on top of the host by reducing its vulnerability surface with restrictive configurations as a preventive control.

As everything in the cloud is interconnected, let’s see how the combination of other tools in a CNAPP solution generates a better outcome than what we would have with single isolated products.

Cloud Detection and Response or CDR

CDR stands for Cloud Detection and Response. CDR aims to protect the dynamic, expanding attack surface of cloud environments with real-time detection of misconfigurations, vulnerability exposures, and suspicious activities. So, it’s the real-time detection piece that comes into play when we talk about CDR.

Common use cases for CDR would be:

• Workload runtime detection: Preventing and detecting suspicious behavior at runtime in containers and microservices.
• Cloud Threat detection: Warning us about unusual activity in the cloud, like an S3 bucket with sensitive data made public or a privileged account accessed without MFA.
• Network security: Visualizing network traffic inside containers and Kubernetes, and enforcing Kubernetes-native network segmentation.
• Incident Response: Conducting forensics and incident response for containers and Kubernetes even after the container is gone. Automating response for container threats.

CDR itself can be the difference between an attack contained and a massive breach. However, combining it with vulnerabilities, misconfigurations, or identities insights increases SOC team speed by providing detection events with full context, reducing the time to understand what, where, who, and root cause.

Are you starting to see the power of correlating insights between the different siloed tools?

Posture Management or CSPM

As workloads moved to the cloud and DevOps teams began to provision their own infrastructure, security teams that used to have a controlled environment in on-premises data centers found themselves losing control over who did what in the cloud. The perimeter had widened. Like in local data centers, security professionals had to ensure compliance in the host instances, user accounts, and data privacy. But the lack of visibility to know what assets they have in the cloud makes it really difficult to keep track of misconfigurations in those assets.

Cloud-bound teams must also quickly adapt to the new paradigm of the cloud infrastructure environment (immutable infra, policy as code, and identity as the new perimeter, among others). Thus, cloud security teams needed a different approach.

Modern Posture Management is the tool that unifies different use cases aimed at protecting the cloud control plane, essentially tracking cloud resources and verifying the static configuration of the cloud.

What use cases does Posture Management cover?

• Compliance: Validating container and cloud compliance and ensuring File Integrity Monitoring inside containers and hosts.
• Misconfiguration Management: Scanning for misconfiguration early in the pipeline, integrating security and compliance seamlessly and transparently into modern DevOps, and avoiding dragging errors to production environments.
• Prioritization and Remediation: Extended capabilities, like providing better identification, prioritization, and remediation of cloud-native application risk.
• Real-time Posture Drift detection: Detecting in real-time when you deviate from your security posture at runtime.

Getting notified if a violation occurs lets teams take action to prioritize its remediation.

CIEM

Identity Management and data privacy are also important aspects of a cloud security program.

As mentioned, when the perimeter was the local data center, it was easier to control who had access to what. Now, even serverless functions can act like users accessing data.

To address the cloud permissions gap, we have Cloud Infrastructure Entitlement Management (CIEM). With CIEM, you would not only know which human and non-human identities can access which resource, but what permission they are using on a daily basis. You can also suggest policy modifications to enforce least privilege access.

Let’s say we have a group of users who are part of a project. These users are responsible for uploading images into an ECR repository and running those containers in EC2 instances, as well as a number of auto-scaling actions. There’s no need for them to have all the permissions an administrator has, even though that approach may be the simplest to configure. Are they going to be deleting VPCs? That is not one of their tasks. Getting rid of excessive permissions is the first step to reducing collateral damage from credential theft.

Finally: CNAPP

If you made it here, congratulations! You are about to uncover the figure after connecting the dots. CNAPP is the combination of different use cases that fall into the Vulnerability, Posture, and Identity Management categories, but let’s go to the source:

“CNAPPs consolidates a large number of previously siloed capabilities, including container scanning, cloud security posture management, infrastructure as code scanning, cloud infrastructure entitlement management, runtime cloud workload protection, and runtime vulnerability/configuration scanning.”

Gartner, Inc., Market Guide for Cloud-Native Application Protection Platforms, Neil MacDonald, Charlie Winckless, Dale Koeppen, 14 March 2023.

We hope CNAPP and the rest of the terms make more sense now than when you started reading the article.

Conclusion

CNAPP solutions will promote collaboration between teams (SecDevOps, DevOps, and cloud security operations) by incorporating common workflows, data correlations, meaningful insights, and remediation that’d reduce friction between the personas.

True CNAPP solutions will provide interrelationships between the different insights of the use cases. It’s totally useless to have a nice UI that provides vulnerability scanning if you don’t enrich it with the cloud context of where those images are stored/running. We are not talking about isolated tools put together to call it a day, but rather a comprehensive security platform that enriches data and workflows with meaningful context on every step.

The post Who’s Who in Cloud Security? CSPM, CIEM, CWPP & CNAPP Explained appeared first on Sysdig.

You may think this only happens in the movies, right? In this case, reality surpassed fiction.

On Dec.20, 2018, the APT10 Group did exactly that. Members of APT10 stole personal, confidential information, including social security numbers and dates of birth, from over 100,000 Navy personnel.

They hacked into a managed service provider (MSP) who had access to lots of networks, and then spidered into each of the customers’ networks, running scans on the DoD’s IPs to see if there were any shared folders open to the DoD’s network.

You can read about it here.

If you are already working to some degree with the DoD of the U.S., you may already know about DISA STIG compliance. But if your organization has never done business with the DoD, you may not know how all these intricacies work.

This blog post is an in-depth exploration of DISA STIGs, what they are, the different categories, and how Sysdig Secure can help your organization achieve DISA STIG compliance for Docker and Kubernetes.

What are DISA STIGs?

DISA STIGs are security guides that contain technical advice to properly harden those contractor systems that attempt to communicate with the DoD systems of the U.S. That’s something our MSP friends should have done if they happened to host systems that had that type of relationship with the DoD, right?

Defense contractors process, store, and secure DoD data-related contracts. To better protect this highly sensitive data, the Defense Information Systems Agency (DISA) created a set of mandatory configuration standards, known as Security Technical Implementation Guides (STIG).

These are designed to make devices (both hardware and software) as secure as possible, safeguarding the DoD IT network and systems.

STIGs are available for a variety of IT systems including operating systems, virtualization software, network appliances, databases, or open source software applications, among others. The DoD has released hundreds of STIGs, and the process has evolved to meet the needs and challenges of cloud-native software development.

DISA STIG Compliance Levels

Within the STIGs, there are three compliance levels, named categories. The categories indicate the severity of the risk of failing to address a particular weakness.

DISA STIGs for Containers and Kubernetes

Docker Enterprise was the first container platform to pass the STIG process. DISA released the Container Platform Security Requirements Guide (SRG) in December 2020 to direct how software containers go through the STIG process.

The Kubernetes STIG was released April 21, 2021.

Some of the requirements included in DISA STIG for Docker and Kubernetes are shared among other compliance or best practices policies, like NIST, FedRamp, or CIS:

• Communication channels must be encrypted
• Run the containers with policies that limit the use of resources (CPU, memory, storage)
• Follow Container Best Practices
• TLS certificate authority (CA) certificate file ownership must be set to root:root

Sysdig Secure is designed specifically to understand all the nuances of Kubernetes workloads. We are built to be the best companion the container’s orchestrator can have, almost like its psychoanalyst. Based on our no-secrets relationship, Sysdig is able to automate the task of assessing DISA STIG compliance for Docker and Kubernetes.

Why DISA STIG Is Important

All Government agencies are mandated to receive an Authorization to Operate (ATO) before they can connect to the DoD network or system. System integrators (SIs), government contractors, and independent software vendors must comply with relevant STIGs as a major part of the process.

If you plan to work for the DoD, you must prepare your systems to be DISA STIG compliant.

Once the accreditation is earned, the ATO must be maintained. Non-compliance can result in millions of dollars in fines and detailed investigations to be carried out on the agencies.

STIGs are notorious for their complexity and the hurdle that STIG compliance poses for technology project success in the DoD. Oftentimes we find organizations with limited staff to perform the lengthy STIG compliance scan, remediation, and reporting tasks. We can almost imagine the pain of the program managers in charge of this task. DISA STIG compliance can turn out into a nightmare, that one in which you fall forever, like the feeling of a never-ending catchup to ensure all of the systems are in compliance.

Automation is the clear path forward.

How to Use Sysdig Secure for DISA STIG

Although the DoD Cloud Computing SRG indicates that CIS Benchmarks are an acceptable alternative in place of STIGs, many organizations are still required to demonstrate compliance with STIGs specifically.

Sysdig Secure offers more than 50 out-of-the-box security policies, with DISA STIG for Docker and Kubernetes included as part of the bundle.

We’ve created separated policies to support the different STIG categories:

These compliance policies map individual STIG requirements to compliance controls based on Open Policy Agent (OPA) and its policy-as-code foundation.

Sysdig Secure makes compliance scalable and predictable by enforcing policy as code as part of DevSecOps workflows. Plus, Sysdig Secure can be used to enable continuous compliance across hybrid infrastructure by scanning for adherence to security requirements, ensuring secure system configuration.

While automation is extremely helpful in configuring systems to be compliant at deployment, system states will inevitably drift over time and fall out of compliance. So, you want to make sure that your compliance automation platform checks for drift and provides remediation playbooks in order to speed up the remediation process.

To check the security posture of a particular Docker/Kubernetes environment for DISA STIG, you just have to create a Zone and select the DISA STIG policy to enable all relevant controls, automatically applying to the appropriate scope of K8s nodes or Docker applications, reaching hundreds or thousands of nodes at once.

If you are monitoring the security posture of your Docker/Kubernetes environment for other relevant Compliance policies, just add the DISA STIG policy to the list and you will be set.

Sysdig Secure allows teams to assess infrastructure-wide compliance and quickly identify workloads that don’t meet security requirements.

After defining your baseline compliant state configurations, Sysdig Secure will continuously check your infrastructure so whenever a system drifts from its compliant state, it will automatically flag those changes.

To get a clear view of the status of each control, Sysdig users are able to see a resource centric inventory with all the resources that need to pass a particular control and its status (passing or failing). Sysdig Secure allows you to reduce workforce costs associated with compliance and generate automatic reports to stay ahead of audit preparation.

You can remediate compliance failures and build a framework for ongoing compliance with content created by Sysdig experts and tailored to your environment.

Conclusion

With hundreds of different controls, DISA/STIG compliance audits can require significant resources to complete manually. Oftentimes, companies don’t have the time or the bandwidth to tackle it. Automated auditing tools that check against the latest STIGs requirements can save valuable time.

Sysdig Secure offers an enterprise solution custom made for Docker and Kubernetes. Automating government security and compliance with Sysdig ensures containerized applications are configured correctly to meet the requirements, helping you stay that way.

If you want to learn more about how Sysdig Secure can help with the Security Posture of your environments, visit the Sysdig Secure trial page and request a 30-day free account.

You’ll be up and running in minutes!

The post DISA STIG compliance for Docker and Kubernetes with Sysdig Secure appeared first on Sysdig.

Cloud Security Posture vs Kubernetes Security Posture

Cloud Security Posture Management or CSPM refers to the security tools designed to evaluate and prioritize policy violations for cloud resources (such identify misconfiguration issues and compliance breaches). CSPM help organizations to be as secure as possible against the various threats that could impact cloud environments.

So we can see KSPM like one of the sub-cases under CSPM.

For a cloud security engineer, the Kubernetes Security Posture can just be a percentage number or score. The higher the score, the better Infra/Ops teams are doing following security best practices. The lower the KSPM score…means the fateful number is going to chase you until you fix all those configuration issues that do not meet the security guidelines.

When a compliance audit approaches, security teams and auditors will need all the relevant documentation on the company’s current security posture, KSPM score included.

Security audits vs Security Posture

Because security audits will come. They have become common procedures in today’s companies.

Maybe the first thought that comes to mind when thinking about security audits can be negative, security audits are not something to fear. Actually, they help organizations protect sensitive data, identify security risks, and ensure employees stick to security practices. Regular audits force us to continually re-evaluate our security policies or create new ones to keep up with the latest threats and also track the effectiveness of our security strategies.

A security audit can be driven by a company, to comply with best practices or internal security guidelines. Companies that belong to a particular field that operates with sensitive data, may be forced to carry out these security audits based on industry regulatory standards, such as HIPAA, NIST, etc. In the vast majority of cases, companies will have at least to comply with the national regulations of their countries.

The Center for Internet Security (CIS) is an independent organization that provides configuration baselines and best practices for securely configuring a system. CIS guidence is one of the most used references among security teams. There are CIS Benchmarks for all kinds of IT environments, and Kubernetes has its own CIS benchmarking as well. No need to say that you can use the CIS Kubernetes Benchmarks to enhance your Kubernetes Security Posture :)

Don’t get caught off guard

If you are using Kubernetes to orchestrate your workloads, in the cloud or on-prem, there is a good chance that you hear that fearsome sentence one day: “We need to improve our Kubernetes Security Posture“.

For the Infra/Ops teams that are already overwhelmed in their daily duties, all the extra work to fix Kubernetes’ bad practices can be a big headache.

Depending on the tools and processes you have put in place to provide Kubernetes Security Posture insights, you will be more or less successful when trying to improve the KSPM score. Start tracking your Kubernetes Security Posture from the beginning.

Some of the questions you should be asking to check if you have the proper tooling or processes could be:

• What is my KSPM score?
• Which controls are we failing?
• How can we decide which violations to fix first?
• What’s the quickest way to remediate specific issues?

KSPM to Improve Kubernetes Security Posture

You only need to follow these three septs to set up a strategy to improve your Kubernetes Security Posture:

Step 1: Visibility – Set the basis

This might seem obvious but before you start you need to make sure everyone stays on the same page. We want the teams involved in the Kubernetes management process to be aware of the actual state of your KSPM score, right?

Having visibility is going to be crucial to do a good job.

Kubernetes Security Posture is the result of the cycles of the posture management process. Before you start, share the KSPM results with the team to start tracking progress.

Step 2: Prioritize – Define your working strategy

Not all bad practices are rated the same. Some pose more risks than others.

It is not the same to have Over permissive access to a resource type than having ServiceAccounts with the Ability to create pods in a cluster (which can ultimately open up possibilities for privilege escalation).

Being able to filter and prioritize is key when designing your strategy. To optimize your time as much as possible, start remediating the highest risks first.

This can be the foundation to start your Kubernetes Security Posture improvement strategy, and how you would tackle it.

Controls are either failed or passed. There is no magic on it. But the reason behind why this happens can be slightly different.

Let’s take the Container permitting root control for instance. In this failing control, we can see that the actual attribute value hasn’t been set. Is not that it has a risky/non-permitted value.

Knowing the real reason why a control failed may seem as no interest (let’s fix it and keep on), but the reality is that, if you pay attention to this nuaces, you can unveil gaps on how your team works:

• Not having enough time to plan ahead a deployment
• Insufficient knowledge of security risks of the underlying technology
• Lack of resource optimization.

Being able to see all these details means you can address them.

Step 3: Remediate – at the source

When having to remediate failed controls from security policies, teams that use automation, prefer to keep using this methodology, integrating the remediation workflow with their tools.

At Sysdig you can tie Kubernetes security violations with the Infrastructure-as-Code (IaC) manifest that defines your Kubernetes resources, in your git repository, identifying the two ends of the pipeline.

Using this approach will narrow your attack surface at runtime but also, you can be sure those changes are reflected in your IaC manifest and won’t happen again.

The remediation flow allows you to understand exactly what the issue is, review the suggested patch that Sysdig created specifically for the problem, and choose how to apply the patch:

• Manually – You can copy the patch code and apply it in production.
• Automated – You can remediate at the source simply creating a pull request integrating the patch (as well as checking for code formatting cleanup).

When you and your team are ready to fix the violation, it’s important to double-check the proposed solution, as it is going to affect your runtime environment.

Conclusion

Kubernetes requires a thoughtful design to ensure that governance, compliance, and security controls are included. You can use automation to remediate and maintain a well-managed and secure cloud while increasing your Kubernetes Security Posture.

The post KSPM and How to improve your Kubernetes Security Posture appeared first on Sysdig.

There are many potential sources for alerts or findings – cloud threats, runtime events, vulnerable images in your pipeline or registry, compliance violations, etc. The sheer volume of it all makes it almost impossible to address everything. We like to compare it to the worst of the fire season in the U.S. West Coast – there are more acres burning than firefighters have the capacity to protect. So where to focus the resources? Where will they have the highest impact or address the highest concerns?

Being inundated with alerts and findings poses real security risks for teams. The potential to miss something important that indicates malicious activity in your environment is high. Identifying the malicious drop in an ocean of frequently repeated alerts is challenging for anyone.

Introducing ToDo, Sysdig’s solution to this major problem that guides users to take the actions that will have the highest impact. Part of Sysdig’s Cloud Native Application Protection Platform, it does the work of aggregating resources with similar problems, prioritizing the most impactful actions, and guiding users to take meaningful remediations. This way, teams can easily know what to focus on first.

Take just a few seconds to try out ToDo in our micro-demo right here:

ToDo offers recommendations – a representation of a flow or action that is repeated across resources. Recommendations are shown as a prioritized list for each product area (such as identity, compliance, and other areas of risk). ToDo provides concise, actionable, and impactful recommendations, rather than a list of tickets that grows over time and that are addressed individually one at a time.

ToDo implements the following strategies for the recommendations:

Aggregation – What resources all have the same problem?

In this example, ToDo has identified a failing compliance control that is failed by a large number of resources and impacts multiple requirements across several policies. You can see how many failing resources are distributed per cluster. You can start a remediation flow for all affected resources or resources belonging to a specific cluster.

Impact – What is the most “bang for your buck” action you can take?

In this example, ToDo has identified where a slight change in a Kubernetes IaC (Infrastructure as Code) manifest file can fix a failing compliance control across many resources at once. By utilizing the automation promoted by IaC practices to fix violations, you can reduce the workload of your teams.

Prioritization – What is the most pressing security concern?

ToDo offers two levels of prioritization. Within a product area, the different recommendations are prioritized against each other. And within a specific recommendation, the failing resources are shown as a prioritized list with the riskiest appearing at the top.

In this example, ToDo calls out the users that have been deemed to have a critical risk and do not have MFA (Multifactor Authentication) enabled. A user’s risk is determined by looking at the exposure of their granted permissions and credential attributes, such as access key best practices. These users pose a higher threat to lateral movement by attackers and should be prioritized first.

Compliance

Many organizations have specific compliance policies or benchmarks that they are required to comply with. In addition to satisfying compliance needs, these policies can have requirements around security best practices. Continuously evaluating your resources against them will help to avoid common misconfigurations. For example, according to Sysdig’s 2022 Cloud Native Security Usage Report, 73% of cloud accounts contain publicly exposed buckets. This is an example of a misconfiguration that having continuous compliance set up for AWS CIS would have identified.

In addition to the IaC Manifest and High Frequency strategies described above, ToDo will offer recommendations to remedy failing controls that are deemed to be very high security risks.

This is one way to prioritize where to start remediating your compliance and posture violations.

Another strategy offered is identifying the easiest way to improve a specific policy score.

In order to improve a policy score, you need to cause a failing requirement to pass. Requirements can be made up of many failing controls, each with their own failing resources. ToDo will identify a requirement with only one control failing that has a minimal amount of associated failing resources. This is the quickest path to improving your Policy Score.

Identity

It’s not unusual for a modern cloud environment to include thousands of human users, applications, services, and other assets, each with a unique set of permission and access requirements to do its job.

How do you keep track of the access rights assigned to all of these human and machine users? In particular, how do you ensure that each user has only the level of access privileges necessary and avoid excessive privileges that could lead to security risks like lateral movement?

Lateral movement is seen in almost every major cloud breach. Here is just one example of how cloud lateral movement can be used to break into a vulnerable container. Sysdig’s CIEM (Cloud Infrastructure Entitlements Management) solution looks at CloudTrail logs and analyzes permissions given versus those actually utilized. That information is utilized for a Least Permissive Policy Suggestion, which can be copy/pasted directly into your AWS IAM (Identity and Access Management) Console.

ToDo will provide a prioritized list of your riskiest policies, users, or roles along with these Policy Suggestions, making it easy for you to tackle the security risk of lateral movement by moving towards a Least Permissive model.

In addition, ToDo will also summarize and prioritize other risky attributes around identity, such as unused policies, inactive users and roles, misuse of access keys, and missing MFA. Cleaning up your identity posture can prevent attackers from abusing your credentials or identity to exfiltrate data or crypto mine from your account.

Risks and vulnerabilities

Vulnerability management is one of the worst offenders of inundating your teams with findings. There are many vulnerabilities, so how can you prioritize what to fix first? Here are a few factors to look at:

• What is the vulnerability score?
• Is this image used in production?
• Is this package in execution?
• Are these vulnerabilities exploitable?

Only vulnerabilities that are tied to packages used at runtime offer a real chance of exploitation. Sysdig’s deep visibility into system calls removes all the guesswork from container vulnerability prioritization by accurately identifying vulnerabilities in packages loaded at runtime.

ToDo will call out Workloads at Risk – running workloads with critical vulnerabilities and respective packages in execution.

In addition, this interactive graph maps workloads with high severity vulnerabilities combined with high numbers of security events. Users can toggle between severities of both events and vulnerabilities.

Frameworks like MITRE ATT&CK can be helpful to understand which events to focus on first. ToDo breaks down all MITRE tagged events by cluster, helping your teams to identify areas of concern quickly.

Conclusion

High rates of false positive alerts continue to plague security professionals despite decades of work to reduce them. This creates real risk of becoming desensitized to alerts, causing you to potentially miss the highest priority security threats. Sysdig has developed a new approach.

We have applied an analysis methodology that groups common root cause security issues based on metadata. The use of ToDo for this purpose may be one small step toward alert reduction, offering the potential for a giant leap forward in addressing this decades-old problem.

Try out ToDo in a free trial of Sysdig, and start discovering your highest priority items today.

The post Prioritize Alerts and Findings with Sysdig Secure appeared first on Sysdig.

According to the NIST Cybersecurity Framework, organizations need to develop and implement the necessary protections to restrict or mitigate the effect of a possible cybersecurity incident.

Security should be integrated right from the source of the cloud architecture design process. Today, threat prevention and continuous security assessment are essential elements of enterprise cloud strategy today. This article will focus on these protection mechanisms.

AWS Shared Responsibility Model

The modern cloud architecture strategy requires a shared security model, which means that even though cloud providers such as AWS, offer considerable advantages for security and compliance efforts, they do not absolve the customer from protecting their users, applications, data, and service offering(s).

It is critical to understand the shared responsibility model, including which security tasks handled by the cloud provider and tasks handled by you, the customer. The workload responsibilities vary depending on whether the workload is hosted on Software as a Service (SaaS), Platform-as-a-Service (PaaS), Infrastructure-as-a-service (IaaS), or in on-premises data centers.

The monitoring, logging, and alerting policies are important aspects of the customers’ responsibility in the AWS Shared Responsibility. These policies enable the customers to improve their chances of detecting malicious behavior on systems and networks.

Monitoring is an important part of maintaining the reliability, availability, and performance of AWS solutions. AWS provides tools and features that enable the customers to record and monitor cybersecurity-related events on a continuous basis within the AWS environment.

Understanding cloud native security

As we covered in our blog post Guess who in cloud security landscape, about 50% of organizations recognize that they have a lack of internal knowledge about cloud-native security.

We want to help the reader be able to understand by themselves the “what and why” of each service. To do so we will contextualize security services leveraging two different methods:

• Security industry approaches
• Documentation from AWS Well-Architected Framework security pillar.

Security industry approaches

Main concepts related to cloud native security take the form of a Cloud-native application protection platform (CNAPP), which can be visualized as a combination of the following elements:

• CWPP (Cloud Workload Protection Platform) → Runtime detection, system hardening, vulnerability management, network security, container compliance, and incident response.
• CSPM (Cloud Security Posture Management) → Cloud controls plane protection by verifying the static configuration, best practices, frameworks, and benchmarks.
• CIEM (Cloud Infrastructure Entitlement Management) → Track and find gaps in cloud permissions and policies aimed to enforce least privilege access.
• CAASM ** (Cyber Asset Attack Surface Management) → Cyber asset attack surface management. Discover, inventory, and track assets (plain hosts, network devices, S3 buckets, containers, etc.)

(We avoid listing CNAPP because it basically contains all the previous elements).

There are many other classifications and layers on the security side of things but we want to keep this blog post as simple as possible.

AWS Well Architected Framework approach

Before going into details, let’s classify AWS services into two main groups:

• Elements with implicit security features: Foundational services that incorporate some security related traits or have a direct impact on the overall security (AWS Artifact, IAM, EC2, etc.)
• Explicit security services: Components aimed to address security issues like vulnerabilities, threats, risk management, etc. (e.g. AWS Security Hub, Amazon Guard Duty, Amazon Inspector, Amazon Macie, …)

  
  This article is focused on the explicit security components which could be native or third-party services that help your organization meet best practices within the shared responsibility model. As per AWS guidelines, the main security areas we will discuss include Detection, Infrastructure protection, Data protection, and Respond.
  

The range of security services AWS offers is rich in options and inter-connection possibilities, although it generates some additional levels of complexity that we will analyze later. Let’s have a look at the main AWS native security services like AWS CloudTrail, Amazon GuardDuty, Amazon Inspector, AWS Config, AWS IAM service, AWS Security Hub, etc.

Understand AWS security offerings

After examining the wide variety of security tools offered by AWS, let’s focus on native solutions meant to address CNAPP and related (CWPP, CSPM, CIEM) requirements using the aforementioned AWS security approach as our lens:

* Services marked with an asterisk are not explicitly secure services but have important implications related to security

Amazon Inspector
Security and compliance for EC2 via vulnerability management, configuration, network ports exposure, unsafe protocols, detection, and prioritization by severity rating.
This solution is agent-based (Inspector classic agents were switched with AWS Systems Manager agents in, Inspector v2).

Amazon Guard Duty
This service helps to identify unexpected and potentially unauthorized or malicious activities like Malware, crypto mining or attacks. GuardDuty ingests audit logs from multiple sources like CloudTrail event logs, VPC, S3, DNS, and EKS.

AWS Security Hub
AWS Security Hub provides a comprehensive view of the security state of your AWS resources by ingesting actionable events from other sources and services such as Amazon GuardDuty, Amazon Inspector, Amazon Macie as well as from Certified Partner Solutions or some Open Source Tools. These security alerts are standardized, aggregated and prioritized. Actions based on these findings can be triggered using for instance Amazon Detective or Amazon CloudWatch Event rules.

AWS CloudTrail
AWS CloudTrail allows monitoring AWS deployments in the cloud by getting a history of AWS API calls for your account, including API calls made by using the AWS Management Console, the AWS SDKs, the command line tools, and higher-level AWS services. Sysdig consumes this service among others as part of cloud security and compliance continuous feedback.

AWS IAM

Security in AWS begins with the foundation of Identity, which is managed by the Identity and Access Management (IAM) service with fine-grained access control policies.

Amazon Macie

Amazon Macie is a fully managed data security and data privacy service. Macie uses machine learning and pattern matching to help discover, monitor, and protect your sensitive data in Amazon S3 and receive alerts about sensitive data, exposed information, and intellectual property. Combined with other tools, it can help to meet regulations like HIPAA, GDPR, etc.

AWS Config
AWS Config provides a detailed view of the resources associated with your AWS account, including how they are configured, how they are related to one another, and how the configurations and their relationships have changed over time. It is not explicitly related to security but it has too many security implications to not be listed in this article. Continuous monitoring/audit configuration, change management, continuous assessment, and operational troubleshooting.

Sysdig offering: How to complement AWS security services

In 2021, we focused on taking our partnership with Amazon Web Services (AWS) to the next level. As part of this effort, Sysdig has successfully achieved the AWS Security Competency. This crucial designation recognizes the value provided by the Sysdig platform to AWS customers to help them achieve their cloud and container security goals.

Sysdig enforces Least privilege for AWS IAM

Identity is (almost) the new perimeter in the cloud.

Privilege escalation is a common technique attackers use to gain unauthorized access to systems within a security perimeter. Inadequate security controls, or failure to follow the principle of least privilege, with users having more privileges than they actually need are just some of the ways they find the “doors wide open” to cloud environments.

In other cases, attackers exploit serverless services, like the Lambda function, using specific techniques to elevate privileges. In addition, it’s possible to affect software vulnerabilities to overcome an operating system’s permissions mechanism and then move to your infrastructure using Lateral Movement technique.

Even though we find a good amount of resources in AWS around the importance of applying the Principle of Least Privilege access to cloud identities, there is no easy way to accomplish that.

We talked about the different AWS security services that can help us realize the permissions granted to identities (e.g., AWS IAM), the actions (e.g., AWS Config) that can be done over a resource (e.g., Amazon Macie), and the information related to the activity the human and non-human identities perform over a daily basis (e.g., CloudTrail). Nevertheless, all that information is spread across multiple AWS service offerings.

Sysdig CIEM offering is something different.

We complement AWS service offering regarding permissions and identities with a dashboard that unifies all the configuration, insights, and the meaningful information from AWS so you can perform the necessary tasks to really enforce this least privilege access principle.

With a CIEM dashboard, you can unveil the identities no longer working in the organization, the roles, the serverless identities you created for a POC that had granted way too many permissions and are no longer needed.

Remember, attackers are there scanning whatever hints they may find.

Many times, engineers get assigned to projects that were to be done by yesterday. For the sake of the project, we may end up granting more permissions than needed. We do not want to be the ones stopping the business. If we analyze the behavior of that cloud identity, we find it is using just a defined amount of permissions over a limited pool of resources.

Sysdig will save you and your team a good amount of manual investigation through AWS services with auto-suggested policies, analyzing what entitlements are granted versus what’s actually used/needed.

Sysdig threat detection for cloud and containers

Amazon GuardDuty is the service AWS provides as Threat Detection to its customers. It does a phenomenal job detecting anomalies involving AWS resources like IAM access keys, EC2 instances, S3 buckets, and Amazon EKS resources.

Sysdig is especially well known for its runtime detection capabilities, not only around workload protection but also cloud security monitoring (read Falco for cloud for more details) and its stream detection approach.Sysdig Secure offers additional capabilities over Amazon GuardDuty.

For Examples:

• Amazon GuardDuty uses the default AWS DNS resolvers to find issues, so if a malicious actor changes the default configuration and adds a different DNS (i.e., 8.8.8.8 or 8.8.4.4), anyone could query a domain without being detected

• Amazon GuardDuty may not scan unusual activity happening inside your production workloads, unknown malware, sources, and so on.

Stream detection is a continuous process that collects, analyzes, and reports on data in motion. With a streaming detection process, logs are inspected in real-time. This real-time detection allows you to identify unexpected changes to permissions and services access rights, as well as unusual activity that can indicate the presence of an intruder or an exfiltration of data.

This way, Sysdig Threat Detection capabilities can now detect the same cloud events as GuardDuty, along with the long-term existing ones of the workload side like: spawning a shell in a container, writing below sensitive folders, delete bash history…expanding the same functionality for Fargate tasks since AWS launched platform version 1.4.0 of AWS Fargate.

When it comes to practical action, depending on the scale of your cloud deployment, GuardDuty findings can be a little overwhelming, You can get lost pretty easily with so much information. If the team needs to fix the most critical findings as soon as possible, then you will need to filter out some of the noise. Here, Sysdig can be your ally.

Sysdig’s threat detection engine uses the open source project Falco under the hood, which means you get to use the Falco language to write rules and can take advantage of the use of a real language with macros, lists, exceptions… and the Falco rule tuning to cut out unwanted noise.

Amazon GuardDuty service is exclusively available to AWS environments, which means you can’t use the power of their machine learning threat detection on any other cloud platform or on-prem deployment.

If you are planning on going multi-cloud or using hybrid cloud environments, Sysdig would pair nicely with GuardDuty, a good complement to empower security.

Sysdig continuous Compliance and CSPM

Compliance revolves around being in accordance with established guidelines or specifications, industry led and government supported.

The two main services that relate to Compliance in AWS are AWS Artifact (not covered in this article) and AWS Security Hub. But there are other services also needed to really have continuous compliance in AWS cloud: Amazon Inspector, AWS IAM, Amazon Macie, Directory Service, AWS Firewall Manager, AWS WAF, AWS Trusted Advisor, AWS Config, Amazon CloudWatch, AWS CloudTrail, AWS Control Tower…

Regarding Sysdig, you have all your compliance controls in one place: Posture.

There, you can find quite a long list of security compliance standard controls (SOC2, PCI, several NIST standards, ISO-27001, HiTrust, HIPAA, FedRAMP, GDPR and adding more standards in a regular basis…) that we have mapped for you, but also Industry Best Practices that come from the CIS Benchmarks and cloud provider’s advices, like the AWS Well arquitecture Framework.

While AWS Security Hub does a very good job providing security findings regarding the configuration of your cloud account and services, it lacks visibility into the workloads.

Here is where Sysdig can help you.

Sysdig provides an overview of your security posture in both worlds, the public cloud infrastructure, as well as the workloads you have in production (whether they are on-premise or in the cloud). You will be able to harden those to comply with security requirements, flagging violations when you haven’t configured AppArmor correctly in your cloud instances or you don’t have sudo suid set.

Also, if you happen to be working with on-prem datacenters, you will also want consistency between the two environments.

Sysdig is not an alternative to AWS security services, but it is complementary and strengthening of AWS Security Hub, and is a solution to consider if you want to simplify operations between the cloud and the on-prem infrastructure of your company.

Conclusions

AWS security services are designed for specific security-related use cases and work really well. There are some gaps that could be covered by third-party tools like the Falco or Sysdig platform.

• This flexibility generates some additional technical complexity because of the need of deploying, configuring, and interconnecting several services.
• With time, we can expect AWS to introduce more of their specialized security tools while deprecating older ones. This also might eventually lead to increased complexity for Cloud Architects and Security Specialists in integrating and managing these many sources of truth.
• It is difficult to link context and correlation coming from different AWS tools for having something close to a unified experience.

Sysdig Secure strengthens AWS and multi-cloud security by providing a powerful but simple unified experience with a predictable cost model, covering:

• IaC code scanning threat detection and drift control.
• Vulnerability management.
• Runtime security for cloud, hosts, and containers.
• CSPM and CIEM.
• Incident response and forensics procedures.

The post Improving AWS security services with Sysdig Secure appeared first on Sysdig.

Cloud provider security services are increasing but it’s become evident that such tools can’t cover the needs to respond to these threats. After all, their main business is to provide cloud computing, network, or storage services. They are not a security provider.

Let’s imagine a potential scenario. You are in the very beginning of your cloud adoption journey, and only have a couple of IaaS or SaaS services running. You can easily implement security policies with tools provided by public cloud providers.

AWS Security Hub, AWS GuardDuty, Azure Security Center, Azure Defender, or Google Security Command Center act as a safeguard to alert us of suspicious behavior. But as the number of services you consume from the cloud providers increases, the need to put security as a first-class citizen becomes more apparent. We may find that these tools are not enough to secure our cloud environment.

In this article, we explain some areas in which the cloud provider security tools need a complement so that in combination, you can resolve all threats or reduce the risk of a security breach.

If you missed our content on how Sysdig Secure provides better visibility, context, and real-time cloud threat detection, you can visit these articles:

When using cloud provider security tools isn’t enough

Before deciding if the security tools provided by cloud providers meet our needs, we must explore the functionalities that each one of them offers.

If a first-class vulnerability scanner is mandatory for our company (you have to meet compliance requirements, leverage dockerfile best practices, or simply want to apply the shift left security principle) you are going to need a third-party solution designed specifically for this purpose. Most vulnerability scanners offered by cloud providers have few configuration options and, in some case such as AWS, their checks are based on a subset of Common Vulnerabilities and Exposures.

Of course, we don’t want to stop you from doing your own investigation, so we’re going to share some of the most popular cloud provider security services from the three major public cloud providers:

If you feel a little overwhelmed by the table, here’s the good news: there are several factors that will determine which type of tool is best for your environment.
We propose a few questions to help you find out if cloud provider security services are enough for you, or whether a third-party tool will best fit your needs.

Do you still have physical data centers?

To manage security risks both on-prem and cloud, you can use cloud service providers, like Amazon GuardDuty, Azure Advanced Threat Protection, or Security Command Center. Unfortunately, those services typically only work in cloud environments or they are looking for a way to migrate you to them. You can’t use the native encryption of a cloud data security service to encrypt data you have stored locally, for example.

Another example could be the use of cloud-based firewall services to secure applications running locally, but only if you set up a very cumbersome and expensive architecture that would allow you to integrate those apps with firewall services.

For this reason, companies that have a large on-prem and public cloud presence opt to use third-party solutions. In this scenario, the cloud providers’ security tools are not enough because the providers offer greater parity in securing both the cloud and on-prem worlds.

Do you work in multi-cloud environments?

Cloud operator teams managing multi-cloud environments need to be in control of their resources, assessing the neverending number of issues and vulnerabilities that show up everyday.

These teams need to check the insights of the different security monitoring tools each cloud provider offers continuously. The bad news here is that those cloud provider security services are often not designed to work with each other. AWS Security Hub, for example, doesn’t integrate with Microsoft Azure or Google Cloud Platform, and Azure Security Center doesn’t integrate with GCP or AWS. It is possible, however, to create complex integrations, manually, that help IT teams ingest security data from one cloud provider into another cloud provider’s security monitoring tool.

But, because of its complexity, it’s usually not worth it. Instead, if you’re going to bother to build your own integrations, you may as well go best-of-breed.

Is your cloud journey still uncertain?

We are talking about the high availability, fault tolerance, and elasticity needs of your cloud security.

Have you noticed how more and more use cases are being added to your security strategy? You need to consider your cloud security needs and how you expect them to grow over time. When you scale in cloud environments, your scope and exposure will grow. There will be the need to analyze risks automatically and to have control over everything that happens.

An ad-hoc solution will be necessary to allow the information from multiple cloud provider tools to be correlated.

Let’s call it a people problem

CloudTrail is a very powerful service. When you enable it, you have all the logs stored in one place and in the event of an incident, just query with the Athena service and you can find what you were looking for.
However, how do you know what to look for?

Sometimes you end up looking for a needle in a haystack. The ideal scenario is that you develop some type of action, like triggering a function, notification, or alarm, and build a response based on things that you see, thus making them actionable. If you don’t have time, or if you don’t have enough engineers with the necessary knowledge to do it, then it’s better to use a security tool that offers you pre-configured actions.

Any of the cloud provider security services that service providers offer us will need some customization, since it is quite unlikely that enabling the service will work perfectly for our use case.

Full view of compliance

For some people, the AWS Security Hub or AWS Audit Manager are like compliance types of tools. These tools check our environment against specific security standards, such as PCI DSS, GDPR, etc. They also show us what the fundamental security best practices of AWS and CIS benchmarks are. It gives us a score of, relative to that legal framework or set of good practices, how well we are doing.

Azure, for its part, does the same with the Security Center. It is very valuable to understand what your posture is at a moment, from a legal framework perspective or a set of security good practices. If you only have a cloud environment, you will be able to take advantage of tools like this one. Otherwise, you need an extra tool.

Filling the gaps that CSPs leave empty

Sometimes, you need to cover a really specialized use case, like when AWS needed to provide runtime security for their Fargate tasks. If you haven’t heard that story, you can read more here.

We’re not saying that cloud providers are bad for this, it’s just that their business is about offering cloud computing services. If we think about all the options, we realize that their lists embrace a broad spectrum of potential services to deliver.

At some point, they have to draw the line and say, “these are the services that we offer.” Sure, it won’t be perfect for everyone, but it’s likely they cover 75% of possible use cases.

If your use case has been left out, then it’s time to consider a third-party solution.

Conclusion

The security tools that cloud providers offer us are easy to manage. They have native interaction with all compute layers, which is awesome. But they also force us to stick to that cloud provider because you are customizing the security service with their tools. We don’t like to work twice, right?

Some of these security solutions offered by cloud providers have their limitations. This may not be important to you depending on where you are in your cloud journey, maybe the default options are fine.

However, as your cloud adoption matures and you think about moving to other cloud providers, get into the multi-cloud environment game. You’re going to need a solution that talks to all clouds. Make sure this tool fills in the gaps not covered by the cloud providers.

The post Sysdig Secure – When cloud provider security services are not enough appeared first on Sysdig.

Providing relevance and credibility in front of potential customers will show that your company takes security seriously, ensuring the client’s trust.

We previously covered other compliance frameworks in our blog, like GDPR, HIPAA, NIST, and SOC 2. Those frameworks also show a strong commitment to security best practices. What sets the ISO 27001 standards apart is its global scope to general security, and the reputation that comes with the ISO brand.

Getting ISO 27001 certification is not trivial and requires several steps. We, at Sysdig, are well aware of this complexity and can save you from cost and headaches throughout the process.

What is ISO?

The International Organization for Standardization (ISO) is a non-governmental organization that underlines standard frameworks for Information Security Management Systems (ISMS) within a corporation.

It provides a firm baseline for executing operational best practices within information security.

Why the ISO 27001 framework is key to your organization

ISO 27001 certification is essential for protecting your organization’s most crucial information and digital assets.

• Enables organizations to successfully mitigate security threats.
• Ensures that the company meets minimum security requirements.
• Ensures that there is an adequate response to manage risk.
• Guarantees the fulfillment of the customer agreement requirements and the regulatory obligations.

Benefits of ISO 27001:2013 Certification

Let’s be a little more accurate now; the last version of ISO 27001 was published in 2013, so that’s the formal name for the certification.

When an organization acquires the ISO 27001:2013 certification, there are several benefits for the company itself. Several of them are listed below:

• Improve reliability and security of company assets.
• Reduce the frequency of audits.
• Compliance with commercial, contractual, and legal responsibilities to avoid costly penalties.

Requirements to be ISO 27001 certified

At a very high level, these are some of the security controls that your company would likely need to implement in accordance with the ISO 27001 certification requirements:

• Identify potential information security risks, such as data breaches, cyberattacks, accidents, and errors.
• Define a secure framework to manage control.
• Meet compliance laws and regulations.
• List of the standards, processes and information security policies to be followed by the company.

How Sysdig helps you be ISO 27001:2013 certified

There are several steps you need to follow in order to implement ISO 27001 in your organization before gaining the coveted log.

Getting management support would be the first, as they need to be aware of the cost and be on-board. That is something Sysdig cannot help you with, unfortunately, but for the rest of the steps, you can count on us!

Once you have identified the assets that are within the scope of your organization, whether it be for a single datacenter, several workloads, or for multiple cloud accounts, use Sysdig Secure to perform an analysis of your security posture in accordance with the ISO 27001 controls.

All these sections are covered by Sysdig’s ISO 27001 compliance report:

• Internal organization
• Responsibility for assets
• Business requirements of access control
• User access management
• System and application access control
• Cryptographic controls
• Operational procedures and responsibilities
• Logging and monitoring
• Control of operational software
• Technical vulnerability management
• Network security management
• Security requirements of information systems
• Security in development and support processes
• Compliance with legal and contractual requirements

Sysdig Secure will assist, performing the risk assessment and providing remediation for those controls that do not meet the compliance check.

Also, keep in mind that you can keep track of the compliance posture of your assets over time, as an internal audit.

Once every control is green, you’ll be ready to register for a certification audit!

A consultant will receive your application and then will guide you through the corresponding steps. Knowing your compliance posture previously will save you time and money even before starting the process.

Conclusion

The concerns about the security of user data privacy are increasing every day. Depending on the industry your company works in, acquiring the ISO 27001 certification can be a great win.

With Sysdig Secure, learn how prepared you are before starting with the certification audit. Save yourself hours of stress and implement the ISO 27001 framework at your own pace.

Try it for free today and have the overview you need to start your ISO 27001 certification journey.

The post ISO 27001:2013 compliance with Sysdig Secure appeared first on Sysdig.

Behind these healthcare services, there’s a good chance we find cloud-native applications running in Kubernetes or some managed-Kubernetes service in the cloud, right?

The sensitive health information that is collected and communicated among health care providers and patients has raised new concerns for data security and integrity.

If you are one of the companies that provides healthcare services and need to meet HIPAA compliance requirements, Sysdig Secure can surely help you with your security posture. Sysdig Secure Compliance features include SOC2, NIST 800-53, GDPR, etc., and also HIPAA. :)

At this point, implementation of regulations and systems that ensure appropriate limits on data access, use, and disclosure is a must.

What is HIPAA

The HIPAA law, approved in 1996, provides standards to protect individually identifiable health information which a system creates, receives, maintains, or transmits in electronic form.

The Protected Health Information (PHI) is your personal healthcare data, and the information included there is what HIPAA addresses in its guidelines in order to keep PHI private and confidential.

Doctors, nurses, and insurance companies are the covered entities, as individuals in a healthcare field that have access to PHI.

The HIPAA law also takes in consideration lawyers, accountants, administrators, and IT personnel that work with a covered entity in a non-healthcare capacity that can also have access to PHI. These are the Business associates, and many of them are responsible for maintaining HIPAA compliance as covered entities.

Why does your infrastructure need to be HIPAA-compliant?

The Office for Civil Rights (OCR) at the U.S. Health and Human Service (HHS) released a HIPAA Audits Industry report with OCR’s findings from HIPAA audits the agency conducted in 2016-2017. These are some of the findings:

• Only 2% of covered entities fully met the requirements, and two-thirds failed to or made minimal or negligible efforts to comply.
• 89% failed to show they were correctly implementing the individual right of access.
• Approximately 70% of covered entities used breach notification letters that failed to satisfy regulatory content requirements, such as a description of the electronic personal health information (ePHI) breached and steps individuals can take to protect themselves from additional harm.

The report serves as a reminder of the seriousness in which OCR treats HIPAA compliance obligations, and healthcare organizations and their business associates need to address basic best practices. Of course, there are also HIPAA fines for those who do not meet HIPAA compliance law.

How Sysdig Secure helps you achieve HIPAA compliance

Software applications intended to be HIPAA-compliant need to adhere to certain standards.

Inside Sysig Secure, you will find the different controls that will tell you if your workloads do or don’t pass that particular HIPAA control.

For every control, you can find a small snippet with information (green box) about the particular control, why it’s needed, and how we actually check it.

In the following example, Sysdig checks if Audit/System logs are being captured for all application servers, database, caching layer, or any other components used in a HIPAA-compliant service. In case of a HIPAA breach, this data can be used to track the users who were accessing the system during that time. Also, we can identify the users whose data was compromised.

Sysdig Secure provides a section with guided remediation actions (red box) you can take in case you do not pass the control.

HIPAA compliance for workloads running on AWS cloud

So whether your workloads are running on an on-prem environment or if you have already migrated them to the AWS cloud, Sysdig Secure will help you with the security posture of your HIPAA compliance software.

Because healthcare information is such a sensitive asset, there are many important privacy and security risks you will want to avoid in healthcare software applications:

• Breach of confidentiality when collecting sensitive data.
• Unauthorized access to data stored on devices.
• Deceptive distribution of software to the patient.
• Violation of privacy during transmission to the provider’s system.

Conclusion

There are still pitfalls to overcome, but technology has already changed the concept that many people had of healthcare. Telemedicine, electronic prescriptions, or shared diagnoses through a platform are the new way to interact with health professionals, minimizing risks and saving time.

Security governance and compliance can no longer be an afterthought for healthcare IT leaders.

Sysdig Secure helps you protect your applications to avoid HIPAA fines and pass the HIPAA compliance controls. Want to see for yourself? Get started for free today!

The post Confidently deliver HIPAA compliance software with Sysdig Secure appeared first on Sysdig.

When thinking about the different mechanisms to protect privacy and gain trust from the users who utilize our services, Compliance is one of the words that comes to mind. Whether an organization is part of health and pharmaceutical, finance, government, or any other field, it will have to follow regulatory standards (e.g., SOC2, NIST 800-53, PCI-DSS, GDPR, etc.).

In the case of GDPR, the first function of compliance is to detect possible data protection violations, and prevent them. After all, a fine for a GDPR violation can be as high as 20 million euros, or 4 percent of a company’s annual global revenue from the year before – whichever is higher.

Let’s discover how to validate GDPR compliance for AWS with Sysdig!

What is GDPR?

The GDPR or General Data Protection Regulation is one of the regulations you must follow if you process personal data from EU citizens, or if you are located in the EU and are a processor of personal data. This personal data includes a person’s name, government ID numbers, the location information, as well as IP addresses, cookies, and other data that lets companies track users as they browse the internet.

GDPR aims to enhance personal privacy rights, requiring that companies take specific measures to ensure the safety of personal data.

It also mandates the implementation of mechanisms for end-users to retrieve, review, correct, or remove their personal data.

Finally, it also requires breach reporting, directing companies that have lost control over customer data, or that’ve been hacked, to notify users within 72 hours.

Although the GDPR laws were passed in May 2018, they haven’t been enforced until recently. The EU privacy watchdog, the European Data Protection Supervisor (EDPS), has started to focus their attention on companies offering services to EU citizens. So despite a timid start, fines are now gathering pace. It is only a matter of time before regulators build up sufficient confidence to enforce GDPR laws more forcefully.

If you want to dive further into GDPR, you may be interested in “GDPR explained for DevOps engineers.”

Why your AWS infrastructure needs to be GDPR compliant?

AWS offers some sort of functionality that will help you accomplish about halfway of being AWS GDPR compliant.

After all, AWS follows a shared responsibility model, so the other half has to be implemented within your service architecture. If you are utilizing AWS as your cloud provider, you have some homework to do.

Amazon Elastic Container Service (ECS) and its Kubernetes version (EKS), Amazon CloudSearch, and Amazon ElasticCache for Memcached are not cleared for encryption — only deletion and monitoring of processing.

Those are the kind of controls that fall on your side.

How Sysdig Secure helps you achieve AWS GDPR compliance

In June 2021, we made curated controls in Sysdig Secure available to help your company be AWS GDPR compliant across your cloud infrastructure.

You can use compliance reports as a proof of compliance for auditors.

Under the Compliance sidebar menu, you’ll find GDPR AWS as one of the compliance standards that Sysdig Secure implements.

This view will help you keep track of your security compliance posture. At a glance, you’ll be able to check how many controls of GDPR AWS you are passing.

And for those that are failing, you can quickly identify remediation actions inside Common fixes.

But sometimes it’s not evident why a control is needed and what steps would help you pass it. That’s the exact information you can find in the detailed explanation under each control.

Compliance is something that evolves constantly. Configuration changes can improve or reduce your compliance status, which is why these reports are scheduled to run on a recurring basis. That way, you can measure your security compliance over time.

But there’s more… GDPR compliance for workloads

In addition, Sysdig Secure also allows you to be GDPR WORKLOAD compliant even if you still have your workloads in your local datacenter.

We take care of kernel system calls, Kubernetes audit logs, host benchmarks, and security features that affect hosts, containers, and Kubernetes clusters.

Conclusion

Understanding the GDPR law and how it affects your AWS infrastructure will help you reduce legal problems and increase competitiveness when offering your services to EU citizens. Remember, we live in a globalized world! Your clients are everywhere on the planet.

Keep in mind that companies found in violation of the law can face very steep fines. The maximum fine for a GDPR violation is 20 million euros, or 4 percent of a company’s annual global revenue from the year before – whichever is higher.

Sysdig Secure helps you protect your data and be AWS GDPR compliant, whether you use cloud computing services or have your workloads locally. Want to see for yourself? Get started for free today!

The post AWS GDPR compliance with Sysdig Secure appeared first on Sysdig.