2024 – DORA and NIS2 time.
The coming year, 2024, will be a period of intensive implementation of the requirements of 2 EU regulations: DORA (Digital Operational Resiliency Act), a regulation for financial institutions, as well as technology providers for them, and NIS2 (Network and Information Systems), a directive covering more than a dozen industries relevant to the economy and society, but also any other companies qualified as at least medium-sized within the meaning of the European Commission’s recommendations.
Both of these documents mention strong authentication, i.e. the use of an additional factor – besides the password – when logging into IT systems to prove our identity. In an effort to comply with the requirements of DORA and NIS2 (which you can learn more about in this special report), organizations have probably already established teams to deal with this issue. And it goes without saying that IT Architects should be members of such teams.
Tasks for IT Architects
The traditional approach to implementing strong authentication is to modify applications, today mainly web-based (browser-based) applications, to extend each of them to require its users to use a second authentication component. This means involving in-house developers and application vendors, making the appropriate modifications, migrations and tests, which takes time and money. And then this functionality has to be maintained and probably expanded – because cybercriminals are constantly devising and using newer and newer techniques to attack user accounts.
To avoid all this work and cost at Secfense, we have developed a solution that allows you to quickly and easily secure all web applications across your organization by adding any second authentication component to them – without having to modify the protected systems in any way. Later in this article, we will describe how it allows Enterprise Architects to incorporate strong authentication as elements of an enterprise-wide IT architecture, Solutions Architects will be armed with knowledge of the functionality of the User Access Security Broker solution, and System Architects will be shown how it works.
Simple implementation of strong authentication
Adding strong authentication to any web application consists of 3 steps, which are performed by IT administrators, and a 4th, which already belongs to the users of secured systems. They are:
1. Installing a broker in the organization’s network. In the form of a virtual appliance, possibly hardware or using a “cloud” service. The broker can, and should, be fully isolated, as it neither sends any diagnostic or statistical information from the company’s internal network nor does it need to receive anything from the outside. To increase the level of availability, spread the load or because of the complex network topology, the broker can work in a cluster.
2. Redirect network traffic from users’ endpoints (their computers, tablets, or smartphones) to servers with applications so that it goes through the broker (or brokers, if we are dealing with a cluster). In the data center, we usually make a simple modification on the load balancers, in the “cloud” architecture we can make an obvious change to the DNS service.
3. Assist the broker during the learning phase of the application. The broker itself recognizes how the secured application has logged its users so far. And a sequence based only on a username and its password expands on the possibility of adding a second authentication component. In detail, it looks as follows:
a. After logging into the broker, the administrator chooses which types of second authentication components to make available to users. It may also force some of them to use a particular type of second factor. At our disposal we have:
- cryptographic key
- fingerprint
- facial contour
- PIN, as a “security output” for the above two biometric methods
- very convenient to use the mobile application Secfense Authenticator
- TOTP codes generated by any Authenticator mobile application
- one-time codes sent via SMS
- one-time codes sent by e-mail
We can also integrate with the company’s existing dedicated authentication systems, as long as they use open RADIUS or OIDC protocols, and thus extend their functionality to all applications in the enterprise.
b) The administrator also decides whether he will still allow users to use the application without having to add a second authentication component for themselves(Soft User enrolment Policy), or whether they will have to do so in order to be able to log into such a secured system(Hard User enrolment Policy).
c) It then launches the learning phase. He goes to the secured application, the banner visible at the bottom that reads “Secfense learning mode” reassures him that the broker is monitoring the login process, and logs in with a user-probe (default: inituser) and any password.
4. Once this is done, the application is secured and ready to accept users. who will select a second authentication component for themselves at the next login, register it, and use it at subsequent system accesses.
The described solution meets all requirements for user-friendliness on the one hand and user safety on the other. It allows flexible policies on the use of the second authentication component, handles the process of helping those who, for example, use a cryptographic key but have forgotten it and need to work, records events in a local log, and sends them to the company’s SIEM system.
Interested?
We are happy to demonstrate the operation of our User Access Security Broker on the applications of interested customers. We will also provide them with a test version to familiarize themselves with its functionality in their own environment.
IT architects are invited to join us at the IT Architects Forum taking place in Warsaw on December 6, 2023, where you will be able to talk to us and ask any questions. You can also do so now by going to our website at: secfense.com.
