In 2014, when I joined the workforce, moving from Eclipse to JetBrains' IntelliJ was world-changing for me. The key reason for moving to JetBrains' IDE was IntelliSense. For decades, JetBrains was the dominant IDE player. However, since I switched to GitHub Copilot, my productivity has improved by 40% (as measured by issue resolution).

Several people have been recommending that I try using Cursor. I was happy in my world, using Github Copilot to autocomplete all mundane boilerplate codes. Although I was reluctant, I went ahead and installed it anyway.

First prompt: Alright, it is like an GPT-embedded IDE. The second prompt has been entered, and it works excellently. In the third and fourth prompts, I noticed something intriguing in my behavior. I did not even want to explore the files it was generating. I felt both physical and mental resistance to exploring the code and editing it manually. This kind of behavior shift toward programming is something I had not experienced before. While IntelliJ's IntelliSense was productive, it did not result in a significant change in behavior. This hit differently. The change did feel like a radical shift. You can argue it is a VS Code clone with prompt executors stitched together, but the complete experience is behavior shifting. It feels powerful, full of serendipity.

The bad vibes

People seem to instinctively kick and abuse humanoids when they see them. I believe that people have a similar instinct when it comes to using AI-generated code. After using Cursor for over a week, I realized that I was not valuing the code generated by the IDE. My second instinct was that I would be hesitant to use it on our core product. My hesitation may stem from the belief that an AI IDE could generate code better than I can; consequently, this fear might act as a barrier, particularly regarding support, operations, and maintenance.

Autocomplete from GitHub Copilot is ok, as it is just boilerplate code, but with Cursor touching multiple files, you often have a tendency to click Accept All because that's the behavior it induces. After generating several projects, I realized that you end up with a project that looks like a 3rd-party product but then you own it, rather than having no ownership. Another key observation was that I was transforming deterministic codes into probabilistic codes. Although the code generated was correct almost all the time, theoretically, changing a variable name transforms a deterministic operation into a probabilistic one.

Giving a cursor to junior engineers is like giving a chainsaw or a road roller to a teenager. If you lack the necessary knowledge to use it effectively or comprehend its side effects and technicalities, you risk causing irreversible damage.

There are specific use cases for AI-native IDEs, back-office software, and internal tools; these are scenarios where the software is considered disposable, business cases are not the primary focus, and we are developing low-ROI tools that do not require architectural discussions or team alignments.

We generated a few projects using the cursor tool.

Superclass

We designed the Superclass project to classify various types of documents, including PDFs, images, and text.

https://github.com/adaptive-scale/superclass

Blacklight

Scan Google Drive, S3 buckets, and local file systems for secrets, tokens, and sensitive information.

https://github.com/adaptive-scale/blacklight

Understanding Compliance as a way of life!

The formal definition of compliance is ‘the act of obeying an order, rule, or request.’ I’m going to come out and say exactly what you’re thinking “Gee, that sounds terrible!” And this is one of the biggest problems with compliance - it has a bad PR problem! The moment someone thinks of compliance, the words that come to mind are; boring, legal, enterprise, risk-averse, costly - don’t think I need to go on.

In fact, I even had a hard time convincing myself that this would be a worthy topic to write about. So what changed? I started looking at compliance through a different lens - not some certification or audit that is necessary for your organization but a safety net that ensures the protection of consumers and employees.

Let’s take a real-world example - one that many of us are familiar with - the FTX and SBF saga! FTX was registered with and licensed by the Commodity Futures Trading Commission (CFTC), an independent U.S. government agency that regulates the U.S. derivatives markets, including futures, options, and swaps. The company was operating mainly out of the Bahamas.

In spite of the CFTC license, FTX, like much of crypto, wasn’t regulated. No compliance, no rules! Without compliance and regulations in place, SBF started engaging in questionable practices, such as using customer funds to invest in Alameda Research, a crypto trading firm co-founded by none other than SBF himeself! This ultimately resulted in retail investors losing billions of dollars.

It is quite obvious that if FTX were operating in a regulated environment, much like any financial services firm, just the complex ownership structure shared by Alameda and FTX would have violated a bunch of compliances. In a regulated environment, there would have been checks and balances on how customer funds could be used, which could have prevented people from losing their hard-earned money.

So if I’d like readers to have one takeaway from this piece - Compliance is not just about licenses and certifications. It's about protecting people from being cheated or losing their money. If you care about your customers and their data, it's time to take compliance seriously.

Consider the following for your next compliance thought exercise: Do you have control over customer data and dollars, and do you care about ensuring that innocent people are not harmed by your mistakes or carelessness? If the answer to both of these questions is YES, it's time to take compliance seriously!

Cost of Compliance and of non-compliance!

If you are still not convinced about taking compliance seriously, it’s best to look at numbers objectively. The financial costs of non-compliance are steep. According to a study on 53 multinational organizations by Ponemon Institute and Globalscape, the findings were really interesting:

• The average cost of compliance is $5.47M, whereas the average cost of non-compliance is $14.82M.

• On average, organizations lose $5.87 Million in revenue due to a single non-compliance event.

• Organizations lose an average of $4 million in revenue due to a single non-compliant event.

So clearly, it is financially a lot more lucrative for organizations to stay compliant rather than stay non-compliant. In addition to the financial costs, non-compliance can also result in damage to an organization's reputation and loss of customer trust, further compounding the negative effects.

Overall, taking compliance seriously is crucial for the long-term success and stability of any organization.

All the right rules in all the right frameworks, so yeah, we’re going down!

