Multi-factor authentication is — thankfully — a normal part of our digital experience. Whether at work, connecting with your bank, or logging in to social media, we’re used to the extra step of entering a short code or acknowledging a push notification during login.
In recent years, attackers have grown an arsenal of capabilities — varying from sophisticated to straight-forward — to bypass the security MFA provides. Examples from recent incidents that included MFA bypasses are the SolarWinds breach, which was carried out by Russian state-actors the NOBELIUM APT; the Nvidia and Microsoft breaches, who are believed to be carried out by LAPSUS$ cybercrime gang, and most recently the Uber incident, by a currently unknown attacker. All of these incidents have a common thread: these organizations used MFA but their attackers found a way to bypass it.
The Island Enterprise Browser enables administrators to embed MFA authentication into every web application and on every user flow at will, and enforces strong MFA methods. We will cover the different types of MFA methods, the challenges of using them within enterprise applications, and how the Island Browser brings it all together.
MFA adoption is dependent on application developers, and security teams often have to find creative ways to enforce MFA consistently. This gap becomes even more apparent in legacy applications that are no longer maintained, or that were developed with technologies that make incorporating MFA difficult or impossible. Thus, many critical applications that we use do not, or cannot, adhere to the security standards we all wish to see.
Implementing MFA eventually sums up to better security at the stage of authentication to the application. Once an attacker has already obtained an authenticated session (through session hijacking, for example), they can do anything they wish in the application. In fact, relying on authenticated sessions is one of the most common ways attackers bypass MFA altogether.
With the ability to embed MFA everywhere, Island allows administrators to build a secured workflow for their users within any application, and protect the most sensitive actions they perform within the browser. For example, with Island, an administrator can choose to prompt for MFA when the user decides to edit a sensitive financial file, or add an MFA prompt to a legacy application that doesn’t support MFA natively.
Rolling out MFA in the organization is not a silver bullet — security teams must be conscious of which MFA methods they use and weigh the risks of each. In the following sections, we will review some of the most common MFA methods and the risks associated with them.
One of the most common MFA methods is SMS-based MFA. Once a user enters their password, a temporary code is sent to the user by SMS, which they input in order to complete the authentication. But according to research from CISA, Microsoft, Okta, and others, it’s also one of the weakest.
SMS-based MFA hinges on the ownership of the phone number tied to the account, and not on ownership of the mobile device itself. Except for phishing and malware, SIM swapping is one of the most common attack vectors on SMS-based MFA — an attack in which the attackers take over the victim’s phone number.
One common method of executing such an attack is using social engineering to impersonate their victim, claim to have lost their device, and convince the mobile carrier to move the number to a new device. In a recent example, an attacker pleaded guilty to stealing some $50 million USD in Bitcoin from a wallet after a successful SIM swapping attack, which allowed him to gain access to the victim’s email and then their cryptocoin wallet.
Another common MFA method is time-based one-time password, or TOTP. In TOTP, a shared-secret is set up between an application (usually on a mobile phone) and a web application, usually by scanning a seed provided in a QR-code. After the shared secret is created, the application generates short-lived codes derived from the secret and the creation time of the secret, making the generation of new codes by a malicious actor extremely difficult.
TOTP is a strong MFA method, but it is not bulletproof. A phishing website that simulates the authentication process with the destination website can intercept the password TOTP code. This allows an attacker to create an authenticated session with the real website on behalf of their victim. Alternatively, malware on the device can steal the TOTP shared secret, and generate a valid code on demand.
Recently, a sophisticated campaign targeted organizations by creating phishing websites mimicking their SSO authentication pages, and intercepting the victims TOTP codes to create valid sessions.
Push-notification based MFA gives a great user experience: a user simply has to click a notification from an MFA app to approve an MFA challenge. Since the challenge is given and completed in a trusted application on one of the user's devices, app-based push notification is considered one of the strongest MFA methods.
However, most applications do not require the user to prove they are physically present near the device used to access the account (by asking the user to input a code shown on the screen, for example). Attackers can flood users with push notifications until a user approves it out of habit. Also, a malware can steal the push notification client key or read the notifications directly. Such attacks allowed both sophisticated state-sponsored APTs as well as cybercrime gangs to bypass MFA of users from very large enterprises.
In recent years, using biometric authentication (such as fingerprint and facial recognition) for web applications has been on the rise, with steady adoptions on physical devices and operating systems from vendors such as Apple and Microsoft. Biometric authentication is just one type of authentication that has been made possible by the FIDO2 (Fast Identity Online) project, and the WebAuthn standard. WebAuthn allows the use of a private key stored in a device — a laptop, a mobile phone, or a security key, that upholds certain hardware and software security standards — to authenticate to a web application while verifying its identity.
WebAuthn-based MFA is considered the safest MFA method these days, as it relies on a private-public authentication mechanism and has a verification of the destination website during the authentication process. This can prevent most phishing scenarios, like those described above. If possible, always use a WebAuthn based authentication.
Besides directly attempting to bypass MFA, an attacker can aim for getting the end result of such bypass directly: a valid session token or cookies of the victim. There are some possible ways to achieve that and they all revolve around attacking the browser. Some examples:
An attacker who has access to the endpoint, or the browser, can (assuming they have user privileges) retrieve the cookies stored in all common browsers — both Chromium based (such as Chrome and Edge) and others (such as Firefox). The cookies are stored encrypted on the endpoint. However, since the encryption mechanisms are known and the keys are accessible to the user, malware can also access the cookies and decrypt them.
In a recent example, the LAPSUS$ cybercrime gang has claimed to have breached EA by buying an active session token of an employee to the company’s Slack. This token was most likely obtained from malware installed on an employee’s devices from which they used to login to the corporate Slack.
SSL is almost ubiquitous in the modern world and keeps our online activities both secure and private. However, Main-in-the-Middle (MITM) attacks are still a possibility. For example, malware installed on the endpoint can add the attacker’s trusted certificate, allowing them to decrypt SSL traffic. By achieving visibility to the unencrypted traffic between the victim and the service, attackers can steal all of the tokens and cookies sent in it.
The Island Enterprise Browser empowers organizations by allowing them to use MFA everywhere. Some of the most common scenarios include:
In addition to making MFA another tool in the administrators tool shed, Island also protects against endpoint and network attacks, like the ones mentioned above. This is done through various methods of local and cloud-based encryption of sensitive browsing data and network integrity checks and verifications. By combining the power of MFA everywhere with strong MFA methods, last-mile controls and enterprise-grade protections, Island protects the enterprise, while empowering the end user.
Dennis Pike is working with a large American law firm to improve their document management and information security practices. Whenever the firm is engaged in a legal matter with a client, they use a digital “deal room” to collect and share documents between the legal staff. The information in these documents is often highly sensitive so access control and confidentiality are critical.
One of the unique challenges for this law firm is managing documents across multiple deal rooms or file share services. It’s common for a client to use their own file storage service in addition to the law firm deal room. It’s essential to make sure documents are correctly stored between the two sources and that the right people have access. Using the Island Enterprise Brower helps the firm achieve both, without adding any unnecessary burden on their staff.
Working with Dennis, the law firm deployed the Enterprise Browser and require its use when staff are using an external client deal room. The additional visibility and access controls gives their risk & compliance team confidence in how deal room documents are managed. It’s also opened the door for employees to have more flexibility with the productivity tools they use at work. The Enterprise Browser gave the law firm the confidence to “say yes” to a wide range of web apps that help their legal staff increase productivity.
Brian Borthwell is working with a company that offers customer support services for some of the world’s largest brands. This company has employees all over the world who fulfill critical roles like content moderation on forums, social media engagement, and customer support. This type of work requires interacting with sensitive customer and company data, so information security is critical to their business.
One of the unique challenges they wanted to solve was replacing a legacy virtualized desktop platform. They used a non-persistent VDI so employees could log-in during their shift, complete their daily task list, then clear all data after their shift. This was a clumsy experience for employees, who would need to spend the first few minutes of each shift logging in and configuring their workspace. It was especially painful for employees on a slower connection.
Working with Brian, they implemented the Island Enterprise Browser as the secure workspace for employees. Daily work assignments are stored and accessed through Island Secure Storage and data is deleted after each shift. Making the change from VDI to Island was a big improvement for employee user experience and boosted productivity by eliminating virtualization friction. It also cleared the path to decommission the old VDI platform to reduce costs and simplify their IT operations.
Island has been fortunate in so many respects, especially at this early stage of our life as a company. To us, that good fortune isn’t just a positive outcome of our past efforts, but a responsibility for the future. To take some of that success, and turn it outwards by improving the communities and the world around us.
In that light, we’ve made certain commitments regarding our carbon footprint.
We’re still a small organization - so our impact at this stage may not be gigantic. But we feel every step in the right direction is an important one. It’s a way for us to use whatever resources we have to better the world around us - no matter how big or small.
Our first initiative is to commit to making our products carbon neutral. To do that, we are partnering with a carbon offset provider as well as contributing to key emission-reduction projects.
And we’re happy to be able to say that, as of right now, we’ve already offset our carbon emissions for the year!
Here are the initiatives we are participating in to make these offsets possible:
But it goes further than our product itself. Island also offsets the heavy footprint coming from the hardware and compute-intensive products and services we displace such as desktop virtualization and traffic backhauling technologies. A difference that amounts to something quite significant. This is good for Island, good for businesses everywhere, and great for society as a whole.
This small but significant step is exciting - but it’s just the starting point. From here, we’ll actively seek other ways we can make things better for the people and the world around us.
Jason Trunk is working with a FinTech Lending company who wants to improve their call center operations. They have several call centers around the world to serve customers on loan origination and servicing and they use Salesforce.com for all their customer service operations. In the business of financial lending, a simple human error could be very costly both for the company and their customers, so it’s critical to track exactly what each employee is doing to catch errors and audit their operations.
Previously, this customer was using a combination of several tools to secure access and provide visibility. One of these tools was Salesforce Shield, an add-on module for Salesforce.com that offers granular logging but adds 30% to their subscription costs. They also required employees to login to Salesforce via a VPN, which degraded the user experience for some employees outside the U.S.
Working with Jason, they configured the Island Enterprise Browser as the default browser for all call center employees. This gave them dramatically improved visibility to all activities through the browser, including Salesforce.com. They were also able to retire the VPN solution, as Island offered a secure and trusted platform to connect through. With this change, the day-to-day user experience for call center employees improved and the company got better visibility and a simpler technology stack.
There’s no playbook for building a whole new category.
It’s not because nobody knows how to do it. It’s because arguably the most important step of category creation is not in your control.
Gaining the recognition and endorsement from the voices that matter most in your industry sends your market an unmistakable message – that a true innovation has arrived and the game has officially changed.
This is why we are so grateful to have Dmitri Alperovitch not just support Island’s mission, but to personally join us as an investor in that mission to help us continue making it a reality.
Dmitri Alperovitch is one of the most accomplished experts in the world of cyber security.
Formerly the Vice president of threat research at McAfee, Dmitri is perhaps best known for having co-founded and served as CTO of Crowdstrike.
Today, Dmitri focuses his time and energy on his three passions – The future of cybersecurity, the teams building it and his philanthropic work.
As he considers cybersecurity investments, Dmitri says there’s just not a lot out there that wows him these days. As an industry, cybersecurity is about as saturated as possible in both innovation and the funding behind it. So something truly new is hard to find.
And that’s why Dmitri’s belief in Island feels significant. It signals that we’ve arrived at something truly groundbreaking.
When it comes to his second passion, the people, Dmitri saw in Island an executive team with a history of success he was quite familiar with. With many of Island’s leaders having worked closely with him in the past, it wasn’t difficult for Dmitri to envision Island bringing this new technology and category to life.
Yet, what was maybe most meaningful of all was hearing our story come from Dmitri’s mouth.
How CISOs want more security but fewer security tools and agents.
How the solutions we’ve relied on until now have become the very targets of attack that put companies at greater risk.
How no one considered enabling the browser to do more than just browse.
How The Enterprise Browser isn’t just about security. It’s about efficiency and productivity – areas that appeal to CIOs just as much as CISOs.
How so very simple the whole thing is.
When one of the industry’s most accomplished and respected leaders shares our vision, believes in our mission, and invests in our future - that’s some of the best validation any new category can get.
They say you can only grow once you know that you don’t know.
When you start something entirely new, there are always a fair amount of unknowns. Lessons you only learn once you’re already out there marketing, selling, and delivering for customers.
For us, our “something new” wasn’t just a product. It was a whole new approach. A category that never existed.
Which meant what we didn’t know was a whole lot. So we spent a lot of time listening. listening.
We pitched what our product can do for organizations and then listened to what customers needed for their organization. And then we built something that (we hoped) would be transformative for them.
We showcased features, and then learned what additional features mattered to them most. Some of those became new features we added later that week, or in some cases, that day.
We listed relevant use cases, then found out there were four more we never even thought of. And optimized for those as well.
And this kept happening week after week. Call after call. Until we realized, this wasn’t just about our product. These were valuable lessons for our industry. Anyone can learn from these conversations, to understand what security teams, end users, organizations as a whole are struggling with, and how we can help.
And from that, “What we learned Wednesdays” was born. A weekly video series where our sales professionals share unique customer stories and what we learned from them. Each conversation consists of three parts:
To start things off, here is our first video in the series: The case of the HITRUST Certification - a set of important risk management and compliance requirements that are critical to customers in the healthcare market.
What we know
Eugene Kim is working with a health care customer who needed to set up a secure environment to access patient records. They considered the virtual desktop approach, but found the cost and complexity was too high. Instead, this customer chose the Island Enterprise Browser as the secure access point for all apps and resources. This solved their challenge for onboarding new employees and didn’t add any of the complexity of desktop virtualization.
What we learned
One of the requirements this customer brought to Eugene was the ability to support HITRUST certification. Working with extremely sensitive patient records is central to clinician workflows and protecting those records is critical. In practice, this means adding tight controls over how patient records can be accessed and where they are stored.
What happened next
Working with Eugene, they configured the Enterprise Browser to freeze a user session after a period of inactivity. Once the clinician re-authenticates with their secure credentials, they can pick up exactly where they left off. If a user is inactive for a longer period, the session ends and the browser clears all open tabs and browsing data. To prevent any data leakage, they also enabled several controls to prevent patient data from leaving the browser. In this way, they can treat the browser itself as the managed endpoint regardless of which device it’s running on. Island provides all the security controls they require with a much simpler deployment model.
So it’s official. The Enterprise Browser was named The Best Enterprise Security Solution by SC Magazine.
And while this is certainly a time for us to take it all in, celebrate the win, and be proud of our accomplishment - this is more importantly a time to reflect on how we got here.
Think about it for a moment - the best enterprise security solution of 2022 is a browser.
Imagine telling your industry peers five years ago that, in 2022, a browser will be the most important security solution for the enterprise. Imagine saying that even nine months ago!
And yet, here we are.
In some ways, it’s pretty shocking, and yet, if you dig a bit deeper (like we did), this outcome seems kind of inevitable.
The world of work was slowly moving to the web. SaaS was gaining momentum fast. Companies started moving critical apps to the cloud. Then moving their entire organization to the cloud. Then companies were being born in the cloud.
And then COVID happened. Work was no longer just in an office, on the corporate network, using company devices. It was everywhere.
Suddenly the browser wasn’t just another work application. It was the center of our digital workspace. It became, quite literally, the most important application in the enterprise.
And yet, the browser, where pretty much all work took place, wasn’t even designed for work. No way to secure sensitive data. Now way to govern access. No way to control or even see what’s happening in there.
Which forced organizations to do some pretty uncomfortable things just to work safely on a browser that was never meant for work.
All this led two industry veterans, Mike Fey and Dan Amiga, to arrive at a entirely new thought:
What if the browser was designed for the enterprise?
What if everything the enterprise needed to work safely was built into the browser, instead of on top of it?
And like that, The Enterprise Browser was born.
The ideal workplace, where everything the enterprise needs is built right in, and everything else is out of the way.
Organizations now control, see, and govern everything happening in the browser. While users get the smooth browsing experience they know and love. Everyone wins.
It was the answer to the high cost, huge complexity, and heavy resources that have gone into securing the enterprise until now.
And the answer to the frustrating, disappointing, and underwhelming end user experience of working with tools that seemed to just get in the way.
It’s everything the enterprise needs, and everything the user wants.
And it’s just.. a browser.
And that explains why today, The Enterprise Browser is the Best Enterprise Security Solution of 2022.
Several years ago, Island Co-founders Michael Fey and Dan Amiga had an epiphany.
What if enterprise organizations had complete control over the browser environment? They knew the traditional web browser was the most widely deployed application by enterprise organizations; yet the browser wasn’t built for the enterprise, it was built for the consumer market.
This commonly used software application is incapable of offering the high-level security, visibility and privacy enterprise users needed.
If it could be modified for the enterprise, they knew it could change everything. With this belief, the founders began developing an enterprise browser that would simplify the security stack, give the enterprise complete policy control and deliver a more efficient, safer and productive browsing environment.
In February 2022, their vision became reality when the enterprise browser emerged from stealth mode to take control of the last mile – from the network to the end device - and redefine the end-user experience.
With the Island Enterprise Browser launch, enterprise organizations no longer need Secure Sockets Layers (SSL) or costly virtual desktop infrastructure (VDI) for data loss prevention.
While the thought of contractors accessing Software-as-a-Service (SaaS) applications from home once made CISOs think twice, with Island’s Enterprise Browser they can now greenlight personal email, collaborative platforms and Bring Your Own Devices (BYOD) while quickly ramping up contractors as needed.
After nearly two years of product development, the Island browser emerged at a time when most major browsers were standardizing to the Chromium open-source project. Leveraging the open-source project, Island’s co-founders seized an opportunity to create a custom browsing experience for enterprise organizations without having to build their own rendering engine. Building on Chromium also meant creating an entirely familiar experience for end users, reducing friction in deployments.
“We could stand on the shoulders of those giants and make sure all of our energy went into making the browser the best enterprise resource possible by upgrading the security posture, improving integrations, giving them complete policy control and providing infinite last mile control,” said Michael Fey, co-founder and CEO, Island.
At the same time, enterprise organizations were shifting to a remote workplace where contractors, call center staff, and BYOD workers needed access to internal web and SaaS applications like Salesforce and Workday.
Island’s enterprise browser allows these organizations to seal the SaaS environment, secure last-mile control and achieve total data loss prevention (DLP). By simplifying the security stack and working with, not against, existing systems, the browser is able to support web filtering, web isolation and Zero Trust network access with a cost-effective solution.
“When call centers move remote, they find themselves going to a SaaS application over a virtual infrastructure to a backhaul location to get out to the SaaS application,” says Fey. “We bring common sense to that architecture and let those users go directly to the SaaS application while still providing the security controls.”
A pricey venture requiring a massive number of engineers, Island’s browser also carried the good fortune of launching within a favorable fundraising environment, with Insight Partners, Stripes and Sequoia Capital providing more than $200 million in capital to bring the founders’ vision to light.
Unlike bolt-on security tools, Island’s enterprise browser provides deep control at the operating system level with security that’s built by design.
While not a replacement but more of an augmentation to the enterprise customer’s existing approach, the enterprise browser circumvents massive change management, allowing enterprises to quickly ramp up call centers and contractors on personal devices.
Users can decide what the browser does and doesn’t do – like cut, copy, paste; take a screenshot; tag traffic; redact data; and change what information flows under enterprise control and governance.
Although Island’s enterprise browser provides remote browser isolation, web filtering and mobile device management (MDM), the browser most often works alongside existing systems to simplify the architecture, reduce expense and provide total endpoint protection.
“This allows us to connect to any of those designs and complete that last mile that’s been missing. So often in the Zero Trust architecture, people would get to the last mile and realize the data on the endpoint was still a massive point of risk, so they went with a heavy, overburdened architecture like a desktop as a service. The enterprise browser allows us to rethink the last mile and ensure it collaborates with all the platforms,” says Fey.
Island has built an impressive roster of leadership and engineering talent with a “nexus of experience” approach beginning with Fey, the former president of Symantec, and Amiga, the founder of Fireglass, an RBI solution that works with Chromium browsers.
“In the world of cybersecurity, where the bulk of people spend their entire careers selling and building something that is just the next generation of something else – the next endpoint, the next gateway, the new firewall – this was an opportunity for those people to take all that skill and expertise and do something fundamentally new and different. We’ve excited people’s imaginations,” says Fey.
The co-founders also learned early on that they would need to remove the friction of adoption if they were going to realize the ultimate vision of delivering the first enterprise browser.
“I think too often people fall in love with their big vision and don’t fully appreciate the challenges they will encounter on the path between the vision and the reality,” says Fey. “You have to address the journey from day one because your investors are going to go to those places and ask you the hard questions, and the difference between an investment they’re excited about and one they just think is interesting is having great answers and proof points to solve those problems.”
Fey advises other startup founders to first identify the obstacles that may be standing in the way of their go-to-market plan. “What is uncharacteristically difficult about your plan? Whether it’s adoption, the business model or the tech, make sure your early days of investment are about tackling that,” he says.
As Island drives toward more integrations, Fey expects the company to expand beyond cybersecurity by helping IT better understand performance and the end user process with greater visibility.
Island’s founders believe every enterprise organization will be running on an enterprise browser one day. “That level of control at the last mile is essential to delivering things like Zero Trust, secure edge and BYOD,” says Fey.
If the vision holds true, the enterprise browser will soon become a core part of the IT toolset as users seek a safer, more secure and productive end solution.
One of the biggest challenges nearly all engineering organizations face is scaling up without slowing down productivity or compromising on security standards. One area where we at Island encountered this challenge is in controlling access and permissions to AWS without compromising on speed and developer autonomy.
While AWS IAM is packed with features, including support for ABAC (attribute-based access-control), It is often very hard to control who can tag what at scale. In this blog post, we’ll dive into the deep waters of AWS IAM, face its problems and learn how to leverage IAM policies to make ABAC scalable.
This journey walks through parts of a talk I gave at fwd:cloudsec 2022 called "The Power of AWS Tags". I encourage you to watch it here
You might be familiar with RBAC (role-based access-control), where access is granted for specific roles on specific resources, which typically requires an administrator to handle permission requests from R&D teams and adjust their roles accordingly. In many organizations - this is a slow process.
On the other hand, if permissions are managed with ABAC (attribute-based access-control), it is easier for the administrator to create rules to match resources by the attributes set on both resource and actor. That way permissions would be granted dynamically, lowering the number of requests from R&D teams and giving teams more autonomy and control over the resources they own.
For example, here is a rule an admin may configure: “users of team: infra can read data from DynamoDB tables tagged with owner: infra.”
This IAM policy would look like this:
What if a bad actor from the infra team had access to modify the tags of his own user or role, or even modify the tags of other DynamoDB tables? Privilege escalation is pretty easy.
In order to mitigate this, we’ll need to protect our owner tag. Let’s write statement like this:
Now, imagine you manage 30 of those tags. Adding a protection statement for each kind of tag sounds pretty cumbersome, and with IAM policies contain as many as 6144 characters, it’s probably a good idea to propose a solution that will allow scaling ABAC with more ease.
Looking at the previous policy we came up with, it is easy to distinguish each statement as its own role:
Think of a UNIX filesystem. If I’m granted permissions to my home directory at `/home/itamar` I can write anything under that path, since this is my grant area.
Translating this into IAM, we’ll assign each user/role with a grant path of their own that will define their tagging grant area: if a role’s grant path points to “ctl/v1/admin” then users assuming this role can tag anything under that path, like “ctl/v1/admin/owner” (but not “ctl/v1/bagels”).
In our UNIX filesystem we’d have a special file, in which every entry will be a username and its grant area, and no one would have write access to it (unless they’re using sudo). Like this:
Yet in IAM, we don’t have the equivalent of a centralized file, so each principal will hold its own grant path in a tag key (which itself, is a control tag under a meta subtree) that no one can create, delete or modify (unless they use “sudo”, we’ll get to that..). In that case, the tag value will be a pointer to the grant area.
Control Tags are a privileged set of tags. Any tag that starts with `ctl/` is a Control Tag.
Let’s see the IAM statements behind this control plane:
Let’s break this down:
It’s THAT simple
NOTE: NEVER SET THE GRANT_PATH TAG TREE TO ANY OF THE PRINCIPALS.
Say you want to introduce a new team to this scheme, change paths or add a broader grant area for some users.
There are two main options to manage grant paths for your users:
To sum up, Control Tags are a great way to manage tagging permissions and enable some developer autonomy in your organization. Check out my entire presentation to learn more tricks Control Tags have up their sleeves
“Zero Trust” is everywhere in the cybersecurity world. While it’s fair to say that the term is a bit over-used by over-zealous marketers, the security paradigm it describes is real. Broad categories of security exploits can be significantly reduced – if not eliminated – by implementing a zero trust security model that continuously validates user identity, device posture, and resource access. One area that’s often overlooked in zero trust implementations is the last mile: extending the principle of least privilege all the way to end-users of information systems.
To understand the last mile of zero trust, let’s first review the first mile. A user wants to access a protected resource, such as a customer record stored in their SaaS CRM platform. The user’s identity is verified against the enterprise identity provider (IdP), the security posture of her laptop is validated to conform with enterprise standards, and her access privileges for the CRM platform are verified. Once this level of trust is established, a secure connection is established between her laptop and the CRM platform and the customer record is displayed. In an ideal scenario, everything just mentioned happens in milliseconds and is transparent to the user.
At this point in our scenario, a customer record is displayed on screen. Now let’s consider the last mile: what can the user do with that data?
This deeper level of granularity in data protection is critically important – but it’s left largely unaddressed by legacy ZTNA vendors. The principle of least privilege is a foundational tenant of zero trust: a user should be given only those privileges necessary to complete their job. Returning to the example above, her job requires access to customer records from the SaaS CRM platform; her job does not require her to make new copies (printed or digital), move customer data to a personal email, or share customer records to a Zoom meeting. Most of the time, she doesn’t need to view credit card data, but there are some exceptions when she needs that information to resolve a customer issue.
An ideal last-mile security policy would look like this:
This vision for embracing zero trust principles for end-to-end security of modern web apps and data inspired the development of Island, The Enterprise Browser. It’s the browser that’s designed for the enterprise that makes work fluid, frictionless, and fundamentally secure. Instead of layering security tools on top of a consumer-focused browser, Island applies security controls within the browser itself. It’s the perfect on-ramp for putting zero trust principles into practice, both at the network layer and at the last mile. Because it’s built around Chromium technology, users enjoy the fast, familiar experience they expect. It’s work as it was meant to be, where security is native to all users, applications, and the data between them.
The zero trust security model builds on decades of hard-learned lessons. The era of a secure network perimeter is long past, so we should never implicitly trust a connection based on its network location alone. With the ubiquity of federated identity providers, we can positively identify the identity behind every request. We can evaluate the posture of the device a request originates from to protect to further protect against stolen credentials being misused. And with modern networking technologies, we can start from zero and build up these layers of trust before allowing the network connection, then continuously re-evaluate trust with every request.
As a security philosophy, zero trust offers a path to resolving many categories of vulnerabilities. Credential theft is much less effective when we require multiple factors for authentication and evaluate the device posture before granting access. Internet-based attacks can’t succeed if there is no routable path between a private app and the outside network. Even if malware is already resident on a device, lateral movement to infect other devices is made exponentially more difficult.
Bringing zero trust out of the realm of theory and putting it into practice means investing in security tools. An identity provider, some network infrastructure, and typically some combination of endpoint agents. Curiously, there’s one application at the center of almost every zero trust workflow that’s been ignored by most security vendors: the web browser.
When an enterprise invests in security tooling to put zero trust in practice, it doesn’t make sense to leave a basic consumer-oriented web browser at the center. Island built The Enterprise Browser to change that.
The Enterprise Browser is the on-ramp for a practical zero trust security implementation. It integrates with identity providers for user authentication and identification of all web activity. It continuously evaluates device security posture, without requiring any additional agents. It can make secure connections to private apps and resources over any network, while keeping those private apps completely dark to unauthorized access. It can apply last-mile controls to protect data from inappropriate use or accidental leakage – something that is virtually impossible for a legacy network-based security tool to achieve. And all web activity within the browser can be logged and shared with a SIEM or analytics platform to gain unmatched visibility and inform security governance and incident response.
And because all of this is built around a Chromium-based web browser, the end-user experience is frictionless and familiar. There are no extra agents to deploy, no training to teach users how to connect. Simply by introducing a new web browser, you can take a practical step at leveling up your security practice and embracing the zero trust paradigm.
A collaborative partnership with end-users is key to any successful security strategy.
At baseline, any new security tool or technique shouldn’t burden users or disrupt their general productivity. Thankfully, modern security practices are generally transparent to users or follow familiar patterns that become second nature. Clear communication with users in the form of status indicators, notifications, or error messages (with instructions on what to do next) goes a long way in ensuring lasting success.
The Enterprise Browser offers a unique approach to end-user engagement. The browser itself is tuned to be fast and a tailored enterprise app chooser makes every app and resource immediately available. There are no added burdens for end-user adoption, and no extra steps that could hinder user productivity. User messaging can be customized to match corporate brand voice, and users get clear and immediate feedback when they encounter a security policy. It’s tempting to overlook user experience or take it for granted when designing a security strategy. The Enterprise Browser makes it easy for end-users to adopt it as their default browser, and it gives Security teams the tools they need to clearly communicate their security policies.
The concepts and technologies that form a zero trust security model are not a secret, nor are they proprietary to any one security vendor. Today’s challenge is largely one of optimization and operations – how do we implement a security strategy that decreases risk without disrupting end-users or business operations?
This challenge is what motivated creating The Enterprise Browser. It’s a unique approach, where the web browser itself plays an active role in the security strategy. Sometimes changing one thing changes everything.
There are still many advantages to centralized purchasing and provisioning, both financial and operational. On the other hand, every business needs the ability to extend access to a personal device in some cases: employee onboarding, business continuity, or contract workers, for example. Some employees want the option and convenience of accessing business apps using their home computer. Balancing the competing concerns of information security, IT operations, and user privacy is no small task—as is evident from the mixed results of BYOD in practice.
BYOD initiatives often stumble when they hit one or more of these three pitfalls:
First, the Enterprise Browser eliminates the need for a system-level endpoint agent on a personal device. By enforcing security and management policies in the browser itself, all critical web apps and data are secure. Last-mile controls keep data in the browser, stopping data leakage and keeping business and personal data separate. Users keep their personal privacy and you get the security controls you need. No endpoint management agent required.
Next, the Enterprise Browser eliminates the need for DaaS or legacy VDI. On top of the security controls mentioned above, the Enterprise Browser protects against web-based browser exploits, phishing scams, man-in-the-middle attacks, malware, and more. Instead of adding multiple security agents, or virtualizing the desktop and all its apps, The Enterprise Browser addresses the root cause of web vulnerabilities: the web browser itself. You get more granular control and visibility than with VDI or DaaS, without the cost and complexity.
Last, the Enterprise Browser is already familiar to users. It’s based on Chromium, the same as Chrome, Edge, and other modern web browsers. The user interface is the same and every web app functions exactly as expected. And unlike DaaS, it’s running locally on their computer, so performance is excellent.
The Island Enterprise Browser is a unique approach that resolves several common problems that hold back BYOD. To learn more about how Island can deliver a better BYOD experience, contact us.
The promise of desktop virtualization is hard to argue: your employees can work from (just about) any device, anywhere in the world while you keep your sensitive apps and data secure and centrally managed. VDI was a decent solution at a time when most organizations managed their own data centers, Windows apps were the norm, and working with rich content (such as video) wasn’t a requirement. Today, most apps are delivered through a web browser and hosted by SaaS providers. Users often connect from home networks outside the reach of enterprise controls. A growing remote workforce pushed many organizations to rethink how they secure and monitor access to critical apps. As an established technology, VDI or DaaS was a natural choice at the time.
But as your help desk tickets will confirm, virtualization in any form comes with a huge burden on both operations staff and the end-users they support. Performance issues, network congestion, and complex provisioning weigh against the benefits of virtualization. Add to that the high costs of hosting, licensing, and operating a robust VDI or DaaS environment and the costs start to outweigh the benefits.
The Enterprise Browser takes a new approach to securing critical apps and data. Instead of adding layers of virtualization–disrupting the user’s experience and adding cost and complexity–security and access controls are built-in to the browser. Users authenticate with their corporate credentials, last-mile controls stop data leakage, browser hardening protects against malware, and full activity logs are sent to your SIEM. This approach gives InfoSec teams a level of control and visibility that goes way beyond VDI or DaaS, and end-users enjoy unrivaled performance.
Provisioning a new user with The Enterprise Browser is much simpler for IT Operations teams: install the browser. That’s it. End-users can even download and install it themselves on devices IT doesn’t own or manage. And it’s available for Windows, macOS, and Linux so everyone gets to enjoy full native-app performance. Once deployed, IT’s job is done: no performance tuning, resource monitoring, or cost modeling required.
The end-users who are working with SaaS apps every day see a noticeable improvement. The Enterprise Browser is built on Chromium, so web performance is as good as it gets. Since there’s no virtualization overhead, there’s no lag or visual artifacts. Users get their work done, in a browser they’re already familiar with.
The Enterprise Browser won’t replace all virtualization: if you’re connecting to systems for high-end CPU or GPU workflows, VDI is the right play. But if your primary goal is to secure access to web apps and data, across a remote or distributed workforce, The Enterprise Browser is a far better choice. Get a demo.
2022 marks the end of the Internet Explorer era, with Microsoft ending all support for IE11. While it’s no surprise that modern browsers like Chrome, Edge, and Safari have replaced the legacy Internet Explorer, there are still many organizations who rely on legacy web apps developed years ago and seldom updated. These legacy tools are often critical to some business process and difficult to replace (hence why they’re still in use today).
Many legacy web apps were built before MFA was a common practice. Refactoring the login and authentication flow to support MFA is a daunting task for old, brittle code. So, while it’s a universal best practice to use a second factor during authentication, it may be impractical if not impossible.
The Enterprise Browser can change that: the browser integrates with your enterprise Identity Provider so every user is identified and authenticated with as many factors as you like. You can go further and require a one-time code on when a user navigates to a web app–giving you the security benefits of multi-factor authentication without touching the legacy source code.
Another challenge for legacy apps is managing shared credentials. In an ideal world, every user would use their own credentials to authenticate; in practice it’s not uncommon for legacy systems to rely on a shared administrator account. When common credentials are shared among several users, you lose visibility and control over user access. And revoking credentials for a user when they leave the organization can be inconvenient (or worse, left undone).
The Enterprise Brower can help: you can store shared credentials securely and make them available to specific users or groups. When the user reaches a login page, the browser will offer to auto-fill the credentials. Unlike using a shared password manager, the actual password is never disclosed to the user. Since every user is identified within the browser, you get an accurate record of every user and every login event where shared credentials are used. Password rotation is much easier, with a single place to update in the Island management console. And revoking credentials is as simple as removing that user from the access list in your IdP.
As published by Microsoft:
The Internet Explorer (IE) 11 desktop application ended support for Windows 10 semi-annual channel on June 15, 2022. Customers are encouraged to move to Microsoft Edge with IE mode. IE mode enables backward compatibility and will be supported through at least 2029.
In global web browser market share, Edge holds about 4% behind Safari (20%) and Chrome (63%). Rolling out Edge with IE mode is a sizable effort for a rather limited benefit. It doesn’t answer either of the issues addressed above, so MFA and shared credential challenges remain unsolved.
The Enterprise Browser is a better choice: it’s built on the same Chromium browser engine as Edge or Chrome, so it looks and feels familiar. It offers IE11 compatibility mode so you can run legacy web apps in a separate tab, and it can solve the other legacy web app challenges listed above. Of course it doesn’t stop there–The Enterprise Browser is built for the modern workplace with security and user productivity in mind.
As described in the Chromium project's official site:
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web
Technically, Chromium is the name of the project, and is not referred to in the code. The product itself is Chrome, not to be confused with Google’s browser named Google Chrome.
Over the years, the Chromium project became more than just a browser. It’s a powerful web platform that can be used in many ways to build different products (Electron, Chromecast, etc). It even became an integral part of an OS (Chromium OS).
Chromium is one of the largest codebases in the world, and it runs almost everywhere. It is developed mostly in C++, but already includes some Rust, TypeScript and more.
Before we begin, let’s set some common terms which anyone interested in Chromium must know.
One of the most commonly known facts about Chromium based browsers is that they have lots of processes. But why are they all needed?
First of all, for security reasons. If we run all of our code in the same process, exploiting one part can lead to code execution all over the browser. It’s harder to isolate threads, so the browser leverages operating system’s features and isolates processes. In Chromium, a renderer doesn’t run in the main browser’s process. Different sites will run in different renderers who have different processes. Also, different types of processes have different privileges. Some processes are sandboxed. This makes exploiting the browser much harder, as in most cases you will have to chain multiple vulnerabilities in order to gain control of the whole browser
This separation is also good for the user’s experience. As more “services” or logical components are moved out of the browser process, it is more likely to recover from errors and crashes - it might be possible to just relaunch the service seamlessly. To be as fast as it can, it uses more operating system resources.
So what kind of processes do we have? Here are some notable examples
And of course there are more.
You can view your own browser’s processes by opening the browser’s task manager:
In this example, we can see a browser with 2 tabs. It has a browser process, some utility processes, a tab process for each tab and an extension process.
So we’ve got different logics in different processes, and some of them are tightly restricted. But how do they work together? If tabs are sandboxed and cannot access most of the operating system’s features, how can we listen to music or download files? It all starts with a bit of mojo.
Mojo is a platform-agnostic collection of runtime libraries, providing inter process communication primitives, a messaging format and a binding system. To make it simple, it allows components (within the same process or not) to communicate with each other over predefined messages, in different languages.
Mojo is the successor of a legacy IPC system, which barely exists as most code was migrated. Nowadays, the different components of Chromium communicate with each other almost only using Mojo. That way, when we upload a file, the renderer process asks the browser for the file’s contents - and the renderer doesn’t need to actually access the filesystem.
Mojo is relatively similar to other IPC systems, but is unique for its ability to pass object handles - such as file descriptors and file handles. It also allows validations that the browser uses for security (e.g. it doesn’t allow passing file path objects if the receiver might not have permissions to it now or later on).
In order to maintain a fluid user experience, the browser doesn’t allow blocking/synchronous operations to run everywhere. It would be a shame if the entire UI would freeze while the browser tries to write a file, or a single tab waits for server response.
Any blocking task that runs in the browser must be marked as such, and it would usually run in a dedicated thread. Blocking APIs always validate that they run in a context that allows blocking.
In the browser process itself there are different UI and IO threads.
Chromium provides interfaces which allow third parties to extend the browser and provide non-generic features to the browser. Extensions are the most known interface, but others exist as well.
Extensions and apps should be downloaded from the official store, but can practically be downloaded and installed from anywhere else.
An extension is defined via a manifest file. In this file it declares the permissions it requires, its scripts and in which tabs to inject them, what resources it needs, some metadata and more. An extension is limited in regard to what it can and cannot access, and it must ask for specific API permissions in the manifest (e.g. - storage, bookmarks, …).
Extensions can run two types of scripts - background and content. Background scripts run in the extension’s process, have access to the chrome API and in general have more capabilities. Content scripts are injected into the requested tabs and can access them. Background and content scripts can communicate with each other and work together.
While for the end user Chrome is the entire product, the project is actually built as a framework and a specific implementation of it.
The framework, often referred to as the web platform or the web engine is the multi-process sandboxed browser platform itself. It includes the rendering engine, interfaces for all supported features, most of the services and components of the browser and more. Think about it as a browser library.
Chrome is the product itself, the browser built atop the web platform - the UI, implementations of platform interfaces, browser specific logics and so on. It uses the framework’s library, implements some of its interface and “makes it an app”.
While the two were separated for code health reasons, it also allowed new opportunities such as creating other products on the platform - such as Electron, Chromecast and others.
in the code, all of Chrome’s code is under src/chrome, while the platform’s code is under src/content.
Great, you’re ready to dive deep into Chromium’s internals! We’ve learned what Chromium is, covered some basic concepts and set a common ground. In future blogs, we will move on to explore various features and areas in the project. Stay tuned!
The Enterprise Browser achieves the same outcomes as RBI — protecting malicious code execution, phishing attempts, and dangerous file downloads — but does so from within the browser itself. This means no added latency for the user and much less complexity for the organization. And unlike RBI that only isolates a fraction of web activity, The Enterprise Browser by definition protects all web activity.
Takeaway: Island, The Enterprise Browser, keeps all web-based work fundamentally secure—without the cost and complexity of a full RBI implementation.
While the Enterprise Browser delivers end-to-end security for web applications and their data, it’s so much more than that. By operating inside the browser presentation layer, it provides granular, “last-mile” controls such as screen capture, copy/paste, and download/upload control, or sensitive data redaction. But it doesn’t stop there: it also enhances any web app with robotic process automation (RPA), such as adding MFA to legacy web apps or placing additional approval steps for mission-critical workflows. And all data flows directly into your SIEM for detailed visibility and forensic analysis.
Takeaway: Island takes an entirely different approach to security that goes beyond the network or content layer to inspect and modify web apps at rendering time, opening a range of possibilities far beyond other security tools.
The Enterprise Browser secures access to web apps and content on any device, managed or not. It knows the posture of the device it’s running on and enforces policies accordingly. For example, the Enterprise Browser can redirect file downloads from an unmanaged device to in-browser secure storage to prevent data leakage. Many organizations are using the Enterprise Browser in place of more complex VDI or DaaS implementations to give contractors or BYOD users secure web access. Whether it’s running on an unmanaged or managed device, the full power of the Enterprise Browser remains intact.
Takeaway: Island secures access to web apps & content, regardless where it’s installed, with a deployment mode that’s far less complex than VDI or DaaS.
While the Enterprise Browser provides secure-by-design access to web apps, it’s built with the same familiar browsing experience that users already know and love. Policies are context-aware, so the security controls that keep sensitive data secure and enterprise apps protected are only applied where they’re needed. Unlike single-purpose secure browser products, the Enterprise Browser is often used as the default browser for all web access.
Takeaway: Island pairs enterprise security & management policies with a granular enforcement engine so the important apps and data are always protected without sacrificing browser speed or user experience.
The enterprise features offered by popular consumer-oriented browsers like Google Chrome and Microsoft Edge are significantly limited and only skin deep by nature. For example, the controls offered are only applicable at the device level, which means policies are by definition applied to all web apps, leaving no room for granular policy enforcement. And most essential enterprise features are missing entirely, such as device posture assessment for tailoring policy management, or inserting browser-based RPA to enhance web app functionality.
Takeaway: Existing browsers offer few, limited, and surface-level enterprise features that were not designed to address the wide-ranging needs of the enterprise. The Enterprise Browser, however, offers comprehensive control, visibility, and governance over all browser behavior, delivering a level of security that was previously unimaginable.
It may seem easy at first glance to confuse the Enterprise Browser with some familiar solutions we’ve seen over the years. But dig deeper, explore what the Enterprise Browser has to offer, and the truth comes out - changing this one thing really does change everything.
Chromium extensions provide a way of customizing the web-browsing experience by adding extra functionality to the browser. The straightforward way of loading an extension in Chromium is by installing it via a supported extension store. But that’s not the only way. An extension can also be loaded from a folder on the computer, via the registry, or via admin policies. Some extensions, called component extensions, are an integral part of the browser which happen to be implemented as extensions.
For each loaded extension, Chromium keeps track of its source location type, which affects the way the extension is treated. For example, component extensions are not displayed on the extensions page (chrome://extensions) and have some extra privileges.
In this post, we’ll take a closer look at where inside Chromium extensions are found, and why their location matters.
The ManifestLocation enum is defined in the manifest.mojom file in the Chromium source code, and at the time of writing, it has 10 valid values. The enum is preceded by a short explanation comment:
Historically, where an extension was loaded from, and whether an extension's files were inside or outside of the profile's directory. In modern usage, a Location can be thought of as the installation source: whether an extension was explicitly installed by the user (through the UI), or implicitly installed by other means. For example, enterprise policy, being part of Chrome per se (but implemented as an extension), or installed as a side effect of installing third party software.
Here are the 10 values and comments from the source code which provide a short explanation:
The values in the ManifestLocation enum are ordered chronologically, with each newly added value added to the end of the list. I found it more convenient to order the values by their rank. The GetLocationRank function, implemented in manifest.cc, assigns a rank to each ManifestLocation value in order to be able to decide which extension to load if there’s an extension of the same id in different locations. The rank has a good correlation with the privileges that are given to the extensions from the corresponding location.
Here are the ranks along with short comments which can be found in the source code:
In addition to the rank values, the ranking function divides the 10 ManifestLocation values to 5 groups, which helps get some extra intuition about the values and the way the browser treats them.
Before we begin looking at the different extension types, let’s tackle another basic question - how do we list all of the installed extensions and their location values? There’s the extensions page (chrome://extensions), but as we mentioned, not all extensions are displayed on it, and it also doesn’t show the location values.
One way to see all enabled extensions, including component extensions, is to navigate to chrome://system and look at the extensions row. Another way to see component extensions is to run Chromium with the --show-component-extension-options command line switch which will show them on the familiar extensions page (chrome://extensions). But those two methods still don’t give us enough information. Specifically, we still can’t see the location value of each extension.
To get full visibility, we can look directly at the information in the user profile folder. The “Secure Preferences” file contains the information we need. For Chrome on Windows, the file for the default profile is located in the following folder:
The file is a JSON file containing, among other details, the list of installed extensions for the profile which can be found under extensions.settings. For each extension, the key of the entry is the extension ID, and one of the properties is “location”. The location value is a number corresponding to the ManifestLocation enum defined in the manifest.mojom file.
For example, Google Chrome comes bundled with a component extension called Google Hangouts, and we can see the following entry for it in the Secure Preferences file:
This tells us that the location value of Google Hangouts is kComponent. The path parameter is also interesting - we can see that the extension is loaded from the readonly installation folder of Chrome, not from the profile folder.
After installing vanilla Google Chrome (version 97.0.4692.71) on Windows 10, here’s what I got under my profile:
Note that 4 extensions are visible on the extensions page, but in fact 14 extensions are installed.
The post wouldn’t be complete without mentioning extension types. Chromium defines another enum called Type, defined in manifest.h, which contains the following values at the time of writing:
The logic that determines the extension type is implemented in the GetTypeFromManifestValue function in manifest.cc. That’s the reason why, for example, the Slides extension was visible on the extensions page for me, but the YouTube extension wasn’t - the former is of type TYPE_EXTENSION, while the latter is of type TYPE_HOSTED_APP (and is visible on chrome://apps).
In this post, we’ll be focusing on extensions of type TYPE_EXTENSION.
As a reminder, here’s what the comment in the ManifestLocation enum says about kComponent:
An integral component of Chrome itself, which happens to be implemented as an extension. We don't show these in the management UI.
Component extensions are registered to be loaded by the AddDefaultComponentExtensions function in component_loader.cc, and loaded by the AddComponentExtension function in extension_service.cc. The list of component extensions is predefined in the code, and can’t be changed without changing the code and recompiling the browser. The extensions themselves are loaded from the browser installation folder, not from the profile folder, and don’t change unless the browser changes, e.g. on a browser update. That means that component extensions don’t update independently like regular extensions do.
As an example, here’s the commit that adds the Google Network Speech component extension.
It can be useful as a reference for adding your own component extension to Chromium.
Regarding special treatment of the browser for component extensions, you can find several such code snippets in the source code by looking for “kComponent” and “IsComponentLocation” around the code. Here are a couple of examples:
Note: Confusingly, in addition to component extensions, Chromium has something completely unrelated called components. Components are listed in chrome://components, and are bundles of files, usually dynamic libraries or data files, which are updated separately from the browser itself. To add to the confusion, components are distributed in .crx files, but they have nothing to do with extensions.
Before proceeding to kExternalComponent, there are details that are common to all kExternal* values. Extensions for all 6 kExternal* values (kExternalComponent, kExternalPolicy, kExternalPolicyDownload, kExternalRegistry, kExternalPref, kExternalPrefDownload) are loaded by loaders which are specialization classes of the ExternalLoader class. Those loaders are used by instances of ExternalProviderImpl that pass the loaded extensions to an installation service. The extensions are eventually loaded by the CheckForExternalUpdates function in extension_service.cc.
Each external provider can provide extensions in two ways: Extensions originating from .crx files, and extensions originating from update URLs. The external provider is initialized with a location type for each of the two ways, which the installed extension will end up being marked with.
Here is the rough list of extension loader specializations and their location values. ChromeOS-specific and other OS-specific cases are not included.
It’s interesting to note that kExternalPolicy is not present in the table. It’s only being used in ChromeOS.
The comment from the ManifestLocation enum:
Similar to kComponent in that it's considered an internal implementation detail of chrome, but installed from an update URL like the *kDownload ones.
External component extensions are registered in the StartLoading function in external_component_loader.cc. The registration sets the extension IDs and the extension store URL to be used for installing the extensions.
Like with component extensions, the browser has special treatment for external component extensions. You can find relevant snippets in the source code by looking for “kExternalComponent” and “IsComponentLocation”.
The comment from the ManifestLocation enum:
A crx file from an external directory (via admin policies), cached locally and installed from the cache.
As was already mentioned, the kExternalPolicy location is only used in ChromeOS.
The comment from the ManifestLocation enum:
A crx file from an external directory (via admin policies), installed from an update URL.
kExternalPolicyDownload extensions are registered in the StartLoading function in external_policy_loader.cc. Two instances of ExternalPolicyLoader are created, one for forced extensions (that can’t be disabled) and one for recommended extensions.
Like with other location types, the browser has special treatment for policy extensions. You can find relevant snippets in the source code by looking for “kExternalPolicyDownload” and “IsPolicyLocation”.
The comment from the ManifestLocation enum:
Extensions that are loaded by using the --load-extension command line switch are marked with the kCommandLine location. They are loaded by the LoadExtensionsFromCommandLineFlag function in extension_service.cc, which delegates the loading to UnpackedInstaller which loads the extensions from their target folders.
The browser has special treatment for extensions which are loaded unpacked. You can find relevant snippets in the source code by looking for “IsUnpackedLocation”. There are also a few places with special treatment specifically for “kCommandLine”.
The comment from the ManifestLocation enum:
From loading an unpacked extension from the extensions settings page.
Extensions that are manually loaded from a folder for development are marked with the kUnpacked location. They are loaded by the FileSelected function in developer_private_api.cc, which delegates the loading to UnpackedInstaller which loads the extensions from their target folders. They are also reloaded by the LoadExtensionForReload function in extension_service.cc on browser launch.
The browser has special treatment for extensions which are loaded unpacked. You can find relevant snippets in the source code by looking for “IsUnpackedLocation”.
The comment from the ManifestLocation enum:
A crx file from an external directory (via eg the registry on Windows).
kExternalRegistry is a Windows-specific location for extensions that were loaded from a local .crx file via the registry as specified here: Pre-installed Extensions (Pre-installing via the Registry). The extensions are registered in the StartLoading function in external_registry_loader_win.cc.
Note: Extensions that were loaded from a URL (and not a .crx file) via the registry as specified here: Alternative extension distribution options (Using the Windows registry) are registered with the kExternalPrefDownload location, not kExternalRegistry.
The comment from the ManifestLocation enum:
A crx file from an external directory (via prefs).
kExternalPref is a location for extensions that were loaded from a local .crx file via the browser preferences as specified here: Alternative extension distribution options (Using a preferences file). The extensions are registered in the StartLoading function in external_pref_loader.cc. Two instances of ExternalPrefLoader are created, one for the system-wide preferences and one for the per-user preferences. kExternalPref is not used on Windows (except for ExtensionMigrator which is a specific migration case).
Note: Extensions that were loaded from a URL (and not a .crx file) via the browser preferences as specified here: Alternative extension distribution options (Using a preferences file) are registered with the kExternalPrefDownload location, not kExternalRegistry.
The comment from the ManifestLocation enum:
A crx file from an external directory (via prefs), installed from an update URL.
kExternalPrefDownload is a location for extensions which were loaded from an update URL via the registry (Windows) or via the browser preferences (non-Window). See kExternalRegistry and kExternalPref for more information.
The comment from the ManifestLocation enum:
A crx file from the internal Extensions directory. This includes extensions explicitly installed by the user. It also includes installed-by-default extensions that are not part of Chrome itself (and thus not a kComponent), but are part of a larger system (such as Chrome OS).
Except for a couple of specific cases, kInternal extensions are the common, regular extensions that are installed by the user from the extension store.
In this post, we went over the extension locations that Chromium defines and uses. We looked at when and where they’re used, and how they affect the way the browser treats the extensions.
We were building a really big product, and we knew we needed to do it right from the start and keep it right at scale, no matter how many engineers we onboard.
We knew the code itself was less important, as it would change frequently, but building a mechanism that would allow us to move fast while continuously onboarding people was critical. And because of that, we decided to invest in building the right infrastructure.
Here are the five main areas we focused on to successfully launch Island.
We wanted the code to look similar across the system, so we made a skeleton of how a microservice looks, how an extension “service” looks, and made sure they were similar to each other. This made diving into any code and things like code reviews much simpler. It also enabled us to get into someone else’s code very quickly, easily, and confidently, since all of the code looked similar. Naturally, we didn’t want to create a big boilerplate for each service, so we wrapped it in generators and Jenkins jobs to create the code as easily as deploying it. Today, populating a new service takes less than a day and is mostly automated. Engineers focus on the business logic rather than how to install dependencies, or how the code structure should look.
And of course, in the specific cases where you’d want to go out of the template, it would be obvious to understand a discussion is needed around it
We then understood that, while we wanted to move fast and release features in rapid phases, our releases had to be of the highest quality and remain that way. Maintaining this high-quality standard was extremely important because the browser is such a crucial tool for everyone – bugs could negatively impact our customer’s productivity – and because of that we kept progressing without letting ourselves get “stuck in the mud” with a lot of regression bugs.
First, we had a rule: No code goes unreviewed. Every piece of code must be reviewed by at least one person from the team. Every feature, every bug, every configuration file, even every typo fix. In specific cases we even added code owners to make sure only the code they approve makes it into the product.
Second, we added CI in the form of github actions to enforce specific style, coverage of tests, build and quality of the code (no warnings etc.), and while coverage does not always point to quality, it at least forced the engineers to think about what they wanted to test and how.
Here’s a nice graph on how our coverage looked after we started enforcing it. When we started back in Jan ‘21 we were at around 80%, eventually making it to 97%.
In addition, we invested heavily in automation from the beginning. This gave us the ability to test features E2E and and keep ourselves accountable for its stability and consistency, while always improving our ability to understand and debug issues on a given PR.
Here is an example of our Grafana presenting the automation success rate:
Another good example is our per-test fail ratio & build time, for monitoring which tests are giving value, which are not, and of course which are slowing us down:
Deploy, deploy, deploy. Since we use our own browser on a daily basis, we wanted to make sure engineers are comfortably deploying multiple versions a day while maintaining a high level of quality. Instead of canary or blue-green deployments style, we wanted to make sure our deployment strategy fits the Island company strategy – lots of engineers moving at a very fast pace. We chose a strategy to keep deploying and keep testing in production while having granular control on how each feature behaved. For that, we chose to use feature flags. Each development, each feature can be controlled by a feature flag (not only boolean, but every variation of a parameter) and each feature is gradually deployed among customers as well.
First we deploy features to our own browsers, then we deploy them to our demo segment and sales engineering. Afterwards we deploy them to specific customers (beta customers, early stage adopters) and finally to all customers. This strategy allowed us to control the quality of releases while getting continuous feedback from both internal and external users and our internal tools and metrics. In addition, it allowed our product managers to have granular control over the product and its deployment, and to decide how and when they wanted to present it to the customer instead of having to depend on engineering. Of course, we’ve added granular control flags in both unit-tests and E2E automation in order to ensure the system is working in all kinds of variations.
I suggest this strategy to any early stage startup wanting to move fast while maintaining high quality.
As we planned on continuously onboarding engineers, we made sure everything was well documented so a clear plan was presented to each engineer as they joined. Of course, like most companies, we assigned each new engineer a ‘buddy’ to guide them along the onboarding process. Our initial goal with onboarding was to have an engineer fully ramped up with all of our tech and be ready to insert code into the product by the time onboarding was finished. The engineer received a clear checklist of what needed to be done and what exercises were to be completed. There would be planned checkpoints between each technology, that included a sync with his/her assigned buddy where they’d show what they worked on. In addition, the engineer would add a module that improved the life of the day-to-day work of the developers, followed by a “kudos” shared with the whole company from his/her buddy to celebrate what the new team member achieved in such a short time.
What’s important to understand is that onboarding is not a static, one-time, “check the box” creation. It’s an ongoing process.
Every new employee joining the Island team improves and fixes the onboarding flow as we go, in case something is wrong or no longer relevant. In addition, we do a retrospective with the engineer and his/her buddy, and see what other items we need to add to the onboarding. For example, our onboarding originally focused only on technology. But over time, we added architecture sessions, product functionality overview, automation and other areas.
Finally, you can’t keep the flow without visibility and alerting. We added logs everywhere and set up alerts to dedicated slack channels on every error. We assigned a “developer on duty” to continuously investigate bugs and improve our monitoring infrastructure. We added dashboards to ensure quality as well as user experience, which measured latency of calls, time of browser events as well as error rate and uptime of production cloud services, all alerting into Jira.
It’s important to make a conscious effort to recognize when your organization is in scale mode. Every tiny decision is important, even the small stuff like how you organize a specific file in the development environment file system or taking the time for a regular retro with new employees.
Find a way to create an environment where quality is top priority but does not cause fear of deploying and merging. Enable the tools your engineers need to deploy their code comfortably while putting strict methods in place for having granular control over what is deployed and when, as well as ensuring overall quality. In addition, engaging product leadership to understand those decisions will create a healthy work environment while enabling the speed and velocity you need for early stage start-ups aiming to grow fast.
SaaS and corporate web apps present challenges to the enterprise many have not considered. The process of signing up and migrating critical business operations to the cloud is fast, easy and can add remarkable value, but comes with a tradeoff that’s not always obvious. These apps can increase an organization’s vulnerability to cybersecurity risk. Due to the nature of the web and traditional web clients (browsers), there is simply not an adequate level of data protection or governance.
Given the massive adoption of SaaS and web apps, this presents an urgent problem. Organizations are operating with thousands of apps, sanctioned and unsanctioned, and often have thousands of employees across myriad departments with their own needs. The need to create constant exceptions to give workers what they require creates massive complexity, along with equally massive risk.
In other words, the present situation is a colossal headache for IT departments.
Here’s the good news: we’ve solved this problem by creating an innovative new product category: the world’s first Enterprise Browser.
The web browser is now an integral part of the business technology landscape. Yet they were never meant to be enterprise tools. Conventional browsers may work beautifully, but they are a consumer product at core.
Pressing a consumer-grade tool into enterprise service comes with a slew of security complications. You can’t see how users interact with data within a browser. They can print screens, copy and paste data, take screen snapshots–a full range of potentially compromising actions for which organizations had minimal visibility.
There have been attempts to address this problem by bolting on tools such as web gateways and Cloud Access Security Brokers (CASBs). These approaches have always failed because these tools are cumbersome and do not offer fine-grained control, creating an ongoing governance mess.
These failures led us to pose a fundamental question: what if we approached this problem of control and governance directly in the browser?
Role-Based Access Controls (RBAC) associated with some apps provide a level of control, but they can’t do the one thing that enables effective governance: assert control over the right app, at the right time, for the right user.
An Enterprise Browser can do this by checking device posture during user logins to ensure trusted devices are being used to access critical SaaS apps. An Enterprise Browser allows you to create policies to block things like screen printing, cut & paste into non-approved destinations, or sharing information over web conferencing.
Additionally, you can use an Enterprise Browser to redact sensitive data types within applications via browser-based Robotic Process Automation (RPA) or enable deep audit logging to see every action a user has taken. An Enterprise Browser can also encrypt cookies to protect app sessions from intrusion, scan for malware, or create policies governing data storage and enhance privacy.
This gives you everything you need to make data protection and governance headaches a thing of the past.
While SaaS and Web apps have seen extraordinary adoption and delivered numerous benefits, cyber-risk and unstructured governance have hitched along for the ride. Creation of the enterprise browser is the breakthrough that IT departments urgently need to solve this long standing problem.
For a more in depth article on protecting critical SaaS and web apps using an enterprise browser, click here.
It’s been impossible to miss the recent cybersecurity incidents involving contractors and third-party access to organizational resources. While these headlines are hardly new, their impact is now exponentially more serious given the major shift to hybrid work, paired with mixed cloud and on-premises hybrid architectures.
Contractors and third parties often serve as the functional backbone of many operations. In some cases, they are individuals performing a specific function. In others, it’s a third-party organization performing an entire function like logistics management or HR. To ensure at least a basic level of security, organizations typically ask them to legally attest to their understanding of their responsibilities toward protecting the critical resources they are given access to. This may also involve rigorous inspection of the contractor’s controls and resources. But given the urgency of many contractors’ work, these inspections are often treated as a mere “checkbox.” Regardless of the need for speed or not, it’s a given that onboarding contractors and third parties is slow, expensive and cumbersome. Here’s why.
Third parties need to be granted access to an organization’s critical systems just to do their jobs, which organizations typically do using one of these two approaches;.
Both approaches involve different complexities and levels of risk that cause unnecessary pain on both sides. Let’s take a closer look:
As uncovered in recent news stories, third parties very often use their own devices. The advantages of this approach are fairly obvious. Allowing these resources to use personal devices saves time, reduces onboarding costs and allows the third-party’s resources to operate in a familiar environment, which significantly speeds up productivity.
But this approach has its downsides as well. It requires giving individuals account credentials to the systems (VPNs, Virtual Desktops, and actual applications) they need to perform their roles. Onboarding this kind of access is complex, costly, and requires ongoing attention to manage provisioning and revoking access and credentials.
On the other hand, many organizations opt to ship a company-owned, managed and pre-configured device to the contractor or third party. The upfront cost and effort involved in buying, building, and shipping these devices at scale is immense. Not to mention the timing - it can take a month or longer to get a single contractor up and running. It also creates a steep learning curve on the third-party’s side to integrate new devices and systems into their workflow. While ultimately this may be the less risky approach, the significant tradeoffs feel unacceptable to both the organization and the third party.
In both of the above scenarios, provisioning alone is a serious organizational challenge. And yet, it’s only the beginning. Ongoing governance is also necessary to ensure contractor and third-party access is limited to only the sources and systems necessary to perform the responsibilities they were hired to carry out. This requires uncomfortable architectural choices to be made to balance the often opposing forces of efficiency and risk. On a practical level, these considerations include whether to use VPN backhaul, cloud forward/reverse proxy implementations, virtual desktops, CASB, DLP, Web Gateways, or ZTNA technologies to govern third-parties safely. Unfortunately, these decisions cause complexity and costs to explode, leaving the organization vulnerable to the contractor or third-party risk. This was made quite evident in recent headlines where the level of complexity for offshore third-party access was undoubtedly one of the core issues.
We’ve always been forced to choose between security and complexity or speed and efficiency. This is what we challenged ourselves with. A way to ensure security while enabling work. Maximum efficiency, minimum risk. And out of this challenge came the industry’s first browser built for the enterprise. Imagine, instead of all the organizational challenges, all the workers’ frustrations, all the costs and complexities, contractors or third parties just logged into a browser that had all the resources they needed waiting for them. This is what the Enterprise Browser can do for work.
Let’s start with provisioning. For third-party organizations or contractors using their own devices, you provide a download link for the Island installer. Once the browser is installed (it takes less than a minute), you give them credentials and access privileges aligned with their role, and in seconds they begin working. The applications they need are immediately made available with no complex configurations or additional software required. And for organizations choosing to provide their own managed devices to contractors or third parties, simply include the Island Enterprise Browser in your device build, and the process is exactly the same as above.
Once the user is working on the Island Enterprise Browser, your organization’s applications and associated data are fundamentally protected. Island’s unique last mile controls allow you to easily create policies to govern application and data access. And further, it allows you to control who has privileges to add new users, who is authorized to change or copy data, and whether or not a user can download, screenshot or save content.
You also get extraordinary visibility in a way that simply wasn’t possible before; deep forensic audit logging to keep a close watch on what these resources are doing as they do their jobs. You can even output these activities in real-time to data aggregation environments such as SIEM to monitor user behaviors and actions to quickly discover unwanted activities. Island sheds light on a unique dimension of user-based data by keeping tabs on the contractor or third-party’s actions within the browser window.
As seen in recent news stories, the inability to govern contractor or third-party usage of key application areas was what allowed attackers to manipulate backend application areas that very well could have been out of the scope of the third-party’s work in the first place. Last-mile control and deep logging could have been the difference between identifying and preventing any sort of compromise and hunting down and remediating the problem once the damage is done.
And while it’s essential to govern the actual contractors or third parties as they engage in critical application areas, it is equally necessary to ensure that they are protected from outsiders who might leverage them as a vulnerable attack vector in the organization. Island ensures that the browser is safeguarding the entire journey on all sides, at all times. Island delivers several key capabilities to ensure that attackers are thwarted in their attempts to use the contractor or third party as a vector of compromise. These capabilities include:
These built-in capabilities ensure that the organization’s applications and the contractor or third party are always protected from attack as they perform their work.
Third-party contractors and resources are pervasive and the practice is growing exponentially as the gig economy and the need for hyper specialized project work expands. Companies are purposefully building this practice into their business models, making these services very often mission critical to operations. But recent compromises using this vulnerable channel threaten to either reduce the practice entirely or forcefully add more cost, complexity and inefficiency into the process.
It is time to consider a whole new way to approach contractors and third-party access. We need to be able to get people to work quickly, and allow the organizations and people on both sides of the equation to be confident that both the applications, data and users are protected. With Island’s Enterprise Browser at the core of these use-cases, you can safely and quickly get people to work, create a great user experience and be confident your data and applications are protected.
When was the last time you thought about your web browser?
The truth is that today's browsers are so powerful, refined and simple-to-use that we essentially take them for granted. Most people use the browser for personal/consumer use and the same exact thing to access their work environment.
A new report from leading analyst firm Frost & Sullivan highlights the challenges of using a consumer browser for business and points out the features and functions a true enterprise browser must offer. You can download it here.
I think the report sums it up best with this statement:
“An enterprise browser with a different approach, which delivers functions with the enterprise in mind, is needed. With the proper control, the browser is able to solve serious problems more easily. Its position is a very unique intersection of users, critical web applications, the underlying data, and the threat landscape.”
Here’s a quick summary of the report.
Consumer-centric design hasn't stopped web browsers from playing a critical role in the business technology ecosystem. Yet it has created a very significant (and often underappreciated) problem: Conventional browsers don't have the visibility, control and manageability required for corporate SaaS and web-based applications.
In other words, reliance on conventional browsers means the assumption of significant and sustained cyber-risk.
Fortunately, there is good news: A new category of browser now exists -- one that pairs the speed and flexibility of a consumer browser with the security of an enterprise-grade product.
Meet the Enterprise Browser.
Today, the browser has become the new office. Employees spend much of their workday accessing data and applications through browsers. This greatly accelerated during the COVID-19 pandemic, which sparked an explosion of telecommuting activity.
Massive adoption of work-from-home and bring-your-own-device scenarios, however, means that IT departments now have even less visibility into user behavior and how people and data are interacting.
For CISOs, the security concerns that come with vastly expanded work-from-home opportunities simply add another layer of stress and pressure.
Other key issues include:
That's a tall order. Fortunately, it's now possible, for the first time, to address these challenges at the browser level.
A browser rests at the intersection of organizational users, critical applications and underlying data. They are deeply embedded in almost all organizational activity.
Yet enterprises have not been able to exert flexible control over what happens when employees use these browsers. Consumer-grade browsers simply do not offer tools to implement security policies. As a result, they leak data. They are vulnerable to screen grabs or printouts, downloads, copying and pasting into personal apps or even smartphone snaps.
Enterprises understand this and have historically attempted to mitigate these risks with multiple security and management tools. Plus, they are forced to do things like banning the use of personal email accounts or other applications. Yet these measures are not truly effective, and they alienate employees.
Enter the Enterprise Browser -- an innovative new product category.
An Enterprise Browser mitigates cyber-risk by assessing the posture of the device on which it is installed. It then dictates the appropriate policy depending on the device type of the logged-in user. This means organizations can manage access regardless of device, user or location.
In essence, an Enterprise Browser gives CISOs infinite control over how users and information interact.
Fine-grained controls aren't the only benefit offered by an enterprise browser. They can also audit user behavior, giving enterprises visibility if unauthorized screen grabs or data copying occurs. This level of visibility into browser-level user and data interaction has never existed before. And what’s more, is that organizations can enforce the use of an Enterprise Browser for certain applications, while allowing standard consumer browsing for personal use or access to non-risky applications or destinations. And for the final kicker, since it is based on the open source Chromium browser, the basis of the majority of browsers in use today, the Enterprise Browser delivers the same experience to users, lowering resistance to adoption significantly.
Conventional browsers are powerfully elegant pieces of software. Yet they are poorly suited for the integral role they are being asked to play within the business technology ecosystem.
Introducing enterprise-grade security at the browser level with an Enterprise Browser is one of the most impactful things CISOs can do today to simplify their entire security architecture and mitigate some of the most urgent cyber-risks they face.
Get the Frost & Sullivan report by clicking here.
As organizations turn towards SaaS cloud-based applications to help them grow, there is an increasing need for access control and sensitive data control measures to be taken. However, internal security teams have many different complications to work through in order to maintain compliance and protect sensitive data across enterprise-level organizations.
Third-party SaaS applications are increasingly important for businesses, as they help manage key operations, improve employee collaboration, and help new initiatives start quickly. While these applications provide many benefits to organizations, they also make security management difficult as there are limitations to access controls for internal IT, risk, and security teams.
Adding even more complication to the problem is the increased reliance on non-corporate-owned devices and personal devices. This goes hand-in-hand with the growing hybrid workforce, making it even more difficult to maintain compliance and security standards across an organization. New strategies are needed in order to address these problems.
There’s no question that third-party SaaS applications help businesses grow, compete with competition more effectively, and cover gaps within the workforce. However, they do add challenges to IT, security, and compliance or risk teams' ability to:
IT, security, and risk teams struggle to manage the staggering amount of third-party SaaS and internal web applications that organizations are adding to their workplace. SaaS applications are often designed for the most common use cases, making specific access and compliance controls difficult to manage and security hard to maintain across departments and at-home or hybrid employee offices.
Most organizations use consumer browsers like Chrome or Edge to engage with SaaS and web-based applications. However, these browsers were not built with governance in mind and offer no controls over what a user can do inside an application, including printing, taking screenshots, or downloading content.
Clearly, a new approach is needed in order to provide security to modern businesses with cloud-based SaaS applications, hybrid work environments, and non-corporate devices. ESG has identified a new, disruptive approach to securing and managing user and data access—an enterprise browser.
Island is a security-enabled and compliance-focused web browser. It uses the same capabilities and user experience that you would find in Chrome or Edge, but ensures that organizations have control over how users interact with information and provides core security controls for IT, risk, compliance, and security teams.
Island enterprise browser provides:
To learn more about the need for an enterprise browser and the capabilities that are provided by Island, read the whitepaper from ESG and discover the bigger truth about modern security and governance in enterprise-level organizations. Click here to see the report.
Cloud growth continues to be nothing short of astonishing: Gartner estimates 95% of new digital workloads will be deployed on cloud-native platforms by 2025, up from just 30% in 2021.
Yet this race to adopt cloud technology has left security teams with an extremely challenging mandate: They need to keep critical assets safe in a world where remote work, BYOD and virtual desktop use are all exploding.
Fortunately, they have no shortage of options. Security concepts such as Zero Trust, and the usual range of data loss prevention, identity management and cloud access security tools, provide a framework for risk management.
However, one urgent risk remains underappreciated: No matter how many security tools you wield, you’re still deeply vulnerable if you continue to use conventional web browsers.
Web browsers have become an essential cog in the wheel of business technology. Many of the productivity applications and SaaS platforms that organizations use today are highly dependent on browsers.
The truth, however, is that they are not truly intended to be used as such. Because they were designed for advertising, tracking and search optimization, they offer minimal control over “the last mile” – the space where users interact with data and applications within the browser.
This means that a user can compromise security through printouts, screen grabs, copying-and-pasting text or even taking a photograph of the screen – and an organization may never realize it because conventional browsers also offer no visibility into how users have acted in the past.
That absence of control is a huge problem – one that organizations have often attempted to address by placing severe restrictions on how workers can use applications or devices. Unfortunately, this is not only ineffective, but it also constrains how businesses operate, and alienates workers.
Fortunately, there is a simple change you can make to avoid this risk: Start managing “the last mile” via an enterprise browser.
Consumer-grade browsers gush data because they don’t allow you to implement security policies. An enterprise-grade browser solves this long standing problem by offering a centralized management console for policy enforcement to govern activities such as downloading, saving, cutting-and-pasting or screen grabs within critical apps.
This gives organizations the ability to give workers much more latitude in terms of how they interact with applications and data.
That’s not the only benefit:
Ultimately, by merging the speed and seamless UX of a consumer-grade browser with last mile controls, the enterprise browser represents an urgently needed innovation – and one of the most exciting new product categories in years.
Read a more in depth editorial brief on this topic by Brian Kenyon, Chief Strategy Officer at Island, by clicking the title: Enterprise Browser Management – The Last Mile Challenge.
We began our journey in enterprise security with a single goal in mind: to build a truly secure-by-design environment. Where work could thrive because security is naturally woven into the enterprise.
So we teamed up with some amazing people. Built anti-malware, DLP, proxies, CASB, firewalls, and many other enterprise security products that became industry standards. Even invented brand new technologies like browser isolation that carved a new path towards a safer enterprise. We were fortunate to build products that truly mattered.
But as the enterprise evolved in ways we couldn’t even imagine, the industry’s approach to securing it stayed more or less the same. An upgrade here. A plus-one there. These improvements were effective. But that’s exactly it - they were merely improvements - on an ecosystem designed years ago for a very different world.
Today, the most precious parts of most organizations live in the cloud. Our employees work in offices, coffee shops, living rooms, and beach chairs. And they use whatever device they want. Let’s face it - even the best versions of yesterday’s security tools weren’t meant to handle the size and scale of today’s modern enterprise. And as long as we were playing by the old rules, that vision of a secure-by-design work environment couldn’t become reality.
The teams we were privileged to lead solved some of the biggest challenges in our industry. Yet, the narrative hadn't changed. And it was becoming painfully obvious why. The one place where basically all our work takes place - where our users, apps, and all underlying data meet - that place was still fundamentally not in our control.
The browser is the one application enterprises use more than any other on planet earth. By far. And yet, ironically, the browser isn’t even an enterprise application. It was built for consumers and advertisers. Optimized for content distribution and consumption. Organizations and employees? They were never part of the picture.
But we knew this already, and we chose the consumer browser for work anyway. Its value to the enterprise was so immense that we ignored the fact that it was built for consumers. We embraced it for its amazing speed, rendering power, universal compatibility, and near flawless user experience. And we learned to live with the tradeoffs - the lack of control, visibility, governance, or privacy - the core elements of a safe work environment.
A reality where the centerpiece of our workplace wasn’t designed for work. Which meant the one place nearly all our critical data lived was the very place we couldn’t protect or even see.
And this reality forced us to treat our browser like a caged animal - surrounding with an endless stack of heavy, expensive, and inefficient tools just to keep it from working against us.
It’s not the browser’s fault. It just wasn’t designed for the enterprise.
It was such a simple question. One that deep down we’ve all wanted to ask. What if there was a browser specifically designed for the enterprise? A browser that put the organization in complete control over how its users, apps, and data interact? A browser that let the enterprise in instead of shutting it out? A browser that integrated into your infrastructure instead of fighting against it?
And suddenly it hit us - That was it. The goal we’ve been working towards our entire careers, right before our eyes.
The ideal enterprise workplace. Security, visibility, and governance built right into the work experience, without getting in the way of work itself.
That vision of secure by design - finally realized.
It seemed almost too obvious. Why hadn’t someone built this yet?
Three stars needed to align for the enterprise browser to seem like a viable idea.
All the pieces were finally in place. The only thing left was to build it. So we did.
The Enterprise Browser fully integrates the browser into the organization, providing complete control and visibility over everywhere work happens. All while delivering the same smooth, powerful, nearly flawless experience users have come to expect. It’s work as it should be - fluid, yet fundamentally secure.
And with it, the possibilities are endless. SaaS and internal web apps truly live anywhere without leaking data everywhere. Contractors and BYOD workers work freely while organizations keep the data they access fully secure. Consumer or risky apps can be safely introduced into the enterprise without compromising security posture. Users are naturally protected from the inherent dangers of the web. And this is all just the beginning.
For years we had one goal - to design the place where work naturally belongs.
Island is that place.
Welcome to the next chapter of enterprise work.
Backed by Insight Partners, Sequoia Capital, Cyberstarts and Stripes, Island delivers a familiar Chromium-based browser experience with built-in critical security control and governance for corporate applications and data
DALLAS and TEL AVIV – Feb. 1, 2022 – Today Island unveiled a new category of enterprise software that revolutionizes security control, visibility and governance with the introduction of the world’s first Enterprise Browser. After almost two years of product development, the company emerged today from stealth mode to introduce the Enterprise Browser, eliminating the massive gaps between current consumer-focused browsers and the increasingly complex IT and security requirements of enterprises worldwide. With core needs of the enterprise naturally embedded within the browser itself, Island is the first browser to provide end-users with the same Chromium-based experience they expect, while giving the enterprise much needed functionality to vastly improve corporate security and employee productivity.
Headquartered in Dallas with research and development in Tel Aviv, Island is led by co-founder and CEO Mike Fey, previously president and COO at Symantec and GM and CTO of McAfee; and co-founder and CTO Dan Amiga, inventor of web isolation technology and previously founder and CTO of Fireglass. Island emerges from stealth with a complete senior management and technical team bringing decades of experience in enterprise security from both successfully established cybersecurity firms and start-ups, as well as deep domain expertise in Chromium research and development.
To date, the company has secured almost $100 million in financing from leading early-stage investors including Insight Partners, Sequoia Capital, Cyberstarts and Stripes and has hired over 100 employees.
“For decades, organizations have globally utilized consumer browsers in the corporate computing environment,” said Mike Fey, co-founder and CEO, Island “These organizations require strong control and governance, which consumer browsers were never built to deliver. Island uniquely provides manageability, control, security and enhanced productivity features from within the browser itself, while users enjoy a familiar browsing experience. We envision the Enterprise Browser fundamentally improving not just security, but enterprise work itself.”
“SaaS has fundamentally changed how IT teams are providing value added services to their companies and the industry is ripe for a new way of thinking about how we secure that value,” said Bob Schuetter, CISO at Ashland Global Holdings, Inc. “A browser built for the enterprise can fundamentally change the industry, empowering us to reimagine how we approach our use cases with tremendous power yet elegant simplicity.”
The Enterprise Browser enables organizations to deeply govern how users interact with all SaaS and internal web applications. Through the use of the Island Enterprise Browser, security teams can fully control last-mile actions from advanced security demands to more basic data exfiltration protections such as copy, paste, download, upload, screenshots and other activities that might expose critical data. This opens up unprecedented opportunities across a growing number of enterprise use cases, including securing critical SaaS and internal web applications from data leakage, safe access for contractors and BYOD workers, and full governance over privileged user accounts. It can also reduce VDI dependency while also supporting built-in safe browsing, web filtering, web isolation, exploit prevention, smart network routing, and Zero Trust access.
“The browser is the office where today’s hybrid workforce lives,” said Dan Amiga, co-founder and CTO, Island, “We have engineered the Enterprise Browser to be the platform for the future of their work. It begins by redefining how an organization secures its work but will positively impact endless needs across information technology.”
“It’s rare that you see a security technology with the potential to reimagine the industry the way Island’s Enterprise Browser does,” said Jeff Horing, Insight Partners co-founder and managing director. “Island has all the attributes we look for in a successful venture – an experienced management team, a brilliant idea and a large market disruption capability.”
Island released and deployed its GA product beginning in September 2021 to some of the world’s most recognizable brands across a range of industries, including several in the Fortune 500.
“When we first saw Island’s design, we immediately recognized the revolutionary impact it could have on securing the workplace,” said Doug Leone, Sequoia global managing partner. “By delivering on the long-standing goal of security by design, we see it as a disruptive solution within the security industry.”
“Our focus at Cyberstarts is to invest in important ideas and people that will change the cybersecurity industry,” said Gili Raanan, Cyberstarts founder and Sequoia general partner. “Island’s Enterprise Browser has the potential to positively impact every part of the space.”
Island, the Enterprise Browser is the ideal enterprise workplace, where work flows freely while remaining fundamentally secure. With the core needs of the enterprise naturally embedded in the browser itself, Island gives organizations complete control, visibility, and governance over the last mile, while delivering the same smooth Chromium-based browser experience users expect. Led by experienced leaders of the enterprise security and browser technology space and backed by leading venture funds -- Insight Partners, Sequoia Capital, Cyberstarts and Stripes -- Island is redefining the future of work for some of the largest, most respected enterprises in the world. Island is based in Dallas with research and development in Tel Aviv, and can be reached at email@example.com or (866) 832 7114.
For more information contact:
Hannah Carroll/Tim Hurley
Matter Communications for Island