Have Questions?

Two-factor authentication is widely spread across many verticals. All individuals and organizations that value secure user authentication and device trust usually pick strong 2FA as the best addition to traditional passwords and logins. Two-factor authentication is often used and advised by security influencers, industry experts, security teams and IT teams within organizations. The usual barrier is either people’s resistance to change, second to that is a barrier in adopting the technology to the existing infrastructure. The list below shows the top five industries where 2FA is a essential in maintaining user authentication security:

• Healthcare: Medical information is incredibly sensitive, in case of a breach, information can be instantly identified and matched with a specific person. Hospitals and other healthcare organizations, often fall victim to phishing attacks because cybercriminals know how valuable information they can steal. Two-factor authentication is therefore used to protect personal accounts (patients, doctors and administration). One of the directives that calls medical organizations to use strong 2FA is HIPAA (Health Insurance Portability and Accountability Act). To be HIPAA compliant medical institutions need to adopt strong authentication mechanisms to protect sensitive data.
• Financial Services: Financial institutions use two-factor authentication to protect against data breaches as well as comply with the growing security requirements on national and international level. The best example of such directives is PSD2 (Payment Services Directive) administered by the European Commission to regulate payment services within the European Union and European Economic Area.
• Government & Public Sector: Government institutions and organizations that belong to a public sector are under constant risk of cyber attacks. In response to that, organizations responsible for public sector data and IT infrastructure implement two-factor authentication as an addition to traditional password protection. With strong 2FA, a cybercriminal would need to steal the person’s device to get access to data, even if his or her password leaks or gets stolen.
• Education: Educational institutions regardless if they are elementary schools, universities or private learning organizations implement two-factor authentication to protect the data of their students and teaching personnel. Students, teachers, and administration access sensitive information on the web with strong 2FA in addition to the traditional logins and passwords.

Two-factor authentication protects against phishing, credential theft, social engineering and brute-force attacks. 2FA also secures the login process from attacks that exploit weak or stolen passwords. This significantly improves the whole login process security. Two-factor authentication als proved to be able to successfully deter automated bot attacks. According to Verizon 2018 Data Breach Investigations Report around 81% of confirmed data breaches involved stolen credentials.

At Secfense we are strong ambassadors of FIDO2, so the open web authentication standard also known as WebAuthn. FIDO2 takes advantage of local devices with biometric authentication to be used in the authentication process. So the person can take advantage of the FIDO2 mechanism when login to the service using fingerprint recognition on the mobile phone or laptop touchpad. U2F keys (so the ancestor of FIDO2 standard) has been chosen by Google corporation as a tool to protect all employees accounts. Since 2017, when the standard has been deployed there hasn’t been any successful phishing attack registered on Google employee. User Access Security Broker from Secfense helps organizations adopt and scale the same technology that Google corporation picked as their authentication standard. With Secfense UASB the organization does not need to have Google’s security budget to be able to take advantage of the strongest authentication standard there is.

It’s complicated. Or at least it can be complicated if you think about the traditional deployment model when 2FA needs to be tied with the protected application and there’s coding involved. Some applications are easy to upgrade with 2FA some applications however require long and expensive software development work, or sometimes are even impossible to upgrade. This often happens with legacy apps, administrator panels or applications that due to vendor lock-ins have long and complicated maintenance cycles. User Access Security Broker from Secfense solves this problem and makes it possible to use 2FA on any web application regardless of how complicated client infrastructure is. User Access Security Broker from Secfense works as an intermediary security layer and can be spread between applications and users within minutes (and in case of scaling 2FA in the entire organization) within just days.

So with Secfense the answer is no longer complicated. It can be done.

2FA works when a person has the authentication device with him or her in the moment of authentication. If that device is lost or damaged it can cause the loss of access forever. That is it is important to plan well and mix authentication methods or in case of choosing FIDO2 authentication standard register more FIDO2 keys and keep them in a safe place in case the main key is lost or physically damaged.

Mixing methods (like FIDO2 and TOTP) is a good way to prevent the permanent loss of data. Let’s say that the person had only one FIDO2 device registered and this device got damaged or lost. In such a case a person can still take advantage of another 2FA method that he or she registered. In our case TOTP and an authentication app. The best authentication policy should be chosen by a security manager inside the company as that person knows best the company culture, company security awareness and can adjust authentication security requirements to that specific company’s environment.