Now let’s get to the main section of this article, understanding all different compliance frameworks. It's important to examine these frameworks not just as a list of rules, but as a way to protect certain aspects of your customers, such as their privacy, financial information, and protected health information. If your organization handles any of these customer attributes, you may need to obtain compliance certification. To fully comprehend these frameworks, it's helpful to focus on the customer attributes they are designed to protect, rather than solely on implementation details.

Once you look at different compliance frameworks from this lens, you will immediately know if it’s right for your organization or not - which is always our goal at To Do or Not To Do!

We are going to cover the following frameworks:

• SOC2

• HITRUST

• HIPAA

• SOX

• PCI

SOC2: Keeping private information private

SOC 2 is a set of ‘Standards for Organization Control (SOC) that includes the security, availability, processing integrity, confidentiality, and privacy of a company's systems. SOC 2 reports are designed to provide assurances to customers that a company is maintaining appropriate controls to protect their data and ensure the availability of its services.

Customer Attributes:

The customer attributes protected by SOC 2 are those related to the integrity of the customer's data, as well as their privacy and confidentiality. This could include things like the customer's personal identifiable information (PII) - Name, Date of Birth, Social Security Number (SSN), financial information, and other sensitive data.

HIPAA - So that sick-notes don’t end up on TikTok

The Health Insurance Portability and Accountability Act of 1996, commonly known as HIPAA, is a set of federal laws that establishes national standards for the privacy, security, and transmission of protected health information (PHI). HIPAA compliance is regulated by the Department of Health and Human Services (HHS) and enforced by the Office for Civil Rights (OCR).

Customer Attributes:

HIPAA protects customer attributes related to their medical information, including their personal and demographic information, medical history, diagnostic and treatment information, and other sensitive medical data. HIPAA applies to a wide range of entities, including healthcare providers, health plans, and healthcare clearinghouses, as well as their business associates who handle medical information on their behalf.

PCI DSS - So that card info doesn’t end up on the Dark Web

PCI, or Payment Card Industry (PCI) compliance, refers to the standards set by the Payment Card Industry Security Standards Council for protecting cardholder data. To become PCI compliant, companies must meet the Payment Card Industry Data Security Standard (PCI DSS) requirements for things like network architecture, access controls, encryption, and security assessments. This helps protect against security breaches and data theft and is often required for companies that accept credit card payments.

Customer Attributes:

The customer attributes protected by PCI DSS are those related to payment card information, such as the cardholder's name, account number, expiration date, and security code (CVV). PCI DSS applies to any entity that stores, processes, or transmits payment card information, including merchants, payment processors, and financial institutions

SOX: Keeping organization accounts accountable!

The Sarbanes-Oxley Act (SOX) is a federal law that establishes standards for public company boards, management, and public accounting firms to improve the accuracy and reliability of financial reporting. It was enacted in response to corporate accounting scandals and applied to all publicly traded companies in the US, as well as foreign companies with securities listed on a US stock exchange. It is enforced by the US Securities and Exchange Commission (SEC).

Customer Attributes:

SOX does not specifically protect customer attributes but rather aims to ensure the accuracy and reliability of a company's financial reporting. This can indirectly protect customers by providing them with confidence in the financial information provided by the company and reducing the risk of fraud or other financial misconduct.

HITRUST really deserves some HIPRAISE!

The Health Information Trust Alliance (HITRUST) was founded in 2007 to provide a comprehensive framework for protecting sensitive information and managing compliance. The organization's "HITRUST approach" is particularly helpful for healthcare organizations but can be applied to companies in other sectors as well.

HITRUST certification enables companies to demonstrate their compliance with HIPAA requirements using a standardized framework. By becoming HITRUST certified, vendors and covered entities can show that they have the necessary controls and processes in place to protect sensitive information.

Customer Attributes:

HITRUST is designed to protect any information that can be used to identify an individual or that is considered sensitive or confidential. This can include a wide range of customer attributes, depending on the type of organization and the information it collects and processes. This can include any or all of the following:

• Personal identification information, such as name, date of birth, and social security number

• Health information, such as medical history, treatment plans, and test results

• Financial information, such as payment information and billing records

• Personal preferences, such as communication preferences and language preferences

What does it take to achieve compliance and truly stay compliant?

This is a question dreaded by many organizations because focusing on compliance really does take significant time and resources. While I won’t go into the specifics of each compliance standard, let me provide a framework that can be applied to all of them when it comes to implementation.

The main goal of any compliance framework is to ensure that the business stays compliant at all times. Compliance implementation involves creating systems, processes, and documents that demonstrate the organization's commitment to protecting customers and employees and following industry laws. It's a way to minimize risk.

Now processes and documentation are still relatively well-understood parts of compliance, and while rigorous, they can be figured out with the right resources and knowledge. However, building the right systems for compliance can be tricky for many organizations. This involves putting controls in place to measure and validate security, such as background checks for employees, role-based access control over infrastructure, audit logs, and penetration tests.

There are tools that can help organizations accelerate the compliance process. Companies like Drata, Vanta, and SysDig offer solutions for building the right processes, documentation, and systems to meet various compliance frameworks.

Adaptive's product also helps organizations with infrastructure access and IT compliance. Our privileged infrastructure access management platform audits every query, eliminates credential sprawl, and reduces threat vectors. This not only helps organizations stay secure and continuously compliant, but also reduces a lot of the overhead and work needed for evidence-gathering during audits.

Subscribe now

Compliance isn’t for me - I believe in YOLO!

It really wouldn’t be a To Do or Not To Do piece if we don’t steel-man the other position (thanks @all-in-pod)!

