devopsy.kinsta.cloud

Tag: Cloud Security

  • Permiso Makes Open Source Tool to Identify Cloud Threats Available

    Permiso Makes Open Source Tool to Identify Cloud Threats Available

    Permiso today launched an open source tool dubbed CloudGrappler that surfaces indicators of compromise in cloud computing environments.

    Based on a cloudgrep project originally created by Cado Security, CloudGrappler detect patterns that Permiso, a provider of an identity threat detection and response platform, associated with tactics and techniques commonly used by various cybercriminal syndicates.

    The tool enables DevSecOps teams to define the data sources they want to scope in a scan of an Amazon Web Services (AWS) or Microsoft Azure cloud. Via a JSON file, DevSecOps teams can access a list of predefined tactics, techniques and procedures (TTPs) that are commonly used to exploit cloud computing environments. DevSecOps teams can also dynamically add queries or a file with multiple queries to scan a specific data set. After scanning, CloudGrappler delivers a JSON report that provides a breakdown of the scan results.

    Ian Ahl, senior vice president for P0 Labs, the research arm of Permiso, said that capability makes it possible for DevSecOps teams to identify issues in cloud computing environments that warrant further investigation before there is a major incident. The primary goal is to make it simpler for DevSecOps teams to determine if they need additional assistance to thwart a potential threat, he added.

    Cybercriminals are, like almost everyone else, creatures of habit and often tend to leverage the same TTPs multiple times simply because they know they’re effective. However, those TTPs also provide clues to their presence in an IT environment. Once discovered, a DevSecOps team can decide if they can remediate the issue themselves or need to tap external cloud security expertise, noted Ahl.

    In general, cloud computing environments may be more secure than most on-premises IT environments. However, the processes used to provision cloud computing environments are often flawed because developers typically don’t have much cybersecurity expertise. Misconfigurations are often rife across cloud computing environments.

    Cybercriminals are also especially adept at stealing credentials to gain initial access to cloud computing environments, which they leverage to escalate privileges in a way that provides them unfettered access to the entire cloud computing environment.

    Adoption of DevSecOps best practices has improved cloud security, but there are still plenty of instances where, for example, a port inadvertently left open has enabled cybercriminals to infest a cloud computing environment with malware that could lie dormant within cloud applications for months before finally being activated.

    There are simply not enough cybersecurity experts available to secure cloud computing environments, so it’s going to be largely up to DevOps teams to secure them. The issue is that in the race to build and deploy applications as quickly as possible, cloud security best practices are either forgotten or simply ignored. Of course, it’s that very carelessness that cybercriminals are counting on to allow them to wreak havoc in an era where the percentage of mission-critical applications running in cloud computing environments will only continue to increase exponentially.

  • Survey Sees Limited DevSecOps Progress Being Made as Vulnerabilities Mount

    Survey Sees Limited DevSecOps Progress Being Made as Vulnerabilities Mount

    A survey of 2,037 IT and security professionals conducted by the Cloud Security Alliance (CSA) on behalf of Dazz, a provider of a platform for mapping cloud computing environments, finds well over a third of respondents (38%) estimated that 21-40% of their code contains vulnerabilities, while 19% estimated 41-60% of their code contains vulnerabilities. Another 13% estimated they have vulnerabilities in 61-80% of their code.

    As a result, organizations on average have 55.5 security vulnerabilities each day in their remediation queue, with typically at least one being deemed critical, the survey finds. Overall, the average number of vulnerabilities that could be addressed is 1,025 per month, but organizations typically only address 270 within a month.

    In general, there are four phases to a remediation with each phase, on average, requiring between three to six hours so it easy to see how some organizations with limited resources can reach a point where they never catch up. The report noted that more than half of the vulnerabilities that have been remediated reoccur within a month, often because the root cause was never adequately addressed.

    Hillary Baron, senior technical director for research for CSA, said the high number of vulnerabilities that need to be regularly addressed suggested that progress in adopting DevSecOps best practices remains limited. While not every vulnerability is equally critical, it’s clear application development and cybersecurity teams are not yet proactively addressing application security issues, she noted.

    In fact, the survey found that less than a third (30%) of respondents reported there is a good working relationship between the application development teams that typically provision cloud computing environments and the cybersecurity teams that usually are held accountable for maintaining cloud security. Just under half of respondents (49%) said their vulnerability remediation teams comprised four to six members. Most respondents (60%) found it somewhat difficult to identify code owners, with an additional 24% facing moderate difficulty and 5% that found it highly challenging.

    Dazz CTO Tomer Schwartz said the more dynamic application development becomes, the bigger the DevSecOps challenge. Most organizations lacked the visibility required to proactively correlate their DevSecOps practices, he added. For example, more than three-quarters (77%) of respondents said they lacked full transparency into their cloud computing environments, and 6% had no visibility at all.

    In total, the survey finds organizations typically employ a variety of scanning and detection tools to safeguard their cloud environments, with 32% using five to six tools while another 29% report using three to four tools.

    More than three-quarters of respondents (76%) also noted that one in 10 of the alerts these tools generate is a false positive.

    Just under 75% of respondents also noted security teams spend more than 20% of their time performing manual tasks when addressing vulnerabilities, even though 83% reported using at least some automation in their remediation process. A full 61% also noted their organization is using three to six different detection tools, with nearly half (45%) considering increasing their security budgets in 2024, so it’s likely that many will be adding additional tools. In total, 22% dedicated less than 20% of their budget to cloud security, compared to 31% that allocated 21-40% of their budget and 27% that invest 41-60% of their budget to securing cloud environments.

    Unfortunately, less than a quarter (24%) said they feel very prepared for the cybersecurity threats their organization faces. Much of that uncertainty stems from knowing just how many vulnerabilities there really are in production environments and that they are being attacked with greater frequency each day.

  • Avoiding Mistakes in Multi-Cloud Configurations

    Avoiding Mistakes in Multi-Cloud Configurations

    The digital sky is bursting with clouds of every kind, and organizations are reaching out to grasp several at once. They seize the opportunities offered by diverse cloud providers, breaking free from the confines of a single vendor. Their approach is a powerful strategic move. Its promise—slashed costs, bolstered resilience and unmatched data back-ups; its bottleneck—configuration issues. And the tightrope between reaping multi-cloud benefits and stumbling into cybersecurity risks is thin.

    “The foremost area where IT leaders have to adapt is cybersecurity,” said Aleksandr Morozov, a cloud security researcher and CTO at Oasis Defender. “As digital interactions multiply, so does our vulnerability to cybersecurity threats. We have to defend against attacks, safeguard data privacy and adhere to international regulations. The adequacy of cybersecurity measures we take directly impacts business integrity and consumer trust.”

    Given these stakes, multi-cloud configuration seems to be an even more tricky aspect to stay on top of. Any slip-ups can spiral into escalating costs, performance hitches and glaring security vulnerabilities. Knowing how to configure multiple clouds mistake-free is essential to keep the promise of multi-cloud alive.

    Multi-Cloud Adoption is Escalating

    On the brink of adopting multiple clouds, a question arises: Why pay more when you can pay less and get more? Organizations steer towards the most cost-effective cloud services, making sure each application finds its optimal cloud match to optimize performance and costs.

    The global march toward digital transformation results in a whopping 92% of organizations already using a multi-cloud approach or in the process of adopting one. Statistics suggest an average usage of 2.6 public clouds and 2.7 private clouds among organizations.

    The multi-cloud setup beckons organizations to distribute their workload across a spectrum of cloud services, each boasting unique benefits. This distribution not only fuels innovation but also provides organizations with robust data recovery mechanisms to use in the event of breaches.

    Multi-cloud also flings open the gates to escape vendor lock-in. No longer shackled to the offerings of a single cloud provider, organizations go for cherry-picking cloud features, explore diverse pricing options and choose geographical locations for sensitive data storage.

    In many regions worldwide, stringent local data regulations dictate the storage of sensitive data within that region’s borders and within specified cloud environments. By leveraging multiple clouds, global organizations can stay compliant with relevant regulations and data governance policies.

    With digital transformation beckoning, organizations are just beginning to harness the benefits of multi-cloud. However, with multiple clouds come multiple risks. Configuring and orchestrating several clouds typically pose challenges, and businesses across industries require robust multi-cloud tools and strategies in place.

    These Industries Need Multiple Clouds More Than Others

    The shift towards a multi-cloud paradigm among businesses isn’t merely a trend chase. It’s a strategic move to elevate operational processes.

    Although the use of a multi-cloud approach is bound with configuration and data breach risks, employing multiple cloud services from different providers brings game-changing benefits. This approach allows businesses to enhance flexibility and improve service monitoring and cost-efficiency—all while helping them better adapt to market changes and technological advances.

    On top of that, a multi-cloud strategy lays a solid groundwork for implementing advanced analytics and AI solutions. Businesses handling vast data, requiring high computational power, or having strict regulatory compliance needs stand to benefit most from this approach.

    “IT leaders must prioritize the infrastructure for remote work. It’s essential that this infrastructure supports seamless collaboration, regardless of geographical boundaries,” Morozov says.

    The global insurance sector is clearly betting big on multi-cloud, with statistics indicating an average use of 11.4 clouds in 2023. Insurance businesses handling massive amounts of sensitive customer data employ multiple clouds as the key to operational efficiency and compliance with data regulations.

    Banking and finance organizations stick to strict industry regulations and use multi-cloud environments to save costs, improve data security, and recover data easily. They seek to use the best features offered by multiple cloud providers to meet data storage rules and avoid reliance on a single provider.

    Besides, financial service organizations often experience rising costs and growing operational issues. That urged them to shift to a multi-cloud approach — their great strategic move. With this transition, they can see a 40% drop in spending by having a clear view of cloud activities across various regions.

    Similarly, health care businesses embrace multi-cloud to distribute workloads across different cloud services and keep their critical and sensitive data secure. They need a reliable backup in case of system failures to improve and maintain high standards of patient care and operations.

    The telecommunication sector is no less in need of a multi-cloud approach. In this field, escaping vendor lock-in and optimizing costs by combining a variety of vendors serve as the propelling forces.

    Retailers typically use around eight clouds from multiple vendors. Their multi-cloud strategies are cost-efficient, help improve scalability, and enhance customer experience by tailoring different cloud services to specific workloads and geographical locations.

    Configuration Mistakes: Why They Occur While Managing Multiple Clouds

    Managing many clouds means juggling a set of rules and systems from various cloud providers. Different settings in each cloud platform can lead to errors, especially when getting clouds to work together. Even a minor mistake can cause issues affecting performance, security, and costs.

    Besides, handling multiple clouds requires special talent. To err is human; common errors involve setting up access controls incorrectly, mismanaging user permissions or incorrectly configuring workloads. Small oversights lead to huge security and operational problems, and without the right training or experience, the chances of making errors increase.

    Configuration mistakes often come from the complex nature of multi-cloud setups. Moving into many clouds means dealing with different infrastructures, APIs, databases, networks, and security systems daily.

    The complexity of multi-cloud makes getting a full view of the whole setup tricky. This lack of clarity can hide configuration mistakes, letting them linger undetected or delaying fixing processes.

    Last but not least, different policies across cloud environments also complicate things. Each cloud setup might have its specific policies and configurations. Without reliable tools, clear rules and ongoing learning, configuration mistakes are imminent.

    How to Avoid Multi-Cloud Configuration Mistakes With AI

    Navigating through multiple clouds can feel like sailing in stormy seas, and organizations need robust tools and reliable solutions to mitigate performance issues and stay safe.

    AI-driven software allows for unified visualization and configuration of multi-cloud security. Let’s see how it aids in the journey.

    Unified Dashboard

    Multi-cloud management solutions bring together data from different cloud providers onto a single dashboard. This makes it easier to see and manage security across an organization’s cloud setup, making the process less complicated.

    Smooth Integration

    A unified interface helps different cloud systems work together smoothly. That means fewer errors and better cooperation between cloud environments.

    Better Visibility

    Having data put together, organizations get a better view of security setup across different clouds. They can see and fix issues faster while keeping multiple clouds secure.

    AI and Machine Learning

    Solutions hinge on using intelligent technology to spot potential threats quickly. Fast actions help reduce the negative impact of any security issues and keep multi-cloud setups shielded from breaches.

    Compliance Monitoring

    The cloud setup has to align with industry rules and standards, which becomes more complicated while using multiple clouds. Using a unified system, organizations can stay compliant and avoid legal issues.

    AI-driven solutions offer an intelligent way to untangle the complex knots of multi-cloud configurations while assuring a safer and more efficient multi-cloud experience.

    Final Thoughts

    The multi-cloud trend is on the rise, offering both opportunities and challenges for organizations. It allows businesses to pick cloud features from multiple providers, easily comply with regional data rules and avoid being tied to just one vendor.

    Different sectors like finance, health care and retail are adjusting their cloud strategies to adopt multi-cloud. Yet, configuring multiple clouds is a tough nut to crack. Diverse policies, different settings across cloud platforms and possible human error complicate multi-cloud configuration.

    However, AI-driven tools can offer a unified dashboard for a better view and management of security across cloud platforms, simplifying multi-cloud setups. Using AI and machine learning for managing clouds leads to quicker threat detection and resolution and helps organizations keep their strategies within legal limits.

    In the multi-cloud discourse, careful configuration supported by AI is a key to receiving multi-cloud benefits while managing the risks efficiently.

  • Snyk to Add ASPM Platform via Enso Security Acquisition

    Snyk to Add ASPM Platform via Enso Security Acquisition

    Snyk this week announced it plans to acquire Enso Security, a provider of an application security posture management (ASPM) solution that tracks events and analyzes metadata collected from DevOps and security tools.

    At the same time, Snyk revealed it has added a DeepCode AI Fix tool that creates validated fixes for code written by either humans or machines and an Insights tool that helps organizations better prioritize remediation efforts based on the risk to the business. DeepCode AI Fix extends the capabilities of a generative artificial intelligence (AI) capability based on large language models (LLMs) that Snyk gained with the acquisition of DeepCode in 2020.

    Manoj Nair, chief product officer for Snyk, said all of these initiatives represent an effort to extend the reach of Snyk’s portfolio to address a wider range of issues within the context of a larger DevSecOps workflow as well as give developers tools that enable them to write more secure code.

    The acquisition of Enso Security is expected to close this quarter. The company has been making a case for an ASPM platform that eliminates the need to manually collect cybersecurity data from the various tools and platforms that a DevOps team may be using.

    Despite innumerable cybersecurity concerns, the rate at which applications are being deployed and updated continues to accelerate. The Enso platform makes it possible for cybersecurity teams to keep pace with those projects by discovering issues before an application is deployed in a production environment.

    The challenge, of course, is that most development teams are not going to be able to address every issue before an application needs to be deployed. In addition to knowing who is developing what application code, cybersecurity teams need to also prioritize potential issues versus rather than just sharing a list of potential issues that have been discovered. Enso Security’s ASPM platform provides visibility into events so that it’s simpler for cybersecurity teams to trace issues back to individual developers or the AI platform that generated them.

    That latter issue is becoming more significant as more development teams rely on general-purpose generative AI platforms to write code, noted Nair. Those platforms are writing that code based on samples collected across the internet, many of which are deeply flawed from a cybersecurity perspective, he added.

    The Enso platform is intended to enable cybersecurity teams to have the most impact on an application development project without being forced to interrogate every developer to determine what’s occurring in any application environment. In fact, one of the reasons developers resent those conversations is they know all the relevant data has already been entered into a system—cybersecurity professionals just need to access it.

    There’s still a lot of work to be done when it comes to bridging the historic divide between cybersecurity professionals and application developers. However, the more data that can be seamlessly shared between these teams, the simpler it becomes for organizations to embrace DevSecOps best practices.

  • AppSec in the Cloud: What DevOps Teams Should Know

    AppSec in the Cloud: What DevOps Teams Should Know

    Cloud application security refers to the measures and controls that are put in place to protect cloud-based applications and data from cyberthreats, unauthorized access and data breaches. These measures can include technical controls such as encryption, access controls and secure networks, as well as operational controls like policies and procedures for managing and securing data in the cloud.

    Cloud application security is important because it helps to ensure the confidentiality, integrity and availability of data and applications in the cloud. It is especially critical for organizations that store sensitive or regulated data in the cloud, as a security breach could have serious consequences for the organization and its customers.

    There are many different approaches to cloud application security, including the use of security protocols, identity and access management (IAM) systems and security information and event management (SIEM) tools. Some organizations may also choose to use cloud security platforms, which provide a range of security services and tools that can be used to protect cloud-based applications and data.

    How DevOps Secures the Cloud

    DevOps is a software development approach that aims to optimize the collaboration and communication between development and operations teams to deliver software more quickly and efficiently. It involves using automation, continuous integration and delivery and other tools and practices to streamline the software development process.

    Cloud security operations, or CloudSecOps, refers to the practices, processes and tools used to secure and manage cloud-based applications, systems and data. CloudSecOps is a key aspect of DevOps, as it helps to ensure that cloud-based applications and systems are secure and compliant, while also allowing for rapid deployment, scaling and management of applications in the cloud.

    There are several key ways that CloudSecOps can be implemented in the cloud as part of a DevOps approach:

    • Automated security testing: CloudSecOps can be implemented using automated security testing tools, which can be integrated into the CI/CD pipeline to continuously test and validate the security of code changes.
    • Identity and access management: CloudSecOps involves using identity and access management (IAM) systems to control and monitor access to cloud-based resources. These systems can be integrated into the DevOps process to ensure that access to cloud-based systems is properly managed and secured.
    • Security as Code: CloudSecOps can be implemented using security-as-code practices, which involve writing security policies and controls in code and integrating them into the CI/CD pipeline. This allows organizations to automatically enforce security controls as part of the software development process.

    4 Cloud Application Security Best Practices

    Understanding and Monitoring Dependencies in Cloud Applications

    Application dependency mapping is a technique that can be used to visualize and understand the dependencies between different components of a cloud application. This can help organizations identify and manage the risks associated with dependencies and ensure that all application components are up-to-date and secure.

    There are several key benefits to using application dependency mapping as a cloud application security best practice:

    • Improved visibility: Application dependency mapping provides a clear and comprehensive view of the dependencies between different components of the application, which can help organizations to better understand the risks associated with these dependencies.
    • Improved risk management: By understanding the dependencies between different application components, organizations can identify and prioritize the most critical dependencies and take steps to mitigate any associated risks.
    • Improved security: By regularly monitoring dependencies for updates and vulnerabilities, organizations can ensure that all application components are secure and up-to-date.
    • Improved compliance: By understanding and managing the dependencies between different application components, organizations can ensure that they meet compliance requirements for storing and processing data in the cloud.

    Cloud Database Security

    Cloud database security is a critical aspect of cloud application security, as it involves the measures and controls that are put in place to protect data stored in the cloud from cyberthreats, unauthorized access and data breaches. 

    Ensuring the security of cloud-based databases is important because these systems often store sensitive or regulated data. A security breach could have serious consequences for the organization and its customers.

    There are several key best practices for ensuring the security of cloud-based databases:

    • Encryption: Encrypting data at rest and in transit can help to protect against unauthorized access to data stored in the cloud.
    • Access controls: Implementing fine-grained access controls can help to ensure that only authorized users have access to data stored in the cloud.
    • Security monitoring: Monitoring for security events and anomalies can help to identify and respond to potential threats to data stored in the cloud.
    • Compliance: Ensuring that cloud-based databases meet compliance requirements for storing and processing data is an important best practice to protect against data breaches and ensure regulatory compliance.

    Apply Cloud Governance Policies

    Cloud governance refers to the practices, processes, and controls used to manage and govern the use of cloud-based resources and services. Some of the key ways that organizations can apply cloud governance policies to improve the security of their cloud-based systems include:

    • Establishing policies for access and use: Organizations can establish policies that define who has access to cloud-based resources and how they can be used. This can help to ensure that access to sensitive data and systems is properly controlled and monitored.
    • Implementing security controls: Organizations can implement security controls such as encryption, access controls and secure networks to protect data and systems in the cloud.
    • Ensuring compliance: Organizations can establish policies and procedures to meet compliance requirements for storing and processing data in the cloud.
    • Monitoring and auditing: Organizations can establish policies for monitoring and auditing the use of cloud-based resources to ensure that they are being used in accordance with established policies and procedures.

    Identify, Categorize and Protect Sensitive Data Stored in the Cloud

    Sensitive data refers to information that is highly confidential or regulated and that requires special protection to ensure its confidentiality, integrity, and availability. There are several key steps that organizations can take to identify, categorize and protect sensitive data stored in the cloud:

    1. Identify sensitive data: The first step is to identify the sensitive data stored in the cloud. This may include personal data, financial data, intellectual property and other types of sensitive information.
    2. Categorize sensitive data: Once the sensitive data has been identified, it is important to categorize it based on its level of sensitivity and the potential risks associated with it. This can help organizations to prioritize the protection of different types of sensitive data.
    3. Protect sensitive data: There are several different measures that organizations can take to protect sensitive data stored in the cloud, including encryption, access controls and secure networks. It is also important to implement policies and procedures to ensure that sensitive data is handled and processed securely.

    Conclusion

    In conclusion, application security in the cloud is a critical concern for DevOps teams, as it involves the measures and controls that are put in place to protect cloud-based applications and data from cyber threats, unauthorized access, and data breaches. 

    To ensure the security of their cloud-based systems, DevOps teams should implement a range of best practices, including understanding and monitoring dependencies, implementing security controls, managing identities and access, and ensuring compliance. By following these best practices, DevOps teams can help to ensure the security and integrity of their cloud-based systems and protect against potential threats.

  • The Missing Link in DevOps Cloud Security

    The Missing Link in DevOps Cloud Security

    We’ve all seen the data from the latest Verizon Data Breach Incident Report that shows half of security breaches stem from credential abuse. It’s clear that credential compromise is an epidemic in cybersecurity and can be largely avoided with multifactor authentication and least-privilege policies. Misused credentials have shot up by almost 30% over the last five years, according to Verizon. Engineers and developers are not immune to this plague; they may be even more attractive to attackers because admin privileges allow access that reaches far beyond that of the everyday user. In fact, they are often granted always-on access when, in reality, they only need brief, intermittent access to get their job done. According to Gartner, privileged access carries significant risk. Even with PAM tools in place, the residual risk posed by users with standing privileges remains high. They recommend identity and access management (IAM) leaders implement just-in-time (JIT) strategies and, eventually, reach a posture of zero standing privileges.

    Giving engineers right-sized permissions with only the privileges they need to carry out specific tasks is especially important when these credentials are used to stand up or make changes to production resources.

    Just in Time for Developers

    JIT inventory management has been standard in many industries for decades. Especially in manufacturing, where factories can’t afford to have supplies sitting in the warehouse unused, assembly lines lying idle or have production at a standstill while waiting for parts. In information security, JIT management grants users privileged access for only the amount of time needed for a user to complete a task. This helps minimize the attack surface and avoid the risk caused by long-standing unrevoked privileges.

    In today’s agile environments, development engineers need to move and fix things fast. For example, cloud infrastructure environments are usually set up and maintained by DevOps and development teams via continuous integration/continuous delivery (CI/CD) pipelines. But developers sometimes also need direct, highly privileged access to production environments for more specific tasks.

    While static privileges that allow developers to perform day-to-day tasks are typically provided through the network’s IAM system, organizations often lack the ability to grant and revoke privileges dynamically for cloud environments. That’s because traditional on-premises privileged access management (PAM) and identity governance and administration (IGA) solutions don’t support cloud-native—and increasingly multi-cloud—infrastructures.

    Developers will always need quick, highly privileged access to sensitive cloud environments for activities such as debugging or manual deployment of a service. But those wide-ranging entitlements don’t need to be permanent and can introduce a significant risk if they’re not revoked once the job is done.

    This has left organizations resorting to risky, overprivileged practices. Inactive accounts are the source of many cybersecurity headaches. In fact, that is how cybercriminals breached the network of Colonial Pipeline in last year’s ransomware attack that shut off gas supplies. Overprivileged accounts are another big headache, which was a big factor in the now-famous SolarWinds attack.

    JIT Access

    This is where JIT access comes into play, and can enforce highly granular entitlement management for privileged access in the cloud. Gartner has become an advocate of JIT since it enables a number of security best practices. They recently advised security leaders to implement “a process for quick and easy requesting and granting of additional privileges with minimal disruption to an individual’s workflow.”

    One of the biggest challenges to implementing JIT privilege management is provisioning. Security staff is overtaxed, especially as the adoption of multi-cloud environments keeps adding complexity to their work. Provisioning individual, temporary permissions for each task becomes onerous when there is so much more to oversee.

    JIT privilege management for the cloud has to meet developers’ need for speed, self-sufficiency and transparency. One approach is to use a self-service portal that accepts requests for elevated privileges, manages the approval process, grants authorized permissions and automatically revokes them when they expire.

    A JIT Framework for Developer Security

    This framework provides security and productivity benefits.

    First, it minimizes the cloud attack surface by enforcing temporary and granular least-privilege policies. This prevents attackers that have compromised a user’s credentials from using excessive permissions to access sensitive resources and exfiltrate data.

    Second, it saves engineering teams time and effort by enabling them to quickly submit a request, notify approvers and gain temporary access. This automated workflow eliminates delays and allows DevOps staff to get their work done more rapidly and securely.

    Finally, monitoring user activity during elevated privilege sessions makes it possible to generate reports for all JIT access requests and authorizations to enforce security policies. It also creates an audit trail for forensic analysis in a security incident.

    When implementing a JIT framework for cloud privilege management, consider the following best practices:

    Look for tools that offer developers a seamless experience through a self-service portal. This saves everyone time by automating the submission, processing, approval and logging of access requests.

    Define owners for each step of JIT approvals including who manages eligibility, who approves the scope of access and who reviews requests.

    For low-risk access requests or those involving non-production environments, use policies that eliminate the need for human intervention. The system should be able to log requests, assess the stated reason for the escalated privileges and the timeframe and respond rapidly.

    Reducing the Attack Surface With JIT

    Giving DevOps staff unfettered access to sensitive resources, especially in production environments, for extended periods of time violates basic security hygiene best practices. JIT privilege management enables organizations to keep engineering activities on track and on time without incurring excessive risk. By reducing the attack surface associated with DevOps identities, even if a user’s credentials are compromised, a hacker will not have the keys to the proverbial kingdom. This will limit the blast radius of an attack.

    The challenge companies face is extending traditional privilege management capabilities to cloud environments. Fortunately, new cloud-native advances in IAM and PAM functionality are making it possible to close this missing link in cloud security.

  • Techstrong TV: The Future of Cloud Security

    Techstrong TV: The Future of Cloud Security

     

    Check Point Software has announced the acquisition of Spectral, an Israeli start up specialized in automated code security. This further reinforces Check Point’s commitment to cloud security. The video is above and a transcript of the conversation is below.

     

    Interviewer:                Hey everyone, welcome to another segment here on Techstrong TV. I’m really happy to have as our guest on this segment TJ Gonen, and hoping I pronounce that right, from Check Point. Hey TJ, welcome to Techstrong TV.

     

    Interviewee:                Yeah, and thank you very much for having us.

     

    Interviewer:                It’s a pleasure. Is that the right way to pronounce your name?

     

    Interviewee:                No, Gonen is the right way. Yeah. TJ is the name that they changed so no one butchers it.

     

    Interviewer:                Well I hear you. It happens sometimes. Hey I really, as I mentioned to you earlier I like the 49ers, especially in a week where they had a tough game. LA, the Rams are going to the Super Bowl in LA and still it’s close.

     

    Interviewee:                Yeah, they almost made it, almost made it.

     

    Interviewer:                It was close, a lot closer than my team, so who am I to say anything. But yeah I know, good for them. Anyway we didn’t bring you on to talk football unfortunately.

     

    Interviewee:                Of course.

     

    Interviewer:                We’re going to talk security, and maybe that’s better off anyway. TJ, why don’t we start though. Why don’t you kind of give our audience a little bit of who you are, a little introduction. What you do at Check Point, stuff like t hat.

     

    Interviewee:                Yeah, sure. So TJ, originally from Israel. That’s a little bit of the accent, now in the US. I am the Vice President for Call Security at Check Point. So I run the Call Security business for Check Point, and been with Check Point for two years. Actually exactly two years since my company was acquired by Check Point a couple of years ago in the cloud security space.

     

    Interviewer:                Yeah, what company was that?

     

    Interviewee:                So we need to talk about another acquisition so it’s an interesting time.

     

    Interviewer:                Well it’s the circle of life. Right?

     

    Interviewee:                Yeah.

     

    Interviewer:                What was the company that was acquired two years ago, your company?

     

    Interviewee:                Ortega Labs. We were in the servalice security space, yeah.

     

    Interviewer:                Absolutely, and of course servalice is a huge, huge kind of growth area right now. But that was two years ago, as you said TJ, and congratulations to you on that. But we have a new Check Point act, so it’s the way of the world. We have a new Check Point acquisition to announce or talk about today. Why don’t you share with our audience a little bit?

     

    Interviewee:                Yeah, so we just a few days ago we announced the acquisition of a company called Spectral in the code security space, and it’s really our move into the developer first security world, and we’ve been very busy in the code security space for the last four years, Check Point through a series of acquisitions.

     

    Actually to call security business at Check Point started with one acquisition, a company called o9 ______ _____ ______ [crosstalk].

     

    Interviewer:                Sure. I know that 09, who was the founder of o9? Not _______.

     

    Interviewee:                Zor.

     

    Interviewer:                Zor. Yeah, I knew him when he started o9.

     

    Interviewee:                There you go, yeah. So awesome company. So that sort of started the journey, then a few acquisitions later including my company and now Spectral, that’s the fifth acquisition we’re actually doing in the code security space.

     

    So I think one of the things that we found out relatively early is that cloud security is almost trying to reinvent all of security. Reinvent it for the cloud and trying to do 30 years of security in 4 years, and it’s very hard to move without acquisitions.

     

    Interviewer:                Yes it is, and look, quite frankly my background is security, so I’ve been in security 25 plus years.

     

    Interviewee:                Yeah.  

     

    Interviewer:                It’s the reason I started devopsy.kinsta.cloud. It’s the reason I got so attracted to the whole DevOps thing, which was I really felt like it was a fresh chance for us to kind of right some past wrongs. Right?

     

    Interviewee:                Right. Yeah.

     

    Interviewer:                A new beginning, if you will. Now it’s funny, I remember in 2005 or from the first time I heard the term cloud security. The Cloud Security Alliance and Chris Hoff and a bunch of folks at RSI were doing a meeting. And back then we found that cloud security is very sort of one dimensional. Right.

     

    Interviewee:                Mm-mmm.

     

    Interviewer:                And but what we see now is it’s infinite in its variety. There is so many different aspects to securing cloud.

     

    Interviewee:                Very much.

     

    Interviewer:                And it’s important. You know, I was on with I think it was the Palo Alto folks yesterday with their latest cloud, Native Survey. For the first time their respondents, and keep in mind when you’re a hammer everything looks like a nail, TJ. Right? So their respondents are probably people in Cloud Native, because it was a Cloud Native survey.

     

    Interviewee:                Right. Right.

     

    Interviewer:                But they said 50 percent of their infrastructure – at least 50 percent was in the cloud.

     

    Interviewee:                Yeah.

     

    Interviewer:                That’s a big threshold.

     

    Interviewee:                It is a big, yeah.

     

    Interviewer:                Right. When you say okay, half of organizations’ infrastructure is in the cloud today, well cloud security really damn important then.

     

    Interviewee:                Yeah, it is very important. Yeah.

     

    Interviewer:                Yeah, and so it’s part, you know, there is reasons for it to be complicated. This acquisition is a little different than o9 or yours.

     

    Interviewee:                Yeah, it is.

     

    Interviewer:                Why is it different?

     

    Interviewee:                Yeah, so the biggest difference I say is the user, and one of the things that we found out over the last two, three years is there is a few trends that are coming down together. One of them is the shift left turn, which is very clear. That shift left is more of a security initiative. Right.

     

    A security initiative that says hey, if I can fix something, prevent vulnerabilities before they hit the ______ department I should do that. Okay. So now if you want to shift left then you are living – your tools are living inside the pipeline, the development pipeline, and they’re supposed to be suddenly used not by security people, but by developers or DevOps people.

     

    Interviewer:                Yeah, yeah, yeah.

     

    Interviewee:                So these suddenly developed tools that are supposed to be used by people first, not to insure that security is their first priority. That’s number one. Actually it’s probably not their first priority. Even if they care it’s not their first priority. Then number two they just are totally used to different environments.

     

    And you find out that the security company definitely like Check Point that’s been doing security for 30 years and yourself and myself who are older than 10 years old as you can see, at least on my side, is that we know how to develop products for security people.

     

    And to develop  products – security products for developers and DevOps people is just a different genetics. It’s a different DNA.

     

    Interviewer:                No, that it’s a different animal, man.

     

    Interviewee:                It’s a different animal. So we were looking at that and said okay, so one, we think that developer first cloud security is a real thing. I mean it’s very important and it’s going to be a very big part exactly to your point there, of the future of cloud security.

     

    So there is always going to be cloud security – security for security people, which is their own time environment, checking out their actual cloud infrastructure. Making sure that the facts are being blocked and all that good stuff. But when you are talking about developer first cloud security you’re going to have a different type of user. You’re going to need to integrate into different types of tool sets. You need to have different types of genetics.

     

    So that’s what you wanted to sell to Spectral is exactly that. So these guys, you know, I met them first time and I said literally I had a, you know, probably a moment where I said okay, that’s it. These guys just get it. They’ve built a product that developers love. They built a product that developers understand how to use.

     

    Just like the one of their customers told me. They said, you know, I ask him why do you like Spectral compared to the other alternatives like Sneak and maybe a couple of others? And he literally said with Spectral the first time I take the connect to this thing first it took me five minutes.

     

    The second thing, I started to use it, everything was exactly where I expected it to be. And he actually used the metaphor in iPhone, and I totally related to that. Where with IOS everything is you don’t know why, but everything is exactly where you want it to be. You don’t need to think.

     

    So they nailed down the developer experience, and it’s not just the user experience and they integrate with tens of tools right out of the gate. They integrate into the IT environment. It’s also one of the things that we as security people who develop products for security people take for granted that you cannot take for granted in developer world.

     

    I’ll give you just a very simple example. Because we assume we’re selling to security people we assume that they’re going to be okay with us screwing up once in a while. For example, false positives. Something will take a bit more time. It’s okay, because they’re security. That’s their job. I mean they don’t have anything else to do except waiting for you to do your job.

     

    When you are talking with developers and you are going to scan code for example, which is what Spectral does. They started the first was scanning for secrets, hard coded secrets inside code, whether it’s in the I keys and W S keys, fast ______, huge problem. I mean developers who aren’t really fast, they forget keys and secrets inside code. They find an attacker that’s easiest way in.

     

    So now you have tens of repos, hundreds of repos. _______ repositories, S stream buckets, so secrets can be everywhere. If I’m a developer and I’m pushing code and I’m waiting for you to scan, and it’s going to take two minutes I’m going crazy over it. Two minutes I’m going crazy. Five minutes I’m killing someone. Ten minutes I’m out of this.

     

    Interviewer:                I’m not doing it.

     

    Interviewee:                And finding a way to go around this.

     

    Interviewer:                Yeah, yeah, I’m not doing it no more. Yeah.

     

    Interviewer:                So this Spectral technology, that was really their core tech, which is really interesting. So they, it’s like keeping it really, really simple. They have the ability to scan huge amounts of code for problems. Now a problem can be secrets. A problem can be mis-configurations in infrastructure as code templates like _______ can be a bunch of missed spaces, but they can do that really fast.

     

    Literally we scan, when we do the due diligence we scan their entire – our entire repo, the checkpoint repo in seven seconds.

     

    Interviewer:                Wow.

     

    Interviewee:                The entire repo, 30 years worth of repo.

     

    Interviewer:                Oh shit. Oh.

     

    Interviewee:                Seven seconds.

     

    Interviewer:                Holy mackerel.

     

    Interviewee:                I know it’s an oh shit. I had an oh shit moment also. It’s so, and it’s not like that. And they were saying okay, something here is happening. Now and it was also super accurate and they found very interesting things.

     

    So once they nail down the user experience or the developer experience you understand how they work and integrated the tools. Then you solve a real, real problem, because that is a real problem and you solve it really fast. That’s why we totally like them.

     

    So we really looking at them and just to make it even more interesting to the point that we started with how different of a DNA it is. Because it’s such a different DNA we’re acting inside my unit, inside the cloud security unit we are leaving them independent. We are not touching them.

     

    I don’t want them to start talking security to security people. You guys get the developers. You understand how they work. You go,  you do you. Just keep on doing that thing. I don’t want to dirty them.

     

    Interviewer:                I got to tell you, I’m sitting here, you know the word kvelling? Have you ever heard that word in your life?

     

    Interviewee:                Yeah, I – yea.

     

    Interviewer:                Because so I started devopsy.kinsta.cloud in 2013. Right. And RSA I think 20, maybe it was 2015 RSA. I started what we call the DevSecOps Event within RSA. It was Monday of RSA week. Right.

     

    Interviewee:                Right.

     

    Interviewer:                And the idea behind it was to bring the security, the cyber whatever you want to call it, the security community together with the DevOps try with the developers. And I got to tell you the aggravation I had, you know, eight years ago. Security people, they don’t care about security, they’ll never care about security.

     

    Interviewee:                Exactly. Yeah.

     

    Interviewer:                They’re stupid. They’re this.

     

    Interviewee:                They’re the enemy. Yeah.

     

    Interviewer:                Right. And you know what the developers are. All they do is say no, they slow us down. They are a pain in the ass.

     

    Interviewee:                Exactly. Totally.

     

    Interviewer:                It was like this. It took me seven years of build, because I believed – I believed that no, security may never be their number one priority, but no developer I ever met raises their hand and says I want to develop in secure code.

     

    Interviewee:                They don’t care, no. Right. No.

     

    Interviewer:                I like crappy quality. I’m a crappy quality developer. You know what I mean? No one says that.

     

    Interviewee:                Right. Right.

     

    Interviewer:                They all, they have pride in what they do.

     

    Interviewee:                Yes, exactly.

     

    Interviewer:                The problem was, is we weren’t giving them tools that they could use.

     

    Interviewee:                Yeah.

     

    Interviewer:                They’re not CISSPs. They’re not ______ or scanning _______.

     

    Interviewee:                No, no, there were security incidents and try to do for _______.

     

    Interviewer:                No, they’re not compliance experts.

     

    Interviewee:                Yeah, exactly. You found the problem, tell me how to fix it. Be very specific. Don’t tell me how to fix it –

     

    Interviewer:                Don’t fix it because I want the quality. I want the quality. Yeah.

     

    Interviewee:                Exactly. And I think you are touching now on a very interesting point, because when you start to bundle these things or unwrap it actually let’s say, one is you’re right, it’s a new user so we talk about it. I actually think that security people today, and I can tell you now product group, that’s exactly how we think.

     

    We think about the developer and the DevOps guy and the ______ guy as a new type of user. He is a user to the security side. I need to think, I need to cater to his needs. Now what does he need? To your point earlier, he is not going to read forensic reports. He is not going to read the tax batchers. That is not his job.

     

    His job is to write quality code that is not vulnerable as much as possible. Now if you find the problem in what he does tell him how to fix it and tell him in his language. In his language. His language is not a dashboard with a search. It is not his language. It is not just a piece of code telling that piece of code is problematic. If you replace it with that piece of code you are good to go.

     

    Interviewer:                Done.

     

    Interviewee:                It’s such a different mindset. It’s like you all are security people. You’ve been around, I’ve been around. We immediately show dashboards and must moves. Who cares? The Spectral ops guys where they showed us a demo and it’s like your heart attack for any normal security person, because what do they show? A CLI.

     

    Interviewer:                Yeah.

     

    Interviewee:                They open the CLI. It’s like everything black screen CLI. Anyone from a security will say I don’t understand what they are doing, but their customers, that’s exactly what they appreciate. To integrate immediately. You are talking with the ex, that everything is API first.

     

    Yeah, there is a report somewhere that you can see in the background if you need, but everything works inside the development environment.

     

    Interviewer:                But this also goes TJ, and we’re probably over time. I apologize.

     

    Interviewee:                That is okay.

     

    Interviewer:                But this also goes that we need to redefine the relationship between the security team and the DevOps developers and the people who use this kind of tool, because what happens is look, it’s going to be the developer. Maybe the DevOps or the SRE, but it’s going to be those people who are instituting the changes to close down a vulnerability or fix something.

     

    Interviewee:                Right.

     

    Interviewer:                That doesn’t absolve the security team of responsibility. No one is saying hey security team, you’re out of a job. Or hey security team, you don’t got to worry about it anymore.

     

    Interviewee:                ______ no.

     

    Interviewer:                The security team still needs that report.

     

    Interviewee:                Exactly.

     

    Interviewer:                That forensics trail if you will, to say hey, yes this was found, this was fixed and this is how it was fixed. And that again is yet another kind of special talent to make a tool that’s easy enough or is in the DNA of the developer, but still gives the security team, the compliance team what they need to sleep well at night.

     

    Interviewee:                That’s why one of the best sentences I like and we used it also when we announced the acquisition is would invent it, people use it before, it’s security tools that developers love and security people trust. That’s the theme. Right. That is so true.

     

    Interviewer:                I may steal that from you.

     

    Interviewee:                Steal it, _______ it. It’s like ten cents a use, and I know it’s in the –

     

    Interviewer:                Okay. We’ll put you down. We’ll put you down. No, but it’s true.

     

    Interviewee:                That’s what you want. Right. That’s really where you want, because and you just described the part that what does it mean for me as a security person to trust the tool that you’re using, and to trust the work that you are doing with it. And I think it’s a very different – it’s very interesting.

     

    I’m thinking the future by the Allan, and I think you are sitting with devopsy.kinsta.cloud, just right on the money. Because the future of security looks like this. You’re going to have security people. They are going to more and more, that’s where it’s going to go. It’s not tomorrow, but that’s where it’s going to go.

     

    The traditional security people I call it the sandwich model. The traditional security people is going to be at the beginning in defining what is secure, or what does it mean to be? Is going to be at the end validating that security actually happened. The sandwich in the middle is going to be more than ever what in the future, more than today by far developers. It’s going to be cool.

     

    Security is code. Computer security people are going to define what’s needed. They are going to make sure that they are going to validate that it happened. These people in the middle are going to be more and more code people.

     

    Interviewer:                People who make it happen.

     

    Interviewee:                Code people. That’s the new security engineer. The new security engineer knows how to code. And that’s why we acquired Spectral and that’s why we are going to let them lead our developer first spot security initiatives, and we’re super excited about it.

     

    Interviewer:                I’m excited for you, and I’m glad to see Check Point coming out with this. It’s great. Hey, for people who want to get information on Spectral where do they go?

     

    Interviewer:                ______.com website. You are going to find immediately on the homepage a link to the information around the acquisition and you can also go and check out spectralops.io, the website of the company.

     

    Interviewer:                I love it. TJ, man thanks for coming on and talking with us.

     

    Interviewee:                You are welcome.

     

    Interviewer:                It was a great acquisition. We’re going to be watching others go. I think a smart move by Check Point. Hey, we’re going to take a break here on Techstrong TV. We’ll be right back with some more interviews and news and information. TJ, thanks very much.

     

    Interviewee:                Thank you very much. Thanks.

     

    [End of Audio]