Of course. Actually, you can do much more. With microauthorizations you can not only equip each single application with strong two-factor authentication but you can also add authentication requirements on any step of user journey within the application itself. This means that authentication requests can be triggered at any stage and any time. It all depends on the company policy and authentication rules designed by security admin. User Access Security Broker from Secfense makes it possible to install any 2FA method on any application one by one.

Microauthorizations from Secfense allow security administrators to add rules that will trigger extra authentication requirements at any time and at any space where it is necessary.

Yes. These are microauthorizations, so the mechanisms or that trigger special rules that require a person to confirm his or her identity again within the specified application even though that he or she logged in before successfully with the use of 2FA. This is an extra security layer especially useful when there are some specific areas within the application and database that should trigger a special warning when accessed. A good example of microauthorizations in use is the protection of CRM against mass export. In a normal scenario any person with access rights can access CRM and export all the leads and customer data. With microauthorizations each single export would need to be confirmed with tapping on the security key. This behavior would also be tracked, monitored and registered by the security admin within the company.

A user access policy is a set of rules that determines if a person can access a specific application. Bigger organizations usually have policies that allow only certain users with a specific level of security clearance access critical data. A proper two-factor authentication solution makes it possible for administrators to set up access rules and ensure that only the assigned people, with the assigned devices and credentials can access specific applications.

Some applications require stricter authentication rules than others, as well as some devices are more trustworthy than others. That is why security managers need to consider these factors when designing access policies for a specific organization.

Applications that contain sensitive information may require a person to authenticate with multiple factors while collaboration tools like calendars may be accessible with two authentication factors or may even be accessible only with a password if there’s no critical data stored in there.

User access security broker is a solution built by the Secfense company that enables a set of multi-factor authentication methods (SMS, TOTP, FIDO2/WebAuthn, etc.) on any web application. The tool works as a reverse-proxy and the deployment does not require any software development. The implementation requires setting up a virtual machine within an organization and then configuration requires redirecting the traffic (reverse-proxy) and applying learning mechanisms so the tool can learn the traffic patterns and then trigger 2FA authentication mechanisms. The whole deployment and configuration is done in a day and can be easily scaled to all the apps across the organization. The tool works as a reverse-proxy and is independent of the technology stack.

User Access Security Broker from Secfense in big simplification is a form of a security layer. It works as a reverse-proxy that sits between any internal application and the external user. Secfense UASB is also an enterprise service bus (ESB) for security modules such as two-factor authentication (2FA). Each 2FA method is completely independent of the protected application. This means that it can be exchanged instantly without affecting the application workflow.

Secfense UASB has two main goals:
1. Making the authentication process resistant to phishing
2. Adding customizable authorization steps wherever it’s necessary (microauthorizations)

• The tool is installed as a virtual appliance in the customers’ infrastructure and from that moment it is completely owned by the customer. The User Access Security Broker from Secfense is not a SaaS product and it doesn’t touch any user sensitive data.
• the setup of the User Access Security Broker from Secfense takes minutes and can be easily repeated on any number of web applications
• there is no interference with the protected application code

The User Access Security Broker from Secfense usually comes where it’s too hard to introduce SSO – legacy, custom-tailored apps, admin panels etc.

Get the right numbers

Two-factor authentication technology was designed to protect against the growing risks of cybersecurity attacks globally.

• According to the Mimecast report one in 61 emails in your inbox now contains a malicious link.
• Threat intelligence company PhishLabs reports that US companies fell victim of over 80% of all phishing attacks.
• Data Breach Investigations Report from Verizon says that more than 80% of security breaches came from phishing and credential theft.
• Microsoft in its Security Intelligence Report claims that phishing attacks keep increasing while malware declines.

Convince your stakeholders

Introducing two-factor authentication inside the organization requires convincing the decision makers that are usually selected by a group of people within the company. Such groups can be formed by C-level executives, security professionals, IT teams, or anyone who has some authority in bringing new technologies to the company. It is critical to understand who makes these decisions and work with them to push forward the change.

Communicate the threats and benefits: once you short-listed the stakeholders, who decide about the organization’s security strategy, highlight what is important to each individual. Different arguments are necessary to convince the company’s CEO and different arguments will convince the CIO or CISO.