Compliance can often seem like a distraction or a nuisance to organizations. It is only natural for members of any organization to defer or even altogether ignore compliance, at least during the earlier stages. The arguments against compliance tend to sound something like this:

• Nothing’s really happened in spite of us staying non-compliant. So what’s the point?

• Compliance seems like a huge investment of time and resources and is a legit distraction. Let’s worry about this later.

• Would anyone ever find out if we are not compliant?

• Why should I worry about compliance when the org is really small, there is no product-market fit, and there are not many employees or customers?

Now all of the above points are valid. Fundamentally, you wouldn’t want to focus on compliance at the risk of business taking a hit - that makes no sense.

But the counterpoint is any or all of the above thoughts can often lead to a situation where the organization realizes that they need to get compliant quickly, but often it’s already too late - case in point, FTX! While it may be tempting to prioritize other aspects of your organization over compliance, the potential costs and risks of non-compliance far outweigh the time and resources invested in maintaining compliance.

The bad? The ugly? Wait, are we suggesting that SSO could be better and there is more to consider while implementing it? Yessir - the world isn’t perfect (nowhere close!), and there are these small minor things called tradeoffs that need to be considered while making important decisions - especially ones that involve high-stakes infrastructure security impacting every employee in the organization. But worry not; this is why we’re here!

What is SSO? How it works?

I’ll try my best to explain the SSO concept without any jargon.

Single sign-on (SSO) is an authentication method that allows a user to securely sign in to multiple applications and services using just one set of credentials, e.g., username and password. The SSO system is made to work through an identity provider where the user’s identity and credentials are anchored. This identity provider interacts with all applications and services by exchanging trust certificates or tokens containing the identity information needed to authenticate the user. This is how it works:

• When a user tries to log in to any website, the service provider sends a token to the identity provider with some information (mainly the user’s email address) to authenticate the user.

• Suppose the identity provider has already authenticated the user. In that case, a confirmation token will be sent back to the service provider, which contains the user’s identity, and they’ll be logged in.

• If the user is not authenticated, they’ll have to enter their credentials once, and upon validation, the identity provider will send the confirmation token to log the user in.

  

Now, this same log-in workflow can stay consistent for the user across all different applications and services that are tethered to the identity provider.

Evolution of SSO protocols

There are many SSO protocols (heads up - jargons!) - there’s LDAP, there’s SAML, there’s CAS, and then there’s OAuth - I promise we aren’t making these terms up.

They all represent different authentication protocols that have been around since the early 90s! Here’s a timeline of when they were created:

Every authentication protocol has a specific use case and, like everything else in the world, has both pros and cons. In the next section, let's look at all these different protocols and their benefits and tradeoffs:

Lightweight Directory Access Protocol (LDAP)

Even though LDAP is often clubbed into various authentication protocols, it really is a directory and access management protocol that defines how one should talk to a directory server. Most systems use LDAP to talk to a directory, retrieve user accounts, verify them and retrieve attributes associated with them.

Pros: Works well for on-premise authentication.

Cons: Extremely complex to set up and painful to maintain. Users have to set up new accounts for external services.

Security Assertion Markup Language (SAML)

SAML is an XML-based framework for describing and exchanging assertions that applications across security domain boundaries can trust. e.g., a typical assertion from an identity provider (IdP) would convey, “This user is John Doe, with the email address of john.doe@example.com, and was authenticated using a password mechanism.” Depending on its access policies, a service provider (SP) could use this information to grant John Doe web SSO access to local resources. [Spec]

Pros: Ability to control employee access across different services and domains, including external ones.

Cons: Due to the complexity, SAML has been mostly confined to enterprises and academia.

Central Authentication Service (CAS)

Central Authentication Service (CAS) is a single sign-on protocol where the authentication process can only happen on the CAS server. Applications that authenticate with CAS never see the user’s credentials.

Pros: Credentials are less likely to get compromised as applications never see them.

Cons: CAS leaves the authorization to the application itself [ref].

OpenID

OpenID was created to solve SSO for non-enterprise end users. It allowed end users to specify URLs as their identifiers. e.g., An end user claiming http://www.example.com as their identifier would include a link to their IdP in the HEAD section of the HTML document served by http://www.example.com. OpenId was never widely used but led to the evolution of OIDC. [spec]

Pros: The authentication is offloaded to the OpenID provider, and their security systems can be leveraged. Anyone can become an OpenID Provider without requiring third-party registration/approval.

Cons: The support for OpenID extensions is inconsistent from provider to provider. This makes it difficult and cumbersome to implement. Moreover, OpenID’s relying parties can only be web apps.

OAuth

While SAML and OpenID enabled end users (Resource Owners) to SSO for protected resources, there was still no mechanism to authorize applications to directly access users’ resources without the end user's credentials. OAuth enabled this by verifying not only the end user’s authorization to access the resource but also the application's identity that makes the resource request. e.g., applications using Google’s API often rely on OAuth to act on behalf of the end user. [spec]

Pros: Uses API calls extensively, which is why mobile applications, modern web applications, game consoles, and the Internet of Things (IoT) devices find OAuth a better experience for the user

Cons: OAuth leaves out the decision of several specifics to implementors, e.g., token types, vulnerabilities, and interoperability issues. OAuth was not designed as a general end-user authentication service and required proprietary add-ons.

SSO is flawless! No, really, not one issue with it.

Now that we understand all the different protocols let’s look at why SSO as a system has been the best thing since sliced bread (NOT!).

There are a lot of advantages to SSO, and no one denies that, but it does come with a fair share of problems and implementation challenges.

Onboarding so good, we feel like hiring people all the time!
Offboarding so good, we feel like firing people... Oops!

