Does your access management hurt your team’s productivity? It does.
How do we know? Let’s look at the data.
The average employee has 191 passwords to keep track managing all those different usernames and passwords is a huge time suck. There’s no denying it: having to constantly remember a jumble of passwords is a productivity killer. A recent study found that the average employee spends over 10 hours in their work year simply inputting passwords. Add to that the time required to reset forgotten passwords, and you’re looking at a serious drag on productivity: the estimated cost of lost productivity per organization averages $5.2 million annually.
But it’s not just the time spent managing passwords that hurts productivity—it’s also the time spent waiting for access to the systems and data your team needs to do their jobs. In fact, 66% of employees say they’ve wasted time at work waiting for someone to give them access to something. And one-third of technical employees of IT professionals say that restrictive access causes daily (31.8%) and weekly (32.3%) interruptions in their work.
These interruptions quickly snowball into missed deadlines and frustrated workers. 52% of development teams have missed deadlines due to a lack of access to the needed resources and infrastructure.
For example, imagine this common scenario: a developer needs to access a Kubernetes cluster to work on an application, but they can’t log in. Their manager, who normally provides access, is on PTO abroad with spotty reception. They have no choice but to send a request up the chain manually and hope for the best, which results in losing hours or even days on a project simply waiting for access to a resource.
If this sounds familiar, your company isn’t alone—in fact, 64% of businesses have experienced financial losses due to access management issues. Missed deadlines and extended projects often result from inefficiencies in access management.
And it’s not just the users who are affected: help desk employees spend nearly 30% of their time resetting passwords. That’s valuable time that could be spent on other tasks.
A record number of data breaches in 2021—1,862 to be exact—cost companies an average of $4.24 million each. According to Verizon, 61% of all company data breaches and hacking incidents result from stolen or compromised passwords, and it’s not hard to see why.
When employees lack seamless access to systems, it not only affects productivity but also company security.
Technical employees need access to do their job well, but they’re not always given that access. To do their jobs, technical teams often find creative ways around the access roadblocks by resorting to methods such as password reuse, shadow IT, sharing credentials, or keeping backdoor access. In other words, when employees can’t get the access they need to do their job, they find ways to get it themselves—even if that means going around company policy.
These workarounds might help the technical team finish their tasks and knock down some Jira tickets in their queue, but it also exposes the company to security risks. A recent study found that 8 out of 10 hacking incidents were due to shared passwords, and even more alarmingly, 53% of employees have admitted to sharing their credentials.
Passwords are proliferating across our digital world and getting stolen in record numbers every year. Consequently, it’s no mystery that over 555 million passwords are accessible on the Dark Web, leading to credential-stuffing attacks that account for a majority of data breaches in recent years.
The bottom line is this: if you want to improve productivity and security, you need to give your technical teams seamless access they need to do their job.
Now that we’ve established that access is key to productivity and security, let’s look at how you can streamline access and get your team back on track.
That’s where Apono comes in.
Apono.io is an innovative identity and access management solution that gives your technical teams the access they need — without sacrificing security.
Apono streamlines access by automating the process of granting and revoking permissions, so you never have to worry about manually managing access again. Our technology discovers and eliminates standing privileges using contextual dynamic access automation that enforce Just-In-Time and Just-Enough Access.
Streamlining access also makes it easier to meet auditing and compliance requirements. With Apono, you can see who has access to what, when they accessed it, and from where.
With Apono, It is now possible to seamlessly and securely manage permissions and comply with regulations while providing a frictionless end-user experience. Plus, Aponointegrates with popular applications like Jira, Slack, and Google Workspace, so you can manage access from one central location.
With Apono.io, you can:
And much more!
It’s simple to use and easy to set up, so you’ll be up and running in no time. Stop wasting time on access issues and start improving productivity—and security—with Apono.io today.
TLDR: Overprivileged access is a natural consequence of manually granting and revoking access to cloud assets and environments. What DevOps teams need are tools to automate the process. Apono automatically discovers cloud resources and their standing privileges, centralizing all cloud access in a single platform so you don’t have to deal with another access ticket ever again.
In the ideal world, you would give access to whoever needs it just for the time they need it, and the “Least Privilege,” (meaning both “Just-in-Time,” and “Just Enough”) access policies would be the norm.
But we don’t live in an ideal world.
Cloud infrastructure is dynamic and constantly changing. Some resources, such as cloud data sets, may include more than one database, each with its own set of access requirements. For example, a user could require read/write rights for one and read-only rights for another.
In theory, you should keep track of all these access rights and revoke and grant them as needed. But in practice, we don’t have the tools to automate cloud access management, which leads us to give more access than we should.
Overprivileged access is when an identity is granted more privileges than the user needs to do their job. In the cloud, this happens all the time.
For example, a developer needs access to an S3 bucket for a couple of hours each Monday in June to do some testing. After they are done, they won’t need that access again until a sprint with a task requiring it comes up.
If you were to go by the book, you would need to manually give them access and then manually revoke it on Mondays for four weeks.
This is simply not sustainable. The ratio between DevOps and engineers is already 1 to 10, and It’s not possible for DevOps engineers to be constantly dropping what they are doing to provision or revoke access. We’ve got other stuff to do.
When a developer needs access to a sensitive S3 bucket that contains customer data, it’s often not clearly defined what permissions will be enough for the user to do their job. We address this problem by providing more access than we should in order to avoid becoming a bottleneck. As a result, the whole role gets over-privileged permissions. What we’re left with, is an Overprivileged Role Level Access that affects a large number of users, and is not likely to ever be revoked.
Another common way overprivileged access creeps into your cloud stack is when “Read/Write” access is granted to users who need only Read rights for a limited time. An overprivileged identity with Write access can do great damage if it’s compromised.
To make matters worse, managing access is kind of dull. Nothing is less exciting than dealing with another access ticket. Managing access is the task you want to get over with as quickly as possible.
Without automation, it’s impossible to implement granular access provisioning, revoke access in a timely manner, or even just keep tabs on existing policies. And that, folks, is how overprivileged access to cloud resources became the norm.
Today, overprivileged access is everywhere. And it’s a serious problem for several reasons:
Overprivileged access is one of the biggest security risks in the cloud. In recent years, the vast majority of breaches (81%) are directly related to passwords that were either stolen or too weak.
But it’s not just about passwords. It’s about the way cloud resources are accessed and used.
Overprivileged access significantly increases the blast radius of an attack. When an attacker obtains a set of valid credentials, the permissions linked to those credentials determine what they can and cannot do in your environment. The more permissions a compromised identity has, the bigger the attack surface.
In the cloud era, permissions are your last line of defense: the right permissions are what prevent unauthorized identities from accessing your company’s sensitive data. Therefore, tailoring access to the task at hand will drastically reduce the risk.
Another issue with overprivileged access is that it makes cloud environments more complex than they need to be. When everyone has full access to everything, it’s very difficult to keep track of what’s going on.
This can make it hard to troubleshoot issues, diagnose problems, and comply with regulations.
The harm that can come from overprivileged access is not coming just from malicious actors. All humans make mistakes, and your employees are human.
According to 2022 Data Breach Investigations Report, human error is to blame for eight out of 10 data breaches. Overprivileged access significantly increases the risk of such mistakes and the resulting fallout.
Traditionally, access management has been the domain of IT security, but as cloud adoption increased, the burden of managing cloud access has fallen upon the shoulders of those responsible for the cloud infrastructure.
More and more DevOps engineers are finding themselves in charge of their organizations’ access management policies.
In today’s public cloud reality, provisioning of access is becoming an ever more important part of DevOps engineers’ day-to-day work. And that’s where the balancing act begins:
Moving to the cloud is a transition towards a more agile way of working, which necessitates a subsequent shift to dynamic permission management.
So what are we to do?
The answer, as with most things in a DevOps engineer’s life, lies in automation. We need to find a way to automate cloud access management so that DevOps engineers can focus on their actual jobs and not spend all their time managing access.
We need a tool that is:
– Easy to use
And that is where Apono comes in.
Apono simplifies cloud access management. Our technology discovers and eliminates standing privileges using contextual dynamic access automation that enforce Just-In-Time and Just Enough Access.
With Apono, It is now possible to seamlessly and securely manage permissions and comply with regulations while providing a frictionless end-user experience.
Are you ready to never have to worry about cloud access provisioning again? Get in touch with us today.
We recently went through the SOC2 process and are happy to report that we successfully passed our audit! Generating a SOC 2 Type 1 Report generally takes up to six months. In our case, the entire process took only 6 weeks, and we wanted to share how we did it.
TLDR: We used Apono’s cloud-native privileged access management solution to streamline our access review process and make SOC2 audit much easier for us (and our auditor)
If you serve customers in regulated industries such as healthcare, finance, or the public sector, you will likely need to obtain SOC2 certification at some point.
For those who don’t know, SOC2 is the gold standard for security certifications. It is becoming increasingly common for SaaS companies to get SOC2 certified to reassure customers that all the necessary controls are in place to protect their data.
SOC2 reports measure a company’s security through the lens of AICPA’s Trust Services Criteria across five major categories:
The SOC2 compliance report is a public attestation that your systems and controls have been assessed by an independent auditing firm and that they meet or exceed the standards for security, availability, processing integrity, confidentiality, and privacy.
The SOC2 certification process is notoriously long and arduous, but we are happy to report that we obtained our SOC2 certification in just six weeks from start to finish.
Apono helped us in two ways:
SOC2 compliance covers a lot of ground and involves solidifying company policies, including access to sensitive resources covering both physical and digital access control.
We are cloud-native, so physical protections around the data centers don’t apply to us. Access to digital resources is another matter. The problem with cloud resources is you don’t hack; you log into it. That’s why access control is such an important part of SOC2.
SOC has several controls for access. Auditors will want to see that you have strong controls around:
To meet these requirements, you’ll need to generate an access review report that includes:
The access review report is one of the most time-consuming and tedious parts of the SOC2 process. It involves manually reviewing Access Control Lists (ACLs) and then comparing them to lists of employees and their job descriptions to see if there are any discrepancies.
Sifting through all of that data is a huge pain, but we were able to generate an access review report in just a few seconds. Apono’s platform automatically and continuously maps out user roles and permissions across all systems and applications. So it was effortless to generate a report that includes all of the information required by SOC2.
Not only did this save us a ton of time, but it also ensured that our access review report was 100% accurate.
Moreover, we could automatically generate an access review report anytime we needed it during the certification process. This was incredibly useful because it meant we could easily re-run the report to reflect any changes in personnel or systems.
This huge time-saver allowed us to focus on other aspects of SOC2 compliance. Going forward, we can easily run the report anytime on demand if there are concerns about potential unauthorized access.
Our auditor was impressed with how quickly we could supply the access information they needed.
It’s not enough to have controls in place – you also need to be able to monitor and audit access on an ongoing basis.
Auditors will want evidence that you’re regularly reviewing and revoking access.
This is important for two reasons:
Auditors will want to access logs to see who did what when they did it, and from where. We could provide them with something better – a live view of access to our production environment that they could monitor in real time.
This gave them visibility into our entire system and allowed them to see exactly who had access to what resources and what they were doing with that access. We were able to give our auditor a real-time view of who was logged in, what they were doing, and from where. This provided valuable insights and evidence that our access controls were working as intended. This was a huge selling point for our auditor.
Overall, Apono was an invaluable tool for streamlining our SOC2 compliance process.
But it’s not just about passing the SOC2 compliance certification in record time (although that is a huge plus!). It’s about handling your cloud access in a way that’s secure, efficient, and scalable for the long haul. So if you’re looking for a platform for managing access control and compliance in the cloud, book a demo with Apono today. We’d be happy to show you how our platform can help you become secure and compliant while maintaining your productivity and agility.
As born-in-the cloud organizations grow, natively managed Identity and Access Management (IAM) tools are becoming a growing concern. Although DevOps teams tend to bear the burden of cloud IAM provisioning, the operational challenges transcend functional silos. Even when SREs and infrastructure teams are closely aligned with security leaders, using native IAM tools to provision access with granular control is unsustainable. No one would contest the need for authorized personnel to get “Just Enough” access whenever they need it – “Just in Time” (aka JIT). Still, teams managing cloud-first deployments struggle to deliver effective access control at scale. While regulatory compliance requirements can act as a trigger for business continuity enablement, many companies are containing unacceptable levels of risk in the form of “cloud IAM debt”. The following list of cloud permissions management traps may sound familiar to DevOps leaders. Avoiding them is trickier than you might think!
Getting cloud IAM provisioning right can only succeed by addressing the manual workflows that currently support multiple teams – namely DevOps, infrastructure, and security. The imperative to remove bottlenecks impacts the business as a whole, but also the success of established functional departments. Once priorities and goals are clearly aligned across departments, the solution is a natural next step.
Earlier this week, IKEA Canada confirmed that an employee had accessed private customer information. Although the official announcement did not provide details, it’s a safe bet to assume that controls related to data governance and regulatory compliance are the primary guardrails that led to the revelation. Unfortunately, this particular case hardly represents an isolated incident.
While data loss is on the list of most concerning threats to DevSecOps success, Identity and Privileged Access Management (IAM & PAM) are at the top.
Regulatory compliance can be an effective guardrail. Still, infrastructure and operations leaders are united on the urgent need to implement a DevSecOps initiative. Regardless of where organizations are on their DevOps journey, a 2021 Cloud Security Alliance survey confirms the tightly coupled relationship between privileged access and DevSecOps success. While data loss is on the list of most concerning threats to DevSecOps success, Identity and Privileged Access Management (IAM & PAM) are at the top. Regardless of the maturity of the DevSecOps journey, the DevOps community clearly faces a mounting challenge.
By IKEA Canada’s own admission, an employee used a “generic internet search” to query personally identifiable information (consumer PII). In other words, an over-privileged user or machine identity queried a shared data asset that included restricted information. To make matters worse, no controls were in place to prevent the privacy breach from recurring over a 72 hour period before security operations teams were alerted.
Effectively answering the following questions will impact every department spanning IT, infrastructure engineers, application developers, and security operations:
The shared high-level goal is to strike the right balance between “Just Enough” privileged access to address security concerns, and “Just in Time” access grants to ensure smooth business operations.
The shared high-level goal is to strike the right balance between “Just Enough” privileged access to address security concerns, and “Just in Time” access grants to ensure smooth business operations. For simplicity, let’s assume the sensitive information was stored in one shared database functioning as a single point of failure enabling unauthorized access to sensitive data. Without an enterprise-wide DevSecOps initiative in place, the engineers charged with developing and maintaining critical systems typically face an impossible choice between bad and worse. By restricting access to data to authorized personnel only, engineers could theoretically prevent illicit access. Unfortunately, using legacy technology to implement such measures would effectively cripple business operations. This tradeoff is familiar to anyone grappling with static role-based access control (RBAC). As DevOps transformation initiatives deepen, enterprises have begun to explore dynamic access workflows that account for requester, approver, asset, and duration. Taking this approach a step further, teams with significant production workloads in the cloud can leverage tagging practices that clearly separate data assets that contain sensitive information (e.g. customer PII).
By supporting dynamically contextualized access to sensitive data, teams can get the job done while eliminating unauthorized parties from ever exposing customer PII in the first place.
DevSecOps can only be successful by addressing the three core elements of security, namely people, culture, and technology. Long-term collaboration between people can create the foundations that build bridges that transcend traditional organizational silos (e.g. application developers working alongside security operations practitioners). It’s up to C-level leadership to embrace the success of isolated initiatives and build out processes that permeate throughout the organization. Finally, disruptive technologies focused on the key challenges (namely cloud IAM and PAM) are critical to empower the workforce to step up and embrace positive change. By supporting dynamically contextualized access to sensitive data, teams can get the job done while eliminating unauthorized parties from ever exposing customer PII in the first place.
Learn how Apono’s approach to cloud-first Privileged Access Management enables DevSecOps Transformation!