Knowing what is important to each decision maker is the key ingredient to move forward with a new authentication policy and shift 2FA adoption paradigm.

The deployment

Introducing strong two-factor authentication inside the organization can face different lines of the resistance. From security awareness, through costs, to fear of difficult adoption and complications that it can cause. You need to have arguments that will help you convince the decision makers that all these doubts and obstacles can be easily addressed and should not be treated as deal breakers.

Strong two-factor authentication has helped organizations across many industries secure their user endpoints. Unfortunately you only hear about breaches and successful cyberattacks that happened and information about them leaked. You will rarely hear about companies successfully preventing attacks with strong authentication mechanisms because such news doesn’t land on the front pages.

There is however great case study that is always worth bringing out as the scale is huge and the company is known to everyone. Here’s an article about how strong two-factor authentication helped Google corporation protect its 85k employees from account attacks and completely eradicated phishing. Since Google corp. started using strong U2F based authentication (U2F is the pre-ancestor of FIDO2) they haven’t been successfully compromised since then.

A reverse proxy server is a type of proxy server. Unlike a traditional proxy which is used to protect clients, a reverse proxy is used to protect servers. A reverse proxy is a server that accepts a request from a client, forwards the request to another of many other servers, and returns the results from the server that actually processed the request to the client as if the proxy had processed the request itself. The client only communicates directly with the reverse proxy and does not know that some other server actually processed its request.

Single Sign-On (SSO) is a system that allows users to access multiple applications with a single set of login credentials. SSO reduces the need for users to remember different login credentials for each application, as it provides a single point of authentication for accessing multiple resources.

An identity provider is an entity that stores and authenticates the identity used by users to log into their devices, applications, file servers, and more, depending on configuration. In general, most identity providers are either Microsoft Active Directory (AD) or OpenLDAP implementations.

Identity and Access Management (IAM) ensures that the right people and roles in your organization have access to the tools they need to do their jobs. Identity and access management systems enable an organization to manage employee applications without logging into each application as an administrator.

SAML is an open standard for the exchange of credentials and authorization data between an identity provider and a service provider. SAML is the most commonly used way to implement single sign-on (SSO).

OpenID Connect (OIDC) is like SAML, an authentication protocol commonly used to implement single sign-on (SSO).

While both SAML and OIDC are most commonly used to implement single sign-on (SSO), there is a difference in their implementation approach. While SAML doesn’t pair well with some apps (e.g. mobile apps), OpenID works well with both web and mobile apps. SAML, however, is a protocol that has already appeared in 2005 and also due to this time it is a protocol many times more popular than OIDC.

Identity as a Service (IDaaS) includes cloud-based Identity and Access Management (IAM) solutions. In the IDaaS model, identity and access services are provided over the Internet by a third-party provider, not deployed locally.

Authentication as a Service (AaaS) is a cloud-based authentication service that allows organizations to securely control access to their applications and servers from a variety of devices and networks.

For single sign-on (SSO), typically the “service provider” is the entity that receives the SSO token and then queries the “identity provider” to verify the token and establish the logged-in user’s identity before providing the requested business services

Lightweight Directory Access Protocol (LDAP) is an open and cross-platform protocol used to authenticate directory services such as Active Directory (AD). LDAP provides communication between the application and directory service servers. Directory services store data about user accounts and share that information with other entities on the network.

Active Directory is a directory service developed by Microsoft. Active Directory stores information about objects on the network and makes it easy for administrators to centrally manage user accounts and users to log in and access their resources.

Corporate Service Bus (ESB) is a type of software platform known as middleware that runs in the background to aid communication between applications. An ESB is a type of bus that receives information from one system and delivers it to another.

Secfense was founded by the people who worked in cyber security for more than two decades. Both on the client side and the vendor side. We’ve designed our core product called the User Access Security Broker thinking about all the cybersecurity specialists who are very skeptical about new technologies, reluctant to SaaS. We are aware that the reluctance to SaaS is justified. SaaS solutions are difficult to control in the context of data that the company has to share with the supplier.

Secfense solution hands over an appliance that “doesn’t call home” (an idiom that says that there is no central management at the manufacturer). Secfense security broker becomes a part of client infrastructure, just like other network devices such as load balancers, WAFs, etc.