Common Narrative

SSO relieves the pressure on IT help desks while onboarding and off-boarding employees. SSO streamlines the onboarding/off-boarding process by reducing the number of individual access requests from employees. Sure! All of that seems excellent, but you should also know some of the issues that come with it.

What they don’t tell you

When SSO is used to provision users in downstream apps, that process becomes opaque to the organization. This sometimes results in users having residual access to downstream apps despite being removed from the SSO directory.

The SSO mechanism, especially OAuth, relies on access tokens and refresh tokens being exchanged between the identity provider and the service provider. Refresh tokens should ideally have an expiry date on them. But the problem arises when expiry is not configured correctly, and the downstream application has to set a default in that scenario. Often the default value is never set, and hence the token never expires.

Now, if the user is removed from the identity provider but NOT explicitly logged out, they might still be able to access the downstream application. If you want to gauge the scale of this problem, organizations with more than 1,000 employees use 150+ SaaS and infrastructure applications. The higher the number of apps, the more susceptible the organization is to encountering this issue.

So secure! Is this Fort Knox or what!

Common Narrative

SSO reduces the number of attack surfaces because users only log in once every day and only use one set of credentials. If login for each user happens only through a single set of credentials, the organization's security posture improves.

What they don’t tell you

The irony of implementing SSO is that the very thing that makes it secure is also a huge security risk!

SSO is more concerned with providing access than with restricting it. Login credentials are a major focus for external attackers - 61% of data breaches involve credential data.

If a user’s SSO credentials get compromised, the hacker or intruder can access all applications, environments, and services. SSO is usually associated with critical resources so the resulting damage will be pretty bad for an organization.

IT teams are just loving resource management through SSO!

Common Narrative

SSO provides a unified way to manage all your apps and services through one dashboard. It provides IT teams with an easy way to keep track of all different employees and the apps and services they have access to.

What they don’t tell you

SSO introduces a single point of failure in the organization. If, for some reason, the SSO service goes down due to the identity provider going offline, users lose access to all apps, app servers, and services. It goes without saying that this situation will be highly disruptive to any organization.

The roadmap for implementing SSO is long. The process to configure each app with an identity provider consists of many-many steps and can take weeks, if not months, per application.

Moreover, SSO cannot be applied everywhere – it is mainly used with web, mobile, and desktop applications. However, SSO does not support infrastructure resources like VMs, Kubernetes clusters, and databases.

SSO is brilliant for access management!

Common Narrative

With the move to the cloud, employees are using more and more apps in the workplace. Requiring separate usernames and passwords for each app is a huge burden for employees and, frankly, is unrealistic. Signing in once saves time, thus improving employee productivity. Since 68% of employees switch between ten apps every hour, eliminating multiple logins can save a company significant time and money. Single sign-on reduces that cognitive burden, not just for employees but also for IT teams.

What they don’t tell you

The principle of least privilege required for various compliance measures commands users to have minimum access to data, applications, and systems required to do their job. If they need elevated access, it should be done through separate credentials. Both these things cannot be achieved easily in SSO as the setup entails giving access with a single authentication.

Moreover, SSO might be good for authentication but doesn’t work for authorization. Enterprise systems like SAML leave the authorization to the individual apps and services. So much of the groundwork is needed to assign the correct privileges to each employee, which still happens in the downstream resource.

Make SSO great again!

The ideal way to set up SSO is to use it with an access control plane, especially for critical resources. This setup solves some of the significant shortcomings that are mentioned above. Let’s look at them one by one:

Wider reach

An access control plane can help enable SSO for infrastructure resources that wouldn’t be possible otherwise, e.g., databases, VMs, and Kubernetes clusters.

Security & Auditability

An access plane can help improve the security posture. Since the access plan contains multiple access proxies in a federated setup, no single-point attack vector can bring down the resources.

Additionally, an access plane enables auditability into the resources. This helps organizations detect any attacks from internal or external sources.

Authorization & Permissioning

An access plane can help automate authorization and assigning roles while onboarding and offboarding people. Moreover, the access plan keeps checking for residual access and ensures users are correctly deprovisioned from downstream apps and services.

Efficient Implementation

Lastly, having an access plane streamlines the SSO implementation. Since the access control abstracts the downstream resources, the service configuration has a minimal footprint.

There’s no denying that SSO is a critical technology and is here to stay. Every organization, at some point in its journey, would need to implement SSO. However, what’s important is to understand all the different challenges and nuances while implementing SSO so that you can solve all its limitations.

In our next column of the ‘To Do or Not To Do’ series, we look to understand whether organizations should implement and trust Zero Trust architecture? Zero Trust is one of the most widely used security concepts, yet ironically, one of the least understood ones. Hopefully, through this column, you will have a good understanding of the Zero Trust concept, why it was created, what it takes to implement Zero Trust, and whether it’s right for you.

The current state of cyber attack

Cloud adoption has lowered the barrier to building new software. On the flip side, it has given rise to new attack vectors that hackers can use to exploit infrastructure vulnerabilities. This is a story best told in numbers:

• Globally, 30,000 websites are hacked daily

• 64% of companies worldwide have experienced at least one form of a cyber attack

• There were 22 billion breached records in 2021

• In 2021, ransomware cases grew by 92.7%

• Every 39 seconds, there is a new attack somewhere on the web.

Traditional security practices aren’t sufficient anymore, and the world is realizing we need more sophisticated mechanisms to prevent cyber attacks.

Enter Zero-Trust

