devopsy.kinsta.cloud

Tag: IAM

  • Sonar Adds Secrets Detection to Code Analysis Portfolio

    Sonar Adds Secrets Detection to Code Analysis Portfolio

    Sonar has added a secrets detection capability to its portfolio of tools for analyzing code and DevOps workflows.

    Designed to be applied to both finding secrets in code repositories and as applications are developed using an integrated development environment (IDE), this capability is being added to SonarLint, SonarQube and the managed SonarCloud service to identify, for example, passwords, application programming interface (API) keys, encryption keys, tokens, database credentials and other private information.

    Sonar co-CEO Olivier Gaudin said the goal is to eliminate secrets that are accidentally or maliciously stored in source code to improve software supply chain security.

    While it’s important to discover secrets in codebases, Sonar is making a concerted effort to make it simpler for developers to discover secrets before they find their way into a codebase that is one step away from a production environment, noted Gaudin. The SonarLint static analysis tool the company provides can now discover secrets in microseconds using the syntactic and semantic analysis engines the company has now extended, he added. No developer is going to wait five to 10 minutes for a code scan to be completed, said Gaudin.

    A Learn as You Code tool also explains how each secret found in a code segment poses a security risk. The overall goal is not only to remove secrets but, ultimately, reduce the number of instances where secrets are discovered in code, said Gaudin.

    Most organizations today are at varying stages of embracing DevSecOps best practices to improve software supply chain security. It’s not clear how readily secrets management is being embraced as part of those modernization efforts, but as cybercriminals routinely scan for application secrets stored in clear text that can be used to compromise application security, the need to encrypt secrets becomes a higher priority.

    There is, of course, no shortage of tools for detecting secrets. Sonar is now simply making a case for managing secret detection as part of a larger effort to reduce vulnerabilities in code that cybercriminals can exploit. That approach should help reduce the total cost of securing a software supply chain at a time when forthcoming regulations are going to make organizations that deploy software more accountable for application security.

    In the meantime, thanks to the rise of generative artificial intelligence (AI), the volume of code that needs to be scanned will likely exponentially increase. The issue with general-purpose AI platforms such as ChatGPT is they were trained using code of varying quality that often contains vulnerabilities that are now sometimes incorporated into the code they generate. On the plus side, however, many developers have little to no application security expertise, so it’s just as feasible that ChatGPT will create more secure code than a human developer. Regardless of how the code was created, however, no one will know for sure how secure it is without scanning it first.

    Hopefully, as AI progresses, the quality of the code being generated will only continue to improve. Until then, DevOps teams should continue to assume all code is suspect until proven otherwise.

  • Why You Should Consolidate Your IAM

    Why You Should Consolidate Your IAM

    It’s not often you can get a win that makes your IT processes easier while simultaneously improving your cybersecurity. In fact, oftentimes making improvements in one area (for example, improving IT processes) comes at the cost of the other (cybersecurity). But there’s one area, in particular, where these improvements aren’t mutually exclusive: Identity and access management (IAM). In fact, consolidating the identity and access management technology used in your organization is one of the few ways to simplify and secure against threats at the same time. Let’s see why this is the case by focusing on each of those items individually and then look at the big picture.

    Let’s start with security. Properly managing identity and access is naturally a critical component of a good cybersecurity stance. If you aren’t properly managing access or don’t know who is leveraging your access tools, the rest of your cybersecurity stack won’t be of much help in keeping you out of the headlines. While that’s pretty obvious, the piece that’s easy to overlook is the consolidation of those tools. As organizations grow, they often find that rather than scaling solutions with teams, they pick up additional solutions for new teams, new locations, new vendors and so on. Suddenly, the original corporate VPN is now three, there are five different vendor access methods (all tied to different authentication methods or shared accounts), some users are in Active Directory, some only in GSuite and there are too many local accounts on applications to count. At the end of the day, each path to an application should be tied to a proper access tool with authentication and a known individual identity, but that becomes difficult or impossible to verify. At that point, it takes just a few questions to realize the security risks of disparate access solutions:

    • When something goes wrong, how do you verify who may have had access to that system? How many access solutions could have gotten a user there?
    • When John leaves the organization, how certain are you that all of his access will be revoked?
    • How do you know that all of these solutions are up-to-date with the required patches to remain secure?
    • Is there a comprehensive list of access methods the organization uses, or are you going to find some long-forgotten VPN in the future?

    So, the security implications quickly become obvious. Consolidating on a minimum number of required solutions means you can address those security gaps with simplification. It’s not often that you get the chance to do that in a world where security usually means adding another tool to the stack. The result of consolidating means your users, whether non-technical end users or IT admins, all see improved workflows. Fewer credentials for end users to manage and less chance they’ll need different access tools depending on the system they need to reach. From the IT side, it means your staff can quickly provision or deprovision access. It also means that when something does go wrong, a clear picture of all access to an affected system can be drawn up in minutes, rather than hours or days. When consolidating identity and access management tools, the following should be clear goals:

    • User authentication should enforce multifactor authentication (MFA)
    • Authentication should also include employment verification when third parties are involved
    • Access management should embrace a least-privilege access model, narrowing access to specific applications and even timeframes where applicable
    • An access solution should take into account the various needs of all user profiles at the protocol level. Some users may need a few web services, while others might need the right protocols to manage servers or custom applications
    • IT admins should be able to quickly identify all the access a user has and all the users with access to a given endpoint
    • History and audit is a given

    Keeping these items in mind when consolidating technologies should not only make it easy to find which tools are right for your organization, but which tools are in place today that should be the first to go. 

    In the end, all organizations have to face identity and access management challenges. Sometimes that’s a problem that can be tackled with a centralized solution from day one, but oftentimes it becomes a mess of tangled wires. Whether you’re starting from square one and building your technology set or you’re pulling those wires apart, the end goal of consolidated solutions is the best way to present a simple solution that makes your users happy while maintaining the security that your organization will depend on for years to come.

  • Techstrong TV: Styra Declarative Authorization Service

    Techstrong TV: Styra Declarative Authorization Service

    Styra’s new launch of Styra Declarative Authorization Service (DAS) for Cloud-Native Entitlements. With this solution, IAM teams can move to cloud-native technologies while still using existing systems-of-record as well as scale to the level that their organization requires. The video is below followed by a transcript of the conversation.

    Alan Shimel: Hello, everyone. Thanks for joining us on another TechStrong TV segment. Oh, I’m happy to have back on TechStrong TV today our friend, Tim Hinrichs, from Styra.

    Hey, Tim, welcome. How are you? 

    Tim Hinrichs: I’m doing great, Alan. Thanks for having me back on.

    Shimel: Yeah, it’s a pleasure to have you here. Tim, we always enjoy actually having the Styra folks on, whether it’s Bill, or you, or anyone else. Of course, Styra is a company that in the cloud native space has really kind of made a name for themselves. But though our audience is a cloud native audience and technical, they may or may not know Styra. They probably maybe have heard of Styra. They probably heard of OPA, but why don’t we kind of make sure everyone’s level set, Tim, and give them a little background?

    Hinrichs: For sure. Yeah, great. So, yeah, what Styra does is we help enterprises by providing them a unified solution to authorization. And so for folks that don’t know and don’t work on authorization every day like I do, just remember that authorization is this problem of controlling what actions that people and maybe software can take within a piece of software.

    So let me give you an example or two here. Every time I log onto my bank online, I can see all my bank accounts, but I may not be able to see my wife’s bank accounts. I may not be able to move money between her bank account and mine, and so that’s an authorization problem. It’s controlling what actions I can take. Can I withdraw money? Can I deposit money? So on and so forth. And so that’s one kind of authorization that we work on at Styra.

    But another good example is sort of at the developer level. So those websites that we all use every day, those are built by developers and developers are also taking action. And so one kind of action that they might want to take is they’re upgrading the software, or they’re deploying a database, or they’re changing some network configurations. Again, all of those are actions and there needs to be authorization controls in place to make sure that the right actions are being taken by the right people at the right time.

    And at Styra, we provide software that helps an organization sort of manage all of those permissions, all of those authorization policies across all those different kinds of decent software.

    Shimel: Excellent. Love it. And we might as well get it out of the way while we’re here, Tim. People who want to get more information on Styra, it’s Styra, S-T-Y-R-A, and it’s styra.com, correct?

    Hinrichs: Absolutely, yeah. Definitely check that one out.

    Shimel: Cool. All right, we’ve gotten that. Oh, you know what else, Tim? We didn’t even tell them about what your position at Styra is. We should give them that, too.

    Hinrichs: For sure, yeah. So my name’s Tim Hinrichs. I’m the CTO and co-founder at Styra and I spend part of my time working on our commercial product offerings, but then I spend the other part of my time on our open source efforts. And one of the things that we do in open source is we started the Open Policy Agent project, or OPA, as we like to call it, and then we donate it to the CNCF. So I’ve got a foot in both of those areas of work.

    Shimel: Love it. Hey, Tim, are you gonna be out at KubeCon in Spain in May, or planning it, not sure yet?

    Hinrichs: Not sure yet, but yeah, it would be great. I’d love to get back out, and start going back on that conference circuit, and seeing people, chatting with them about policy and authorization, and just seeing folks, again. I think it would be great.

    Shimel: We are currently planning on being there. We’re going to hopefully try to do some videos but a different sort of setup. I forgot what they’re calling it, something topist talks or something, so short, little, smaller segments. Again, assuming the world is right, we’ll be there.

    Anyway, but Tim, let’s focus in on what we want to talk about today, which is you guys recently announced a new offering. Tell us.

    Hinrichs: Yeah, for sure. So the new offering that we just released a little while ago, we call it the Entitlements Offering as part of our normal product called the Declarative Authorization Service. And so the idea behind this new offering is that it’s really designed to help organizations take custom applications and migrate them from on-premise data centers into the cloud more effectively, more quickly.

    And so the problem we kind of saw happening over and over was that if you’ve got one of these on-prem applications, especially an application that’s focused around helping your employees interact with each other or the organization as a whole, these employee-focused applications, a lot of those apps are dependent on what folks will call an on-premise entitlement service. So that entitlement service is often backed by LDAP, or Active Directory, or something, and it’s sort of just those applications sort of need to know which groups that employees are a member of in order to sort of grant permissions within the application.

    And so the challenge when you’re mind reading those kinds of applications into the cloud is that the cloud, what you don’t want to be doing is having an application running on the other side of the world and having to make a request all the way back to your on-premise LDAP or AD. The roundtrip time, the availability, the performance and availability, are just too poor. It’s sort of an anti-pattern in the cloud. And so these folks that we’re talking to are struggling because they want to migrate these applications in the cloud, but in order to do that, they also have to migrate those on-prem entitlement services to the cloud.

    And so this new offering from Styra really makes that easy. You sort of just hook it up to your LDAP or AD and then you can deploy that thing in as many cloud regions as you like.

    Shimel: Excellent, excellent. Back at the end of last year, I told our team here and I think we said it on our predictive that I thought IAM was going to be the battleground, the most important thing for us to be focusing on, especially as it relates to cloud native, and security, and stuff like this. Of course, this was before the software supply chain builder management, and the ransomware, and a lot of the stuff that we’ve seen come down.

    But I still believe that IAM is the kind of the soft, white underbelly. It’s where cloud security gets down in a lot of ways, right? You have cloud providers who are investing billions, literally billions of dollars, into their infrastructure and their security, and we count on them to deliver the security to a certain level of that stack. The rest of that stack, through a good chunk of it, is protected by our IAM.

    I mean, I’m not blaming anyone, but just this week, we’ve seen Okta with a problem, and I’m not blaming Okta. Any one of us can be the next Okta, or the next Solar Winds, or the next take your pick. We’re all vulnerable, at some point. But it goes to show you how vulnerable we really are through the IAM stuff.

    Tim, what made you guys kind of go down this path? I mean, obviously with what you do, it was kind of adjacent and it wasn’t out of left field, but what made you say, hey, we need to do this?

    Hinrichs: Yeah, there are a couple of things. You mentioned a whole bunch of things and one in which I want to respond to before I get to your question.

    Shimel: I’m sorry.

    Hinrichs: I think that the recent stuff around Okta was interesting because I think one of the things that should remind all of us of is just this idea that there are two kinds of companies in the world, those that have been compromised and those that don’t know they’ve been compromised, to your point.

    Shimel: Exactly, yeah.

    Hinrichs: And so this thing with Okta just I can highlight this idea that once you sort of understand and sort of internalize this idea that you’re gonna be compromised, the only sort of thing you can do is put defensive in depth in place. And so authentication, proving that you are who you say you are, which single sign-on vendors have done a tremendously good job of, is that first level of defense. But then authorization is that second level where what you want to do is sort of control the amount of damage that is done once one of those user accounts is compromised and that’s the notion of authorization. You limit the amount of permissions that every one of those accounts have.

    And so that’s, to your point, one of the foundational principles of security, that you layer levels of security in place so that when any one of them gets compromised, you have several others to put in place.

    Shimel: Absolutely. We hear the term zero trust getting thrown around and it’s funny, with zero trust, to a lot of people’s idea, I do my single sign on, so now I know Tim is Tim. And now, Tim, here’s the keys to the castle. Have at it. But I think what people miss is with zero trust, is just because Tim is Tim, Tim doesn’t get the keys to the castle. Tim should get just what Tim needs, not what Tim may want. He doesn’t get everything. So if Tim is compromised, I still limited my exposure.

    And, again, to me, that’s really when we start getting into the permutations of zero trust and how we do IAM, it’s so important that we have that. Not everybody’s access is created equal.

    Hinrichs: Right. I totally agree and I think, well, one of the more interesting things that we’ve seen is that part of why I think a lot of folks end up with maybe more permissions than they need is just that these authorization systems today traditionally have been hard to use. Every product, every project, every service on the planet has a unique way of solving authorization.

    So if somebody needs additional permissions for some small period of time and I’m the admin, well, I’ve got to go poke around and figure out how to give them additional permissions and then there’s this back and forth. “Okay, I gave you more permissions. Did that work? No, okay, I’ll give you more permission. Did that work? No.” And at some point, you just say, “Forget it, you’re an admin.”

    [Crosstalk]

    Shimel: You know what? I’ll give you everything.

    Hinrichs: “You’re an admin.” And then what happens is you’re supposed to pull those permissions back a week later, but then you forget because you get busy. And so I think there’s this very real notion of permissions creep where people just have more and more permissions over time. Because everybody’s definitely gonna ask for more permissions when they need them to do their job. Very few people are gonna say, “Oh, you know what? I’ve got too many. I don’t need those, anymore.”

    And so I think one of the things that we do at Styra, by trying to provide a unified solution, a foundational solution for authorization, is help with this. Because we say, look, there’s one collection of tools and technologies you need to learn in order to deal with permissions. If you can apply those to all your 57 different products and services, well, you just are more conversant with being able to give rights correctly and being able to revoke them. And so I think that speaks well to why in part we’re doing what we’re doing at Styra.

    Shimel: Absolutely. So if you don’t mind, Tim, let’s talk a little bit about kind of the business aspect of this new offering. How’s it packaged? How’s it offered? How’s it priced? Is there a free open source version, that kind of thing?

    Hinrichs: Yeah, and maybe I’ll also offer the answer to the question about why did we end up doing this ’cause I didn’t get to that.

    Shimel: Yeah, please.

    Hinrichs: Yeah, so it’s one of these nice things that because we have an active user base in the open source world and because we have active customers on the commercial world, we can just watch what they do all the time and then when we see a pattern emerge where we see the same people having to address the same kinds of authorization problems, then we realize, well, that’s a systemic problem throughout our community and organizations. And so then we can go ahead and put the energy into building a new offering, and that was exactly what happened with this entitlements solution.

    We just saw a number of our open source and commercial customers and users having to solve this problem and using OPA and DAS to do that. And so then we just realized, well, hey, if they’re kind of piece-mealing things together, why don’t we just put forth a real offering around this design specifically to solve this entitlements problem. So that’s how it came about.

    To answer your second question, how’s it packaged, and priced, and all that good stuff. Well, so typically what we do is this is another feature, so to speak, or a solution, or sometimes we call it a use case, for our product, our declarative authorization service. So that declarative authorization service was designed to provide a unified solution to authorization. It helps you with Kubernetes authorization, with microservice authorization service mesh. It helps you with public cloud through terraform, and now entitlements. And so in that sense, it’s yet another feature, so to speak, in the product that exists.

    And so in that sense, if you’re just using DAS, then you can kind of just pick that out of a list and put it in place. DAS is available as a SAS offering so everybody can run it and you can sign up for free, as well, so I definitely suggest if you want to try it out, go log in and do that. We do, for the enterprise version, also offer an on-prem solution. And so if folks want to actually run DAS on prem, it doesn’t have to be on prem. It could be in their private cloud accounts, then they can do that, as well.

    Shimel: Excellent. Once again, proving the old axiom, it’s not a product, it’s a feature, and it’s good when you can have a product, whether people can’t decide, well, it’s a platform, not a product, but you have a product that has multiple features like that that handle this kind of thing.

    Tim, it’s available now? So I assume it’s been beta tested, hardened, gotten the feedback, and it’s ready to rock and roll.

    Hinrichs: Yeah, it’s one of our earlier releases, for sure, but yeah, we definitely want people out there trying it and giving us feedback, for sure.

    Shimel: How do people go sign up and give it a whirl?

    Hinrichs: Yeah, just go to styra.com. There’s a signup link, and then when it drops you into the product, you’ll get to pick from one of several quick starts that help you sort of walk through putting stuff in place, and you can kind of kick the tires.

    Shimel: I love it. Tim, thanks for coming on and telling us about this exciting new feature in the Styra product line. Looking forward to hearing more. I do hope we get to see you at KubeCon in May in Valencia, hopefully, fingers crossed.

    Hinrichs: That would be absolutely fantastic, and thanks. It’s been a pleasure chatting with you, again, Alan.

    Shimel: All right. Say hello to all our friends at Styra. Tim Hinrichs, CTO co-founder at Styra here on TechStrong TV. We’re gonna take a break. We’ll be right back.

  • Cybersecurity 2021: Are You Really Prepared for a Cyberattack?

    Cybersecurity 2021: Are You Really Prepared for a Cyberattack?

    As the majority of businesses are increasingly moving to the online world, employees keep working remotely and more cyberattacks keep happening all over the globe, there is no doubt that embracing DevSecOps should be the new normal for every company. Organizations need to be able to adopt DevSecOps practices and adapt to new and evolving threats in order to protect their data and systems from malicious attacks.

    At Cybersecurity 2021: The New Normal Virtual Summit, taking place March 4 and 5, the brightest minds in the security and IT industry will come together to discuss new security threats, empower DevOps teams with the latest security tools and provide practical tips and guidance to help developers and ops teams make the right security decisions to keep their data secure.

    The two-day virtual event features thought-provoking discussions, networking opportunities and educational sessions focused on:

    • DevSecOps tools and practices
    • The main challenges of security and development teams when it comes to AppSec
    • Identity and Access Management (IAM)
    • Passwordless and the long-term future of identity management
    • Policy-as-Code and how it impacts security
    • How security threats changed with COVID-19 and what to expect in 2021
    • How to manage AppSec
    • How to mitigate API vulnerabilities
    • How to break the silos and advance towards DevSecOps maturity
    • How to expand your security program through low-to-no cost initiatives
    • Time series database for security monitoring
    • Machine identity management
    • Top 10 Hacks From the Past Decade
    • Runtime observability techniques for security and compliance
    • Securing AWS credentials on DevOps machines

    Cybersecurity 2021 features an outstanding lineup of industry leaders, including:

    • Ira Winkler, author and president at Secure Mentem
    • Chenxi Wang, founder and general partner at Rain Capital
    • Ron Gula, president at Gula Tech Adventures
    • Richard Stiennon, founding member of The Analyst Syndicate and chief research analyst at IT-Harvest
    • Joe Levy, CTO at Sophos
    • Rajat Bhargava, founder and CEO at JumpCloud
    • Myla Pilao, head of security research communications for TrendLabs at Trend Micro
    • Upasna Gupta, senior product marketing manager for Prisma Cloud at Palo Alto Networks
    • Julian Waits, general manager of cyber business unit and public sector at Devo
    • Joseph Feiman, chief strategy officer at WhiteHat Security
    • Ian Murphy, founder and CEO at CyberOff
    • Mike Jones, security researcher at H4unt3d Hacker Podcast
    • Rhys Arkins, director of product management at WhiteSource
    • TJ Jermoluk, co-founder and CEO at Beyond Identity
    • Jim Ducharme, general manager of the anti-fraud business unit at RSA

    Attendees will have the chance to enter a raffle for a chance to win a free copy of “You can Stop Stupid” by Ira Winkler and another one for a free copy of “Security Yearbook 2020” by Richard Stiennon. There will be valuable resources available for download and attendees will be able to interact with sponsors to learn more about their security tools and services.

    To see the full agenda and to register, please visit the Cybersecurity 2021 website.

  • Cloud Misconfigurations Threaten Cloud Migration

    Cloud Misconfigurations Threaten Cloud Migration

    If we’ve learned one thing during the COVID-19 pandemic, it’s that digital-native business models are essential to survival. That means cloud adoption is more important than ever before. Research shows that the public cloud market is expected to grow to $308.5 billion in 2021, an increase of 16% from 2020.

    But while the cloud holds incredible potential, we have an outstanding security issue to address. That issue is cloud misconfigurations. Through 2025, 99% of cloud security failures will be the responsibility of the customer, quantifying the need for security professionals to turn their attention to security hygiene issues like cloud misconfigurations.

    Digging Into the Cloud Misconfiguration Problem

    To get to the root of the problem, we must fully understand the risk of cloud misconfigurations and how they differ from more traditional vulnerabilities. While traditional vulnerabilities can be patched, cloud misconfigurations can create vulnerabilities in otherwise secure applications and infrastructure. Imagine cloud infrastructure like a highway system and cloud misconfigurations as road hazards. They can be incredibly dangerous and lead to accidents.

    As a specific example of cloud misconfigurations, let’s look at identity and access management (IAM). Poorly configured IAM, such as misconfigured roles or a lack of multi-factor authentication (MFA), can lead to compromised administrative accounts. If a threat actor hijacks a legitimate administrator account, they potentially can take full control of an entire cloud environment. Because IAM sits above the cloud infrastructure layer and all workloads and data within, once it is exploited a threat actor will often be able to circumvent your other security barriers, such as network segmentation, leaving you defenseless.

    Cloud Misconfigurations Can Easily Scale

    Where misconfiguration risk dramatically increases is through the adoption of cloud-native applications and practices like infrastructure as code (IaC) templates used by DevOps teams. These templates offer teams greater speed and scale for building and managing applications, but the downside is that misconfigurations can be unknowingly replicated from development environments to production environments (where sensitive data is stored) at greater velocity.

    In short, the biggest risk to organizations right now is scaling these misconfigurations through the cloud. As the cloud grows in adoption and scale, we’re witnessing these misconfigurations scale right alongside it. Where before, a misconfiguration might have been limited to a siloed application or environment, today, that same misconfiguration can impact the entire organization without checks in place to catch it. Worse, many cloud storage buckets have logging disabled, meaning once threat actors are able to identify a misconfiguration and access an internal cloud bucket, an organization won’t even be able to see what data was accessed.

    Understanding the Shared Responsibility Model

    This all points to a higher-level, hygiene-related issue to keep in mind when securing cloud environments: responsibility. Particularly, organizations struggle to understand the shared responsibility model and how it applies within their own organizations. While some may fail to delineate between cloud provider responsibilities and their own, the major issue at stake is the shared responsibility between various internal teams that often goes undiscussed and undocumented until there is a security event.

    When thinking about software-as-a-service (SaaS), to a much lesser degree the responsibility falls on consumers. However, when considering infrastructure- and platform-as-a-service (IaaS/PaaS) and all the moving parts such as network, user credentials, resource configurations, workloads, identity configurations and more, cloud consumers become responsible for much more. A key consideration to note is that one can never outsource accountability, no matter which cloud model is used. To put this more simply, if one puts data in any cloud provider, they are still accountable for that data.

    Enabling a Holistic Cloud Security Strategy

    When advising security and business leaders on how they can better secure their cloud environments and applications, I highlight what my team calls “The Big Cloud 5,” a set of recommendations developed to help organizations adopt a holistic cloud security model that accounts for proper security hygiene and shared responsibility.

    • Gain awareness and deep cloud visibility
      The very first step to ensuring cloud security is understanding how teams are using cloud technologies, leveraging shadow IT and cloud provider APIs. This allows you to get situational awareness and make informed decisions today as well as in the future. This is not a one-time event, but something you’ll need to do continuously.
    • Set guardrails to automatically prevent the most serious cloud misconfigurations
      Drawing lines in the sand around the most offensive (and potentially destructive) misconfigurations that should never exist in an environment is key to automating protection in the cloud. This will help keep templates and practices controlled, so that poor hygiene doesn’t inadvertently take root and spread. Think of this as your “dirty dozen.” What configurations should never exist in your cloud environments?
    • Standards are the precursor to automation
      One can’t automate what hasn’t been standardized, and while there aren’t widely accepted security standards yet, key stakeholders in an organization must be in agreement about how to secure cloud infrastructures.
    • Train and hire security engineers who code
      To fully leverage APIs, security teams must have engineers who know how to code and automate security processes. An assessment of skills that exist across your security team (e.g., knowledge of coding in the likes of Python or Ruby) can point to areas in training and hiring that need further investment.
    • Embed security in the development pipeline
      Map out who, what, when, where and how your organization pushes code into the cloud. Once mapped, identify the least disruptive insertion points for security processes and tools, so that they can exist in as much of the development pipeline as possible.

    If you feel your organization is a step behind on proper cloud security hygiene, know that you’re not alone. Earlier in 2021, the Cybersecurity and Infrastructure Security Agency (CISA) released a report highlighting the importance of strengthening security configurations based on the uptick in successful cloud attacks, often attributed to poor hygiene and the mixed use of computing devices in the remote work environment. While this is a growing problem, it is also a reversible trend. Best practices, cyber hygiene and a shared responsibility model can help companies safely and securely migrate to the cloud.

  • I am, I am!

    I am, I am!

  • The Best IAM Practices for DevOps

    The Best IAM Practices for DevOps

    Through identity and access management (IAM), it is possible to assign policies that determine whether a user and the role can access particular services or not. An IAM system is also supposed to maintain the principle of least privilege (POLP), which grants the roles and users the permission to access certain resources. As a business focuses on ensuring the IAM is secure, some of the issues that come about include experimenting using new forms of technology, building fast and reducing friction across teams.

    As the scope and number of IAM objects grow, it may be hard to answer questions such as:

    • Are there inline policies?
    • Which policies are assigned to groups?
    • Can another person assume the role of other principles or users?

    As a developer, there are different approaches you can use to ensure the IAM configuration is auditable, tidy and right-sized. Automation plays a key role in this case.

    Below are the best IAM practices for DevOps:

    Use Strong Passwords

    The majority of the users will opt for an easy password. In such an instance, a hacker can easily gain access with minimal effort. Users should create passwords that are highly secure by adhering to the following measures:

    • The password should have 14 characters or more.
    • Include one uppercase alphabet, one special character and non-alphabet characters.
    • Avoid reusing the same password.
    • Don’t use dictionary words.
    • Utilize password-generation tolls.

    Use Third-party Tools to Enhance Security

    For better results, it is advisable to look beyond the service. For example, tools are available that can automate the creation of the IAM policies, making it possible to save a considerable amount of administration time. However, such tools help to eliminate risks while accelerating different management tasks. The administrators should monitor them since they lack flexibility. Update such tools regularly to ensure they are always useful.

    IAM Permissions Review Using Access Levels

    The IAM policies should be reviewed and monitored to ensure efficient security. Such policies grant access to permissions needed to execute certain actions as per particular requirements. Policy summary can help to review policies that issue details regarding access level for specific services. The access levels include read, list, permission management, tagging and write.

    Use Multifactor Authentication

    IAM users should have access to multifactor authentication, which ensures response generation on the user’s device, part of the authentication process. To sign in, the user requires the response generated on the device and the right credentials. If the password is compromised, the account’s resources will be secure because of multifactor authentication.

    The response can be developed in the following manner:

    • A code is generated using U2F keys after tapping on the device.
    • For hardware devices, the response code is generated on the device. You’ll key in the code during the sign-in process.

    Get Rid of Unnecessary Credentials

    A good security practice should audit the user credentials regularly and get rid of the users who are not active. Credential reports help keep track of the access keys and the password’s life cycle. The report includes the date of creation, user details and when a password was last used or changed. If you’re using a password-rotation policy, you’ll receive a reminder that you should change your password. The auditor can download the credential report and perform additional tasks as per the requirements.

    Rotate Credentials Regularly

    Change access keys and passwords regularly for all IAM users and place a password policy in place. Also, IAM users should be enlightened about how frequently they should change the passwords.

    Never Share Your Account Credentials

    Avoid sharing your credentials. If anyone needs to access certain resources, you can create IAM users for them. In such an instance, you can assign permissions to different users.

    Monitor User Activities

    Organizations should monitor the activities of all the users to get a better view of cloud activities. By doing so, it will be possible to find any threats. A cloud access security broker (CASB) can provide cross-cloud visibility meant to monitor user activity and offer threat protection.

    Create a Strategic Plan for IAM

    After compiling identities and mapping the access points, you should decide the permissions to keep and change. Every organization should determine its priorities and liaise with the stakeholders while formulating a strategic plan regarding IAM. Put in place a common decision-making framework.

    Most firms usually start with privileged accounts. Since such accounts belong to the administrators, they are considered high-value targets for hackers.

    An account that has unnecessary access privileges is termed as a security liability. The risks are high if such an account can gain access to sensitive pieces of information. It is always good to determine who has access to the database or different applications.

    Come up with an Agile System

    Companies are dynamic since they do merge and acquire other firms. Departments are also reorganized in some instances, and people are also assigned new roles. The issue arises when you fail to notify the IT department.

    The change is constant; however, security lags since the access updates are limited to a specific time frame. Hackers can take advantage of such loopholes, making companies suffer from a massive data breach, which costs the firm a significant amount of money.

    Consider Unstructured Data

    Although managing access to applications such as emails is important, it is good to consider the information these applications contain. Ensure you assess the information beforehand to determine who can access it. Failure for an organization to keep track of unstructured data makes it hard to decide whether it’s being stored or transmitted securely.

    Some of these apps require social security and credit card numbers. Sending such information through an unencrypted email poses a data breach at some point. It’s, therefore, advisable to keep track of unstructured data.

    Conclusion: IAM Best Practices

    IAM comprises different pieces of the cloud security issue. By adhering to each of the practices above, it is possible to ensure tight security in the DevOps toolchain.

  • ForgeRock Simplifies the Process for Companies to Migrate from Legacy Products to a Modern Identity Solution

    San Francisco – March 11, 2020 – ForgeRock®, the leading provider in digital identity, today announced new tools to help enterprise customers quickly and easily migrate identity and access management (IAM) capabilities from legacy vendors, such as Oracle or CA Technologies, to ForgeRock’s more secure and flexible platform.

    The Modernize IAM Accelerators mitigate the costly and time-consuming process of moving away from legacy systems, helping to make migration seamless and invisible to users.

    “Organizations often delay updating or replacing their legacy identity systems, assuming they must migrate everything at once and cause massive disruption to users and the organization,” said Peter Barker, chief product officer, ForgeRock. “However, the ForgeRock Modernize IAM Accelerators enable organizations to transition to a modern IAM environment at their own pace and avoid interrupting the user experience or causing operational impact.”

    Tackling the Legacy IAM Challenge

    Legacy IAM software slows digital transformation efforts. Siloed and inflexible identity solutions increase security risks and provide suboptimal user experiences while interoperability and scaling issues inflate operating costs. However, legacy IAM software can’t be ripped out and replaced overnight. The risk, expense, and time required to retire these solutions and implement entirely new ones is a significant challenge for most organizations.

    The Modernize IAM Accelerators Solution

    The ForgeRock Modernize IAM Accelerators enable legacy IAM systems to coexist with a modern IAM platform, giving organizations the ability to migrate to ForgeRock without disruption to users. They are a pluggable, open source framework that can support multiple patterns of co-existence with and migration from most legacy IAM systems, by providing Single Sign On (SSO), Just In Time (JIT) User Migration, and Bulk User Migration. Just in Time (JIT) helps organizations save time and effort without sacrificing users’ productivity, particularly when a bulk export of passwords is not possible.

    Included in the Modernize IAM Accelerators are two bidirectional coexistence toolkits supporting SSO & JIT (Core and Edge), and a bulk user migration toolkit. Customers can choose the optimal toolkit (or combination of toolkits) based on their selected migration strategy.

    For all three toolkits, ForgeRock has developed a pluggable framework that can be extended to specific legacy systems with included Plug Ins. Additional Plug Ins can be developed by customers and partners since the assets are open source.

    Depending on an organization’s needs in modernizing IAM, these solutions can help with the success of  digital transformation by reducing time and cost-intensive barriers to success.

    Availability
    ForgeRock Modernize IAM Accelerators are available today. See http://www.forgerock.com/modernize-iam for details.

    About ForgeRock
    ForgeRock®, the leader in digital identity, delivers modern and comprehensive Identity and Access Management solutions for consumers, employees and things to simply and safely access the connected world. Using ForgeRock, more than a thousand global organizations orchestrate, manage, and secure the complete lifecycle of identities from dynamic access controls, governance, APIs, and storing authoritative data – consumable in any cloud or hybrid environment. The company is privately held, and headquartered in San Francisco, California, with offices around the world. For more information and free downloads, visit www.forgerock.com or follow ForgeRock on social media:

    Facebook ForgeRock |Twitter @ForgeRock | LinkedIn ForgeRock |

  • Multi-Cloud Adoption: Time to Rethink Your Identity and Access Management

    Multi-Cloud Adoption: Time to Rethink Your Identity and Access Management

    This may well be the decade that the data center’s reign falls, and multi-clouds prevail. A multi-cloud strategy, which incorporates cloud services from multiple vendors, promises plenty of benefits, including improved resilience and flexibility that makes it easier for enterprises to meet various application and data needs. But, there will also be operational challenges. Expect security, specifically identity and access management (IAM), to be one of them. 

    Gartner states that “by 2025, 80% of enterprises will have shut down their traditional data center, versus 10% today.” Except for a few mission-critical processes that will remain on-premises because they require intense oversight and control, much of an enterprise’s workloads and data will be spread across a multi-cloud environment, with users accessing applications from a range of devices from multiple locations–making it more difficult to secure, control, track and manage access to applications and services. Without a comprehensive IAM plan, an organization could be more vulnerable to attacks and data breaches.

    Instituting the right IAM strategy now, in concert with an evolving multi-cloud architecture, will help protect threats and ensure that the right users have access to the right information when they need it. To get started, we recommend following these key recommendations. 

    Get Your ID Store in Order

    IAM solutions are designed to make sure only people appropriately identified and cleared can access an enterprise’s systems and services. In today’s increasingly complex IT environment, an IAM solution must include an ID store that supports both on-premise systems and cloud services. Unfortunately, too many companies still rely on Microsoft Active Directory as the single source of truth for the IT services they provide. This needs to change.

    As companies begin to adopt multi-cloud architectures, they’ll soon discover that Active Directories are not flexible enough to support IAM, nor can they keep up with the growing number of potential threats. Integrating an identity software product that can manage users’ digital identities, credentials and groupings with Active Directory may work as temporary solution, but as user passwords and access rights are dispersed across on-premise and cloud-based systems, things can get complicated quickly, taxing even the well-resourced IT team.

    If you haven’t already done so, it may be time to extend Active Directory (AD) to Azure Active Directory (Azure AD), Microsoft’s multi-tenant cloud-based directory and identity management service that enables Single Sign-On (SSO) access to on-premise and cloud applications, putting users through an authentication process to prove they are who they say they are. It uses multi-factor authentication, a two-step identity verification system that requires two or more of the following methods: something you know (password), something you have (trusted device) or something you are (biometric screening).

    Embrace Zero Trust

    The premise of zero trust has been around for several years. According to CSO, the first model was defined by John Kindervag (then principal analyst at Forrester Research Inc.) in 2010. The idea is that when it comes to securing enterprise systems and data, no user–internal or external–can be trusted. Security threats are much more sophisticated today and are impacting organizations at greater rates than ever before.

    Malware such as phishing, email phishing and drive-by downloads–which can occur when visiting a website, viewing an e-mail message or by clicking on a deceptive pop-up window–put an organization’s identity and authentication at increased risk. Once an attacker gets a working identity and authentication method, he or she can do almost anything, including system damage, data leaks and destruction, and more. A zero trust network that rethinks approaches to resource access is quickly becoming a necessity.

    Part of the move to zero trust should include a decision to move away from passwords, which are still widely used. Passwords are typically too weak or often re-used, making them vulnerable and difficult to manage. As such, they don’t deliver robust enough security for sensitive systems and confidential information. A passwordless approach eliminates this problem by removing the need for users to remember passwords and for organizations to store them. There are several ways to go passwordless, including adopting biometric authentication such as touch ID and face recognition, and token-based methods such as mobile app authenticators or secured USB keys.

    Control Your Multi-Cloud Strategy

    Of course, distributing an enterprise’s workloads and data across larger numbers of clouds operated by different providers and located in various geographic regions can increase the complexity of IAM. IT staff will have to learn how to manage, provision, control, track and synchronize the systems in each environment, and such a highly distributed operation can easily become an operational challenge. Things can get even more messy, and risky, if an enterprise’s multi-cloud adoption develops in an ad-hoc manner.

    Multi-cloud best practices include working with existing cloud partners, adopting orchestration tools, controlling the risks of shadow IT and keeping the number of cloud environments to a minimum by adding only those clouds that support and elevate an enterprise’s business goals.

    With multi-cloud adoption on the rise, IAM is becoming increasingly important in order to protect against insider and outsider cyber threats and to ensure that the only the appropriate users can access the resources they need, when they need them. 2020 is the year to get identity and authentication right. It’s time to develop a comprehensive IAM strategy that includes an advanced ID store, zero trust and controlled multi-cloud adoption.

    — Richard Diver