It’s also important to mention that the Secfense solution does not touch the application code. An analyzed traffic remains on the device and is never analyzed in the cloud.

Another important thing is that we never process or store any credentials or passwords. Despite the fact that in terms of architecture, Secfense User Access Security Broker stands in a position in which it has the opportunity to see all the traffic (including passwords), we consciously do not process them as they are not necessary for our solution to work.

If you would like to see how the deployment process looks like in real live you can check this 7-minute video where we show the whole installation of Secfense solution. This is a step by step process that security administrators on the client site can repeat on any application inside the organization.

You can also schedule a discovery call here and learn how to register for a free trial.

The User Access Security Broker from Secfense is a security layer that is designed to deal with user-oriented security of any web application without any change in the application code.

The main benefits of introducing a user access security broker are:

• increasing the level of security of the authentication process
• adding customizable authorization steps wherever it’s necessary
• making it possible to create unified security policies for the entire organization easily

Because managing a variety of security policies, different for each application, makes it hard or even impossible to manage and control.

Secfense fights with complexity and inefficiency. In large organizations, there are still hundreds of applications that authenticate users only against their passwords and this may often cause a lot of security problems. It wasn’t possible before to protect them all with 2FA due to the huge costs of software development and further maintenance. 2FA was introduced to 1 app and there’s still 99 that could cause a potential security breach. Secfense changes that.

Secfense completely eliminates the risk of phishing and the risk of theft of user credentials. With Secfense, two-factor authentication can be easily implemented in any application and in just a few minutes. Therefore, organizations no longer have to make difficult decisions which applications should be protected with strong authentication and which should only be left with password protection. Now you can introduce any 2FA method to all your applications and protect your entire organization with strong phishing-proof authentication.

The Secfense solution is, to a great extent, a form of a security layer. It acts as a reverse-proxy that sits between any application and the user.

The Secfense User Access Security Broker is also an Enterprise Service Bus (ESB) for security modules such as two-factor authentication. Each 2FA method introduced with the Secfense broker is completely independent of the protected applications. This means that the chosen method of strong authentication can be freely changed without affecting the application.

Two-factor authentication is really easy to set up with User Access Security Broker from Secfense. These are the steps to launching strong 2FA within your organization. Administrator setup:

• Install Secfense UASB virtual machine
• Redirect network traffic through Secfense UASB (reverse-proxy)
• Apply learning mechanisms that learn traffic patterns
• Register ‘test user’ to teach Secfense UASB authentication patterns
• Done. Any end-user will be forced to use 2FA now to login to this specific application

End-user setup:

• Login to the application as usual
• The registration window will pop up forcing person to add 2FA method
• Next time the person logs in he or she will be asked to authenticate with 2FA

Our full User Access Security Broker Enrollment is requested on demand and can be provided after setting up a discovery call here

The entire integration of User Access Security Broker with applications closes in a few steps:

Step 1:

creating a virtual host for the application in Secfense (DNS name and current application IP are defined)

Step 2:

network traffic to the application is directed by reverse proxy Secfense UASB (this action takes place outside Secfense UASB and is performed by network administrators) – now Secfense UASB proxies traffic but does nothing with it, it behaves completely passively

Step 3:

Learning stage – an attempt to log into the application with an ‘inituser’ – a user understood only by Secfense UASB (‘the learning stage’ is described below).

Step 4:

This is the end of integration. A pattern for a given application is created in Secfense UASB, which is simply applied and from now on users will be required to use the 2FA. Two-factor authentication methods in Secfense UASB can be assigned per application to all users or selected user group.

Learning stage:

At the deployment stage of Secfense UASB, the unique user “inituser” is sent to the application. There is no such user in the application but we receive a response from both the frontend and backend of the application that allows us to identify the login process and handle it on the fly.

Then learning is then turned off and the pattern created in this way is remembered by Secfense UASB.

All depends on the 2FA method that was selected. In some cases the lockout is easier to fix and the person can regain access to the account faster. In other situations this may require the use of another device that was initially registered as an alternative authentication method.

For example if a person uses a U2F security key he or she should have the other key previously registered that could be used in such an occasion. In the situation of losing a mobile device with an authentication application there should be another device that generates TOTP registration.