Coming from the world of traditional security, we're all too familiar with the concept of perimeter-based security. You can access specific resources when connected to a corporate LAN, and you've been verified as trusted. The problem is that this type of security model relies on trust—and while it's great for keeping people in, it's not so great for keeping them out.

But what if the default security posture of an organization was NOT to trust anyone? Enter zero trust architecture (ZTA). The main concept behind zero trust is "never trust, always verify.” This means that no device and no user is trusted by default, even if they are connected to a permissions network such as a corporate LAN or even if they were previously verified.

The Zero Trust model revolves around three core principles:

Never Trust, Always Verify

Always authenticate and authorize based on all available data points, including user identity, location, device health, service, and anomalies.

Principle of least privileged access

Limit user access with just-in-time and just-enough-access (JIT/JEA).

Always assume breach

Verify end-to-end encryption and use analytics to get visibility, drive threat detection, segment access and improve defenses.

Great, so how do I implement Zero-Trust?

I wanted to do a little research on Zero Trust implementation to see the existing literature out there, and I started questioning if the whole thing is just an SEO term being pushed by big tech. On searching ‘Zero Trust’ on the ever-reliable Google, over 30% of results on page 1 and over 40% of results on page 2 were sponsored websites by large security companies.

The strange thing about Zero Trust is that every company has a different interpretation and implementation of it. So we thought it’s best to look at Zero-Trust from first principles and understand why it was created in the first place.

Subscribe now

The right question: Why was Zero Trust created?

In the early 90s, the internet started gaining adoption, and that unlocked new modes of sharing information across the world. But this came with a new level of risk that couldn’t be eliminated by cryptographic methods, the foundation of our security stack. As more and more information was being shared through the internet, we were forced to rethink our approach to trust.

That's what Stephen Paul Marsh did in his doctoral thesis at the University of Stirling in April 1994, and he coined the word ‘Zero Trust’ to rethink computer security. Marsh's work studied trust as something finite that can be described mathematically—that it transcends human factors such as morality, ethics, lawfulness, justice, and judgment. Marsh proposed a security model where all users, devices, and networks are treated as untrusted and treated with the same level of scrutiny. The core idea of Marsh’s thesis was to “never trust - always verify.”

In 2009, Google implemented a zero-trust architecture referred to as BeyondCorp. It started as an internal Google initiative to enable every employee to work from untrusted networks without the use of a VPN. BeyondCorp shifts access decisions from the network perimeter to individual users and devices, thereby enabling employees to work securely from any location.

In recent years, the rise of cloud computing, remote work adoption, and the increase in mobile devices have made it difficult to maintain a perimeter-based security model. Zero Trust is seen as a response to this new reality, as the traditional security perimeter has become more and more porous. This has been the reason for zero trust gaining popularity in recent years.

Understanding Zero Trust implementation at Bird-App through the lens of Rahul Ligma

Now that we have established why Zero Trust is becoming more and more important for organizations let’s actually try to understand the ‘how’ of it more deeply. Let’s first take a look at all the components that are included in a Zero Trust architecture:

Zero Trust Components

We think the best way to understand Zero Trust implementation is to see how the above components fit into an organization’s infrastructure set-up and how they impact the employees. We chose Bird-App and its most real (NOT!) employee Rahul Ligma for this.

For readers who need a bit more context, here is a little help:

As a part of this section, we’ll dive into the Zero Trust components and map them to Bird-App’s set-up as well as how they impact Rahul.

PS: The below story is a fictional representation and as true as Rahul’s employment

Rahul’s first day at Bird-App!

Rahul’s first day at Bird-app is going fantastic, and he sees the HR and IT Manager for onboarding!

Bird-App maintains its employee directory in Okta for SSO and uses two-factor Authentication (MFA) for access. The company also uses Certn for the background verification of each employee.

• Rahul completes his background verification on Certn, which requires him to provide proof of identity using a government-issued ID. User (Identity, Authentication)

• Rahul receives a managed device with certificates installed to verify device identity and compliance. Device (System of Record)

• After verification is successfully cleared, the IT manager adds Rahul to Okta’s user directory, and he gets a digital identity for authenticating himself inside Bird-App. User (Authentication)

  

Rahul needs infrastructure access to push code!

Bird-App’s infrastructure set-up consists of Kubernetes clusters, VMs, and Databases - all hosted on the cloud. The company’s infrastructure resources are all protected by IAM and Microsegmentation.

Microsegmentation is isolating workloads in a network in order to limit the effect of malicious lateral movement. It is either Agent-based (built into the host), Network-based (SDN, VPN, switches), or Native cloud-provided (Security group, Azure firewall, Google cloud firewalls).

Bird-App has set up a VPN as an access proxy that requires a certificate to access the microsegmentation, and IAM resides in AWS.

The star that Rahul is, he puts on some LoFi music and starts writing code. Now he needs access to staging RDS to test his application before he can create a pull request on GitHub. This is what Rahul’s infrastructure access journey looks like:

• Rahul uses the client certificates installed in his laptop to connect to the network segment via VPN as an access proxy. Network (Microsegmentation)

• Rahul needs to first authenticate himself either via static credentials or SSO using a two-factor authentication system from his company laptop. User (Authentication)

• Once Rahul’s identity are verified, the IAM checks whether Rahul’s device has read-write permissions to the staging DB or not, and accordingly grants access for testing. Device (System of Record), Infrastructure (Least Privilege)

• Once the testing is done, Rahul logs into GitHub via SSO, creates a pull-request and waits for the approval from his team lead for the code to be reviewed and deployed. Application (Authorization)

Rahul is a star, becomes a team lead! In charge of access and compliance now.

Rahul has an exceptional year at Bird-app and becomes a team lead! Rahul has new responsibilities to manage infrastructure access, security and compliance processes at Bird-App.

The company uses Splunk as a Security Information and Event Management platform (SIEM) to observe user behaviour by logging all real time communication between Zero Trust components and actors. In order to ensure compliance:

• Rahul makes sure all customer data is isolated and encrypted at both transit and rest. Data (Encryption)

• Rahul ensures infrastructure audit logs are in place to understand exactly “Who did What” and are being sent to SIEM so that alerts can be built on them. Visibility & Analytics (User behavior)

• Rahul creates explicit policies so that no team member can write to production DB. User needs to obtain special break-glass privileges during an incident in order to override the policy. Infrastructure (Authorization)

Bird-App gets acquired, and Rahul is let go.

Well we all knew from the beginning how this was going to end, so Rahul being let go from the Bird App is hardly a surprise for anyone (except for Rahul maybe).

HR updates their records to indicate Rahul is no longer an employee at Bird-App. Before Rahul is off-boarded, the resources owned by him are transferred to another team lead. Eventually, Rahul is removed from Okta’s user directory.

• Rahul no longer has access to Bird-App’s infrastructure resources. User, Infrastructure

• Rahul returns his laptop to the HR. Device
  

  

  Finally Rahul collects his box of things and exits the premises as seen in the iconic pic below:

Cost of Zero Trust, is it really worth it for your organization?

Now that we understand that Zero Trust improves the security posture of an organization, let’s also take a more pragmatic look to understand if it’s right for you.

A zero-trust policy affects nearly everyone in an organization, so all leaders, managers, and developers need to buy into this approach. Getting an alignment like this, especially at a large organization, takes months, if not years, and that doesn’t even account for the implementation timeline. BeyondCorp, for example, took years to implement at Google.

Even today, there is no off-the-shelf tool/service that can transition you to a zero-trust architecture overnight and do it for all of your network/applications. Moreover, threats on the internet keep evolving, making security an ongoing investment. So committing to a Zero Trust philosophy is not just a one-time process, but a mindset that requires continuous investment in resources, training, implementation, and maintenance.

If your business is young and a breach will have a low impact, you probably don’t need a full-blown zero-trust implementation just as yet. You could just start with a couple of basic good practices like making sure the network's use is always verified, and no-one has more privileges than required.

The need for Zero-Trust in the new world

Organizations have been talking about Zero Trust since the early 2000s, so why is it suddenly getting so popular? Well, the simple answer is that we live in a new world, especially after covid-19. There are a few trends that are being unfolded in real-time:

• Sensitive Geopolitical situation

• The Great Resignation 2021, followed by the market crash of 2022, creates a transient workforce

• Generative AI creates a new identity impersonation problem

Sensitive Geopolitical situation

The world is in an extremely delicate place right now as global tensions are at an all-time high. While physical wars are still being fought today, it is common knowledge that the war of the future is going to be through cyber attacks.

In order to tackle this, private and public companies need to improve their security posture proactively.

The Great Resignation of 2021 followed by the great market crash of 2022 creates a transient workforce

According to the U.S. Bureau of Labor Statistics, over 47 million Americans voluntarily quit their jobs in 2021 — an unprecedented mass exit from the workforce that is now widely being called the Great Resignation. This has been followed by the market crash in 2022, that led to mass layoffs in the tech industry - Twitter, Meta, Stripe, and many more!

Workforce today is more transient than ever, which can lead to ex-employees still having residual infrastructure access if keys and credentials are not actively updated.

Generative AI creates a new identity impersonation problem

We have all seen first hand how far generative AI has come in the last few months. There is very little doubt that the technology is going to be great for the world. However, it also brings a unique set of challenges. With generative AI, bots can finally pass the Turing Test, originally called the imitation game by Alan Turing in 1950. For folks that need a refresher, this is a test of a machine's ability to exhibit intelligent behaviour equivalent to, or indistinguishable from, that of a human. As bots get smarter, there is a risk that they can impersonate employees making organizations more susceptible to intelligent phishing attacks.

This culmination of the above trends leaves no choice for organizations but not to ‘trust’ anyone and always ‘verify’ their identity, aka Zero Trust! The realm of network and application security is changing rapidly, and Zero trust provides a framework to adapt to this changing landscape. Our opinion is that in this new world, implementing Zero Trust is not an ‘if’ but a ‘when’ question. However, the Zero Trust implementation shouldn’t be blindly followed based on whitepapers and guides. Instead, every organization should objectively evaluate its stage, risk, and the vertical they operate in and implement different elements of Zero Trust that are applicable to them.

Thanks for reading To Do or Not To Do!

Subscribe now

Hi everyone, 👋

We are very excited to bring you the ‘To Do or Not To Do’ series. The goal of this series is to explore various nuances and trade-offs that organizations should consider while making security, compliance, infrastructure or DevOps decisions. If you find yourself in a position where you need to take a certain infrastructure decision, it is our hope that this column will provide a framework to think through all the different variables around it.

While there are a lot of great technical blogs out there that focus on implementation, we feel there isn’t enough content on the strategic and business reasons behind engineering decisions.

In our first newsletter, we focus on whether organizations should share infrastructure access with the team members or not. This has become quite a critical question post-covid as companies are still adapting to the remote set-up. Also, a lot of recent high-profile stories like the Twitter whistleblower incident and the Uber & crypto hacks have created an urgency in organizations to really think through their infrastructure access strategies.

Cost of Unsupervised Access

Before we dive deeper into the why/ how of infrastructure access management, it is important to understand what happens when you don’t have a strategy.

Unsupervised access often leads to compromised credentials, which then lead to data breaches. Data breaches in organizations have been increasing at an alarming rate of 15% every year since 2015. In the US alone, the number of data breaches has gone up from just 785 in 2015 to more than 1800 cases in 2021.

And these data breaches are extremely expensive to an organization. An average data breach costs about $4.35M and 19% of the breaches are caused due to compromised credentials - Hence, unsupervised access is extremely dangerous and expensive!

In fact, what happened at Uber recently is a perfect example of a hack caused due to compromised credentials.

Okay, great - unsupervised access is expensive. But why care about this now?

There are a few trends in the tech industry, all gaining momentum at the same time that have forced organizations to start thinking about their infrastructure access strategy.

Trend 1: Covid-19 forces companies to go remote-first

Trend 2: Increased Cloud Adoption

Trend 3: Compliance Requirements becoming more important and moving downstream to early-stage companies

Trend 4: Crypto creates new financial incentives for hackers!

Trend 1: Covid-19 forces companies to go remote-first

In March 2020 Covid struck, and it completely transformed the operating paradigm of the world - not just for people, but also for organizations. Remote work went mainstream in an unnaturally rushed timeline, and the consequence was organizations not getting enough time to think through all the different dimensions and processes in order to adapt to this change sustainably.

Tech companies were the quickest to respond to covid and moved to work-from-home policies. They promoted remote collaboration, virtual setups, and the use of cloud services and quickly embraced the new normal of remote work culture. For example, by mid-2020, Facebook had planned to employ more than 50% of its workforce to work remotely over the next 5 years.

Organizations are forced to reimagine their infrastructure access management policies and processes in this new remote-first world.

Trend 2: Increased Cloud Adoption

Nothing screams validation of cloud adoption like AWS revenues, which went from $3.1 Billion in 2014 to $61.5 Billion in 2021.

Cloud adoption has been a major help for tech-first companies to maintain business continuity as well as growth during covid. While other sectors struggled to stay afloat during the pandemic, the tech-first companies did quite well during the same time. During covid, Amazon went on a hiring spree and onboarded close to 275,000 employees in these 6 months, which is a great validation that cloud adoption really helped maintain business continuity.

A common infrastructure setup that companies used in the pre-covid era was setting up an on-premise server and a perimeter network to restrict access. However, this onset of cloud adoption has changed how infrastructure is set up resulting in the need for new access policies.

Trend 3: Compliance Requirements becoming more important and moving downstream to early-stage companies

Zero Trust has changed the way companies operate and infrastructure access is one of the most critical components that ensure compliance. In the next article, we’ll dive into Zero Trust and why it is an important security measure.

These days, even Seed and Series A stage organizations are forced to adhere to compliance standards like SOC 2, ISO 27001, and HIPAA - especially if they operate in regulated industries. Most organizations scramble to gather evidence while going through compliance audits and also struggle the most with access audit logs. Anytime an employee touches an infrastructure resource such as ubuntu VM on AWS or a managed SQL Server Database on Azure (especially in production environments), there needs to be a log that captures all the queries/commands that were executed as well as the resulting outputs.

In order to stay continuously compliant with various standards, infrastructure access hygiene is crucial!

Trend 4: Crypto creates new financial incentives for hackers!

Crypto has gained a lot of momentum over the past few years (for better or for worse) - and that has changed the financial incentives for hackers. Crypto rails have allowed for funds to be transferred in a way where it becomes extremely challenging to track the sender or the receiver.

On May 7 2021, an oil pipeline company Colonial Pipeline which provides roughly 45% of East Coast’s fuels (gasoline, diesel, home heating oil, jet fuel, and military supplies) got hacked by ransomware. Colonial had to cease operations temporarily and decided to proactively take certain systems offline to contain the threat. Within hours of the attack, Colonial also paid 75 Bitcoin (worth roughly $4.4 million at the time) — to DarkSide, the Russia-based cybercriminal group responsible for the attack. Colonial was finally able to resume operations 6 days later but during that time, the shutdown plus the panic resulted in fuel shortages in several areas.

Historically, a hack or a compromise in an organization’s IT infrastructure would most likely result in the hacker releasing some confidential information or documents to the public. But now, hackers often blackmail organizations with the same confidential information, and in exchange ask for funds to be transferred via a chain that cannot be traced easily (Finally a use case @Zach Weinberg!)

Now what is worse is if the victim of a hack is itself a crypto company. In that case, the hacker can drain the tokens directly and convert them into fiat. Case in point: Crypto.com, Qubit, Bored Apes, Wormhole, Cashio, Beanstalk, Fei Protocol - should I keep going?

OK! So, how do we figure out the best access management strategy?

So now that we’ve established how important having an infrastructure access strategy really is, how do companies currently do this? Especially w.r.t. production environments, where the cost of a breach is way more expensive?

At the end of the day, any organization’s security implementation is a tradeoff between:

1. Locking everything down and making it really hard to use which is expensive to implement and maintain

2. Moving fast with minimal restrictions, key sharing, etc. but it’s really prone to security incidents

However, there are a few more nuances to the above philosophies that are important to consider. We will evaluate and rate different access strategies on the basis of 4 key dimensions:

• Security Posture

• Auditability

• Developer Productivity

• Ease of Set-up & Maintenance

We understand that a lot of people might not agree with our ratings, but the main takeaway here is to be aware of all the different tradeoffs and dimensions we are evaluating. The goal of this newsletter is not about the exact ratings but about understanding all the different tradeoffs and potential risks involved in selecting your organization’s access management strategy.

“We don’t believe in sharing access at all”

The first and perhaps, most inefficient way organizations tackle infrastructure access is, by NOT SHARING ACCESS AT ALL. While one can argue this is a secure practice, the organization’s productivity really suffers as a result of this.

Let’s say there is an incident, and a developer needs access to a production server. Now in order to solve this problem, the dev will first have to get in touch with someone who has access (which might be really difficult in the first place as there are very few people in the org with keys/credentials, given the company’s policy). Once that happens, the person with access might have to somehow start a TeamViewer, or do a screen share to let the developer access the resource through their machine. According to Gartner, the average cost of IT downtime is $5,600 per minute. Now imagine all the time being spent with someone just trying to access the resource and resolve an incident via screen share.

Thus, while this access management strategy offers good security posture and is easy to manage as well, the trade-offs are low developer productivity and lack of auditability.

“We are going to create shared keys and credentials for teams!”

This is an extremely popular access management strategy widely adopted by many organizations. While this partially gets the job done, there are a few different challenges to this approach.

1.) Keeping track of who has access

When an organization has shared accounts, the biggest issue arises due to not having a central platform to keep track of who has access to which resources. So, what do companies do to solve this problem? They use our oldest friend, Excel.

We have seen many organizations use Excel files (Google sheets for more progressive ones) to manage and keep a track of the keys and permissions. Here’s what this actually looks like!

2.) Auditability

Another issue that arises from using shared keys is the lack of auditability for any change done. Since the keys are being used by multiple folks, companies cannot pinpoint exactly “Who did What” when an infrastructure resource was changed. Now imagine someone making a change in production DB (we know this is rare, but it DOES happen!), and the organization does not know who actually made that change. Well, even Twitter suffers from this lack of auditability as highlighted in their recent whistleblower story.

This strategy scores really low on security posture as well as auditability and creates a high risk factor for any organization. The setup for this strategy is easy but maintenance is deceptively cumbersome. Let’s say an employee who has access to the shared keys leaves the organization. Now the organization will have to deprecate the earlier keys, create new ones for all resources and redistribute them with team members who are supposed to have access. This can get extremely painful to manage in a large organization where attrition is common.

“No fear when VPN is here!”

VPN is ubiquitous and almost every organization uses one. Historically, VPN was great when organizations only cared about protecting servers located on-premise.

Modern-day infrastructure, on the other hand, is on-cloud, ephemeral and collaborative - and that is where relying solely on VPN becomes complex and cumbersome. Provisioning all these resources via VPN can be a maintenance challenge.

Second, solely relying on a VPN follows the all-or-nothing principle. This means that when someone is inside the VPN network, they can access ALL the resources. This could be extremely dangerous if a bad actor gets inside the VPN network. This also means that providing infrastructure access to a third-party vendor or a contractor can be painful and slows down the process of granting access.

From an auditability perspective, VPNs provide TCP logs but aren’t able to provide info on individual commands or queries within the resources and hence don’t provide great transparency into user activity.

“Bastion Servers are the best!”

A Bastion Server is a specialized computer used to access an infrastructure resource and helps create a separation between the downstream resource and developers. From a security perspective, a Bastion host is the only node in the network exposed to the public.

The fundamental challenges with Bastion nodes are the same as with shared keys/credentials - Basically, it's hard to know who has access to that server and also there is a lack of auditability.

An additional challenge is when organizations have a larger infrastructure. In that scenario, managing Bastion hosts becomes extremely challenging and you would typically need a separate team just to maintain them. Also, in a very isolated experience, we have seen instances where someone by mistake deleted the Bastion host itself. Now if a Bastion host is deleted, there is an immense amount of groundwork needed to recreate a new host and put the credentials of all the downstream resources again.

“I’m going to use a combination of Bastion, VPN, and shared credentials!”

Now, this is the ground reality in most organizations - they typically use a combination of VPN, Bastion, and some shared credentials. While this dramatically improves the security posture of the organization, it also increases the security budget - as this setup is extremely cumbersome to manage and maintain.

There is a tremendous amount of friction anytime a new resource is added to the company’s infrastructure or even a new employee is to be on-boarded. Also, the lack of auditability still continues to be a challenge and infrastructure access logs are not that easy to create with this approach.

About 15% of organizations using DevOps have a separate team to look after providing infrastructure access, defining processes, and even responding to tickets related to infrastructure issues for the rest of the organization. This strategy clearly provides the best security posture but is also the worst when it comes to setup & maintenance given the number of moving parts.

Conclusion

Below is a summary of all the above organization philosophies and their ratings.

Different strategies work better at different stages of an organization. If you are a fast-moving early-stage company looking for a product-market fit, focus on developer productivity and ease of setup & maintenance. Post product-market fit, improve your security posture, and auditability as the increased visibility will make you more susceptible to hacks and data breaches.

Also, the vertical in which an organization operates plays a huge part in figuring out the access strategy. If you are operating in a highly regulated vertical with sensitive customer information (for eg. FinTech, Healthcare, insurance), ensure a high-security posture and auditability at all times - even when it lowers the dev productivity and/or complicates the setup & maintenance

Every organization is unique, and there are many factors at play. The most critical aspect while selecting a specific access strategy (or not) is to be intentional about the decision. It is extremely risky if an organization keeps granting access randomly on an on-needed basis. When the organization eventually matures and plans to put some structure to the access strategy, a lot of time and resources would be needed to recycle and deactivate old keys & credentials.

The takeaway of this article is for organizations to be deliberate about access even at early stages and be aware of the business reasons, tradeoffs and risks involved in different strategies.