Two-factor authentication is the best way to protect against phishing and increase overall organization’s security however it also needs to be well established within the company to minimize lockout consequences.

That’s why it’s critically important for security administrators to have always alternative authenticators in place to prevent organization’s employees from getting locked out completely and lose application access forever.

Yes, it’s not only possible but also strongly advised. Since strong 2FA can cause a person to get locked out forever it is incredibly important to have various U2F security keys, FIDO2 keys, or mobile devices with authentication apps registered in case of breaking or losing one of the devices.

It’s safe to say that VPN (especially protected with password only) is not very secure. Traditional network perimeter has evolved and according to the Zero Trust Model we need to abandon the “idea of a trusted network”.Instead, it’s better to rely on a strongly authenticated user (with 2FA). This is where Secfense can help. It can be either applied to SSL-VPN as an extra layer of security or become a replacement – security broker that will keep the bad guys off and let only the legitimate users in.

Secfense solution does not store passwords. The User Access Security Broker from Secfense does not need to process and store user passwords to operate. Application authentication remains intact and the Secfense broker works “above it”.

We shift the paradigm of implementation of 2FA. With Secfense 2FA is no longer the domain of software, but rather the network. Instead of tying each app individually to the selected 2FA method – which is time and money consuming and requires development efforts, you just reroute the web traffic throughout our proxy – which is as simple as changing DNS entry or a firewall rule.

The User Access Security Broker from Secfense is independent of authentication methods. This means that it is possible to use any authentication method available on the market.

Secfense solution allows you to run any strong authentication method. The method is selected by the administrator on the client’s side and configured according to the security policy of a given company.

Secfense recommends using the FIDO-based method as this authentication standard completely eliminates the problem of phishing. However, other two-factor authentication methods such as TOTP (compatible with Google Authenticator), an SMS-based method, as well as older token-based methods or biometric authentication with voice and face can also be used with the Secfense broker.

Due to the sensitive nature of the data flowing through Secfense most of our customers prefer on-prem deployments, either as a physical or virtual appliance. In the near future, we plan to extend the offering to SaaS.

Strong authentication based on the FIDO standard (also known as WebAuthn) is one of the safest and most effective ways to use 2FA. FIDO authentication has been battle-tested by giants such as Google corporation, Facebook or Twitter and is currently the only 2FA method that is fully phishing resistant. The solution works out of the box in most environments and is easy to use and manage.

FIDO keys rely on public key cryptography but without the problematic infrastructure of legacy PKI systems. The FIDO method based on local authentication devices uses devices such as a smartphone or a laptop instead of keys, serving the user to confirm his or her identity.

If you already use 2FA to protect your most sensitive applications, you can still use Secfense in one of two scenarios:
– seamlessly extend existing methods to other apps
– seamlessly replace legacy with state-of-the-art methods for the selected app or user base.

During the phase called “self-learning” Secfense probes the target application to gain knowledge on how it’s built. After performing the pattern analysis on both backend and the frontend, Secfense issues custom-tailored protection for the selected application.

Secfense supports all keys compliant with the FIDO standard (formerly the U2F standard). It is up to the customer to choose which key supplier to choose.

Yes. Secfense can either use your existing SSL certificates or generate new ones for you. It can also hide behind your SSL-terminating device and make consume unencrypted traffic.

HTTP/HTTPS and SSH

You can start with a single cluster for high-availability and add more nodes if necessary. Additional nodes can be span between your own datacenter, private and public cloud.

Yes. High availability is provided by the redundant nodes of a cluster.

As a first step, it is important to schedule a discovery call with us, which you can schedule here.

During this 30-minute conversation, we usually show a demo of the Secfense solution and perform its full installation on the example of a working external application, the code of which we do not control. You can see the demo during the conversation, or the previously recorded demo at this link.

After watching the demo, we usually go with the Q&A round, which aims to find specific cases (cases) on the client’s side where Secfense could help.

If the client sees the potential in the solution and is willing to test the solution on his infrastructure, we sign the NDA and run a demo version of our virtual machine to run in the client’s test environment. After selecting the application for testing, the administrator on the client side redirects traffic between the testing users and the application (most often by changing DNS entries or firewall rules).

Secfense solution testing is free of charge and simply limited to the number of applications and users (trial version) on which strong two-factor authentication can be run.

Yes. If the application is publicly available on the Internet, we can secure it with the User Access Security Broker from Secfense and demonstrate all functions without having to make any changes to the protected application. In this link there is a demo that was shown to the public at the Finovate conference on the example of the Amazon.com application. The same demo can be run on any other application. So you can make an appointment with us and in the contact form indicate the site on which we should install the Secfense solution during our call.

Yes. With Secfense SSH gateway we can carry out the “good” man-in-the-middle attack on your infrastructure in order to apply additional security measures (such as multi-factor authentication) on your users’ SSH sessions.

This question comes up frequently and in various forms. During our live demonstration where we show 2FA implementation using the example of Amazon.com , we locally change the DNS entry and make the traffic flow through our network. During the demo, of course, this only has the right to run on our laptop, as we do not control the Amazon app. The purpose of the demonstration is therefore only to show that we can implement 2FA without touching the application code. When Secfense User Access Broker is deployed in a real environment, it is close to the load balancer or WAF.

If the client controls the DNS of the application, Secfense can be deployed on those applications. Think of the Secfense security broker as Cloudflare for 2FA.

At this stage we’re focused on applications owned by the company, so currently we don’t support SaaS products. But we’re working on expanding Secfense operations to SaaS environment, though.

Being a multi-factor authentication method enabler means that we activate any 2FA method to any web application. We are not a producer of 2FA methods, but we integrate them on our platform making it available for every web application that Secfense sees on the web. That means that if you are currently using some specific 2FA method in your organization, attaching it to the Secfense integration bus will make it the next method to choose and deliver to the application on the fly, at the network layer.

Secfense was designed for web-based applications as it leverages the standards both on the protocol level as well as on the client side (browser). It might be deployed for some mobile environments, but that requires some extra support.

The Secfense solution is delivered to the customer in the form of a physical or virtual device. The solution is placed between users and applications in such a way that it can analyze and modify HTTP(s) traffic – usually near a load balancer or firewall. Depending on the client’s preferences, the Secfense security broker can act as a TLS termination proxy or work on already decrypted traffic.

Due to the confidentiality of transmitted data, Secfense solution never communicates with external hosts or “calls home” for reporting purposes.

Secfense installation options:

Or what exactly does the traffic inspection and application learning phase look like? In the learning phase, Secfense solution runs a probe on the target application to scan for requests (and responses) related to user authentication. In this step, both network traffic patterns and user interface patterns are collected.

In most cases, the learning process is automatic and takes just several seconds. In rare cases, where patterns are not recognized automatically, the administrator performs manual tuning.

After applying the previously learned pattern, the application becomes instantly protected by the selected 2FA method. During the next login, application users will be prompted to activate the 2FA component.

This is possible by intercepting requests at the user interface level and blocking unauthorized traffic in the HTTP(s) layer.

The user remains in the domain of the protected application (no redirection to an external service), and the 2FA registration/use process seems to be an integral part of the protected application.

This mechanism works for both traditional applications (where the HTML code is rendered completely on the server side), as well as the so-called SPA (Single-Page Apps).

Here is a link to our 7-minute demo that we showed at the Finovate Europe conference in London. The demo shows what the entire implementation of the User Access Security Broker from Secfense looks like and the launch of two-factor authentication. The demo was shown on the example of Amazon.com, but in practice it can be shown on any other web application. When arranging a conversation with us in the registration form, you can select the application on which we should run the demo , and we will show how the Secfense broker works on this application.

The learning stage is a one-time process designed to teach Secfense the characteristics of the web application, which will be protected by 2FA methods.

The entire Secfense integration with applications closes in a few steps:

Step 1: create a virtual host for the application in Secfense (DNS name and current application IP are defined)

Step 2: network traffic to the application is directed by rev-proxy Secfense (this action is outside Secfense, performed by the network administrators) – now Secfense sees the traffic but still does nothing with it, behaves completely passively.

Step 3: Learning process – in this stage the admin should try to log into the application with a special username that is’ understood’ only by the Secfense broker. The special probe username provides Secfense solution with knowledge about the target application.

This is the end of integration. In Secfense broker, a pattern is created for a given application, which is enough to apply and authentication using the second component will be required. 2FA methods in the Secfense broker can be assigned to all or selected users.

Here is a link to our 7-minute demo that we showed at the Finovate Europe conference in London. The demo shows what the entire implementation of the User Access Security Broker from Secfense looks like and the launch of two-factor authentication. The demo was shown on the example of Amazon.com, but in practice it can be shown on any other web application. When arranging a conversation with us in the registration form, you can select the application on which we should run the demo , and we will show how the Secfense broker works on this application.

No. In the unlikely event of a failure, it can be easily disabled without disruption of a target application.

One of the crucial functionalities of Secfense broker are microauthorizations. This functionality makes it possible to stop the user when he or she reaches for some specific resources or wants to perform some specific actions in the protected application.

In such a case, Secfense takes over communication and triggers one of two scenarios:
1. In the Owner Scenario, Secfense asks the user to re-authenticate
2. In the Supervisor Scenario, Secfense asks the third party for authorization

Since Secfense, as described above, works as an intermediate security layer, so microauthorizations can be added inside of the application anywhere, and it only takes minutes to deploy.

Microauthorizations (in the Owner Scenario) introduce an increased level of granulation under the Principle of Least Privilege. This means additional protection against attack on a stolen active session or other attacks against an already logged-in user (including real-time phishing or malware).

Microauthorizations (in the Supervisor scenario) leave authorization of particularly sensitive resources requests in the hands of selected and trusted users.

Regardless of the scenario, the additional effect of microauthorizations is the protection of sensitive resources against risks such as:

• automatic export (with or without the consent of the user)
• uncontrolled leakage of confidential data through the application interface

MICROAUTHORIZATIONS ONLY MAKE SENSE WHEN THEY ARE EFFORTLESS FOR THE USER.

That is why the best tool to include in microauthorizations are U2F / FIDO2 cryptographic keys or local authenticators compliant with the WebAuthn standard. The 2FA methods based on one-time codes (SMS, TOTP) will not work because of too much user involvement in the process.

In the case of the Owner Scenario, the access to the protected resource requires the user to simply touch the cryptographic key that was used during the authentication.

In the case of Supervisor Scenario, access to the protected resource requires the same action as above but needs to be performed by the privileged user with a privileged cryptographic key.

ALL EVENTS RELATED TO MICROAUTHORIZATIONS ARE LOGGED IN THE SECFENSE EVENT LOG (OR STREAMED TO AN EXTERNAL LOGIN SYSTEM) AND CAN BE ANALYZED TO DETECT ANOMALIES.

More on micro-authorization can be found below:

• Website dedicated to microauthorizations
• A brief introduction to microauthorization with Secfense
• See microauthorizations in action

The User Access Security Broker from Secfense analyzes both network traffic and front-end events. For a given application, the default 2FA method (cryptographic keys, TOTP codes, biometrics, etc.) is selected and placed between the user and the target application.

Regardless of the 2FA method, there are two processes: the registration process and the authentication process. In the registration process, we associate the attribute of the second component with a given account in the system (i.e. in the case of SMS codes, the user provides the telephone number and then enters the start code from the SMS). At the next login attempt, Secfense solution already knows the relationship of the user with the given attribute of the second component, performing its part of the task, and expects the correct code from the user. In the linked video, from around the 2-minute of the video, we have shown how this process works for cryptographic keys of the FIDO U2F standard (registration in the first step, and then authentication in the next steps).

User Access Security Broker from Secfense “covers” the applications without making it dependent. Thanks to this, in the event of an unforeseen failure, the Secfense broker can be bypassed by changing the traffic (DNS, firewall, routing) until stability is restored. During this time, the application returns to its pre-deployment state, and the 2nd factor is no longer required when logging in. In the physical appliance version, the Secfense solution is delivered in a high availability model. In the case of a virtual appliance, HA is transferred to the virtualization environment.

The SLA level is related to the response time to the reported problem, in existing installations it usually takes several hours (when the customer decides to use network traffic bypass on his side).

Yes. In the case of installing the trial version and willingness to test the Secfense solution on the client’s applications, we provide the Secfense broker version in OVA format, and then help in launching and testing the selected application. To register for a free solution test, schedule a discovery call with us here to determine the details of the trial implementation.

Absolutely not.

Exactly, the Secfense solution is a broker (enabler) that allows you to implement any 2FA method on any application. We are not a producer or vendor of 2FA methods. We integrate them on our platform, making them available for every application that the Secfense solution sees on the web.

If you currently use a specific 2FA method in your organization, plugging it on the Secfense integration bus will make it another method to select and deliver to the application on the fly, in the network layer.

The pictures below show well the possible scenarios for implementing the Secfense solution in the IT infrastructure:

No. It is not a separate application. The learning stage in the Secfense solution is a one-time process aimed to teach the Secfense broker the characteristics of the web application itself. Secfense solution learns in this way the application that will be protected by the 2FA authentication. The entire integration of the Secfense solution is executed in a few steps:

Step 1: Create a virtual host for the application in the Secfense broker (DNS name and current IP of the application are defined).

Step 2: Web traffic to the app is routed through the Secfense reverse proxy. This activity outside of the Secfense broker is performed by network administrators. Now the Secfense broker proxies traffic, but does nothing with it yet. It behaves completely passively.

Step 3: Learning stage – an attempt to log into the application with the ‘Inituser’ user. A special user that is understood only by Secfense solution – the process is described below. This is the end of integration.

In the Secfense broker, a pattern for a given application is created. In the next step the pattern is applied and from now on, the second factor will be required for the users to activate whenever they attempt to log in. 2FA methods in the Secfense solution can be assigned per application for all or selected users.

The learning stage:

At the stage of securing the Secfense solution, the unique user “Inituser” is sent to the application. Such a user does not exist in the application, it is used only to initiate the learning process. Thanks to it, we receive a response from both the front-end and back-end of the application, and this allows us to identify the login process and handle it on the fly.

Then the learning stage is turned off and the pattern created in this way is remembered by the Secfense broker.

Here is a link to our 7-minutedemo, which we showed at the Finovate Europe conference in London. The demo shows what the whole process of implementing Secfense User Access Security Broker and then launching two-factor authentication looks like. The demo is made on the example of the Amazon.com application, but in practice it can be performed on any other application. When scheduling a discovery call with us in the registration form, you can add the link to the application on which we should perform the demo, and we will show how the Secfense solution works on this application.

The majority of our customers require that the applications we protect with Secfense broker have user authentication via SSO.

SSO is a very important piece of the puzzle, and wherever possible, we encourage customers to tie their infrastructure together in this way. It is then important that the system that verifies the identity of users has implemented two-factor authentication. If it is not there, you can “hide” it behind Secfense. Our experience also shows that only selected applications are connected to the SSO. In this case, we solve the problem of all the other applications that are left without SSO. It is also worth remembering that the Secfense solution provides security service also for already logged in users (so-called microauthorizations), thus entering the territory of PAM (privileged user access management) for web applications.

PAM (Privileged Access Management) is a solution that focuses on the group of privileged users (hence privileged access), and does not deal with ordinary users. PAM solution addresses a small group of users in an organization, leaving a large group of ordinary users without additional protection. The User Access security Broker from Secfense is therefore a good addition to corporate security and the protection of user accounts that are not covered by PAM.

There is a small confusion that we often need to clarify when talking to clients. Secfense User Access Security Broker does not overwrite DNS servers for client stations (or anything else), but only the A record for the application that Secfense is supposed to protect. If so far, e.g. the CRM application had an A record pointing directly to the web / application server, it should be changed to point to the Secfense broker. Then the users connecting to the CRM will transparently “pass” through the reverse-proxy server in the form of Secfense broker. Such solutions are widely used in both cloud-based anti-DDoS systems and in-house application firewalls.

User Access Security Broker from Secfense is a more flexible alternative to SSL. When using a VPN, the user cannot see the app at all until they have passed the VPN gateways. Thanks to the Secfense broker, the protection is transparent, the user will be asked to enter the second authentication factor when trying to log in, but can navigate through the public page of the application without logging in as well. One of the most significant advantages of using the Secfense solution over a VPN is that the Secfense broker also protects users from within the organization.

High availability is ensured by a cluster of two Secfense broker’s nodes, which are stateless on the one hand and fully aware of their presence on the other. Traffic between users and applications is routed through such a high availability (HA) cluster.