BarsUP.AM: how we developed a tool for protecting information of web applications

BarsUp.Access Manager (BarsUp.AM) – our software package for the protection of confidential information. When designing and developing this system in accordance with the requirements of regulatory documents of the FSTEC of Russia, we encountered difficulties in managing access to web applications using certified information security tools.
Order of the FSTEC of Russia No. 17 says that the choice should be made of information protection tools certified for compliance with information security requirements, taking into account their cost, compatibility with information technology and technical means. We looked at what was on the market at that time and understood: the cost of solutions compatible with our information systems often exceeded the cost of the systems themselves, or they were incompatible.

In this case, the controller reports that in the absence of suitable means of information protection, their development (revision) and certification in accordance with the legislation of the Russian Federation or adjustment of design decisions are organized. We decided to develop and certify software in FSTEC of Russia that implements the functions of user identification and authentication, access control and registration of security events for the possibility of its use:

• In automated systems up to security class 1G inclusive according to the requirements of the guidance document “Automated systems. Protection against unauthorized access to information. Classification of automated systems and information protection requirements ”(State Technical Commission of Russia, 1992);
• In state information systems up to and including the first security class, in accordance with the order of the FSTEC of Russia dated February 11, 2013 No. 17 “On approval of requirements for the protection of information not constituting state secrets contained in state information systems” and the methodological document of February 11, 2014 “ Information security measures in state information systems ”;
• In information systems of personal data up to level 1 of security inclusive according to the order of the FSTEC of Russia dated February 18, 2013 No. 21 “On approval of the composition and content of organizational and technical measures to ensure the security of personal data when they are processed in personal data information systems”.

The product is called BarsUP.Access Manager or BarsUP.AM. I will remove issues related to obtaining a decision from the FSTEC and concluding agreements with a testing laboratory and certification body beyond the boundaries of this material, and describe how we developed software for protecting web applications.

Start

We formed a team consisting of a project manager, information security engineer, analyst, software architect, and two leading developers. During the implementation of the project, we identified the following stages of work:

At the analysis stage, requirements were collected from the regulatory documents, which can be implemented by a security tool for the web, then they worked together with the developers on the possibility of their implementation in terms of resources spent and time. When discussing the requirements, we translated the wording from the legal acts into a language that was understandable to analysts and developers, formed a roadmap: what should be implemented in the first place, which is optional. We wrote documentation for certification in parallel and after product development.

At the output, we received a product that solves the following problems:

– providing a single access point (SSO) to information systems;
– identification and authentication of users and devices;
– multifactor authentication;
– identity management;
– access control of subjects of access to information systems;
– registration of security events.
– A flexible password system for managing authentication information of users and devices in software;
– the ability to enter using electronic signature;
– the possibility of multi-factor (two-factor) authentication, using the TOTP algorithm;
– restriction of unsuccessful attempts to enter the software;
– limiting the number of concurrent access sessions for each software user account;
– blocking the access session in the software after the set time of inactivity (inactivity) of the user or at his request;
– the ability to create directories;
– interaction with external directories;
– horizontal scalability of the system due to clustering.

The software supports two standards for implementing single sign-on:

– security assertion markup language (SAML);
– OpenID Connect 1.0.

SAML Single Sign-On Implementation

In accordance with the terms of the SAML standard, the software acts as an identity provider (IdP). IP subsystems act as service providers (SPs).

The general procedure for working with single sign-on via SAML is presented below:

1. The user is trying to implement web access to the application (SP);
2. The application checks for the presence of a security context and, in its absence, generates an AuthnRequest message and redirects the user’s browser to the authorization server BarsUP.AM (IdP);
3. The user connects to the authorization server and enters his credentials;
4. The authorization server identifies, authenticates and authorizes the user;
5. The authorization server redirects the user’s browser back to the application with a Response message;
6. The user again tries to access the application, with the Response parameter. The application checks Response and gives the user access.

The exchange of messages between the parties is in the form of statements SAML (assertions). SAML claims are transmitted using the secure HTTPS protocol.
A trust relationship is established between the IdP identity provider and the SP service providers. Transmitted SAML messages, including AuthRequest and AuthResponse, are signed using SP and IdP digital certificates, respectively.

An AuthRequest message is signed by the application’s private key and delivered to the authorization server using HTTP Redirect, HTTP POST, or HTTP Artifact messages. An AuthRequest message, in particular, contains the following information:

• Application URL
• IdP Identity Provider URL (BarsUP.AM Authorization Server);
• ID and time of request creation.

The AuthnResponse response message is signed with the private key of the authorization server. An AuthnResponse message, in particular, contains the following information:

• AuthRequest request identifier to which this response corresponds;
• Response handler URL
• the period during which the response is considered valid;
• User authentication date and time
• user session identifier;
• user attributes and their values.

Implementing Single Sign-On Based on OpenID Connect

OpenID Connect is an extension designed to provide user authentication and authentication through the OAuth 2.0 protocol.
In the process of implementing single sign-on using OpenID Connect technology, BarsUP.AM acts as an OpenID provider (OpenID Provider, OP). Information systems (i.e., targeted web applications accessed by the user) act as the Relying Party (RP), which uses the OP to authenticate the user.

The implementation of single sign-on via OpenID Connect is described in the figure below:

1. A user is attempting to access a web application (SP);
2. The application generates an Authorization Code Request (OAuth2.0 protocol) and redirects the user’s browser to the authorization server BarsUP.AM (OP);
3. User enters their credentials on OP;
4. The OP authenticates the user in one of the established ways;
5. If successful, the OP asks the user for permission to transmit RP information about him. If yes, returns an Authorization Response message that contains the authorization code;
6. RP checks the response of the OP, and then sends a request for a token (Token Request). In this case, the interaction is carried out using the secure TLS protocol;
7. In case of successful verification of the request for a token, the OP sends RP identification and authorization tokens (ID Token, Access Token);
8. RP checks the token and, if successful, provides access to the user.

Authentication between BarsUP.AM and web applications

To avoid attacks aimed at spoofing the OP or RP, they must mutually authenticate each other.
BarsUP.AM supports the authentication methods defined in the specification for OpenID Connect. The principle of operation of OpenID Connect and OAuth 2.0 is based on the use of identification tokens (ID token) and authorization (access token).

I will provide the implementation of the basic security functions in software:
– Identification and authentication of users;
– access control;
– Registration of security events;

User Authentication and Authentication

Authentication and authentication is implemented in BarsUP.AM based on username and password. The user enters their credentials on the BarsUP.AM authentication web page. In this case, the credentials are transmitted in a secure form via the HTTPS protocol. Access to the target application is allowed only if authentication is successful. Thus, user identification and authentication are realized with remote web access to the IP.
When entering the password, the password is not displayed in the web form and the special is replaced. characters. Due to this, feedback protection is implemented when entering authentication information.
The BarsUP.AM password policy provides for the following settings:
– hashing algorithm;
– ban user name in the password;
– minimum number of digits in the password;
– minimum password length;
– the minimum number of lowercase letters;
– the minimum number of uppercase letters;
– minimum number of special characters;
– length of password history;
– forced password change after a certain period of time;
– minimum number of changed characters in the new password.

BarsUP.AM also supports multi-factor (two-factor) user authentication.

Access control

BarsUP.AM implements automated user account management support and automatic user account lockout.

The administrator can create, modify, delete, block and unblock user accounts at his discretion. User accounts are created by the administrator using the web console of the BarsUP.AM management server. When creating an account, full name, email address, account validity period and, if necessary, other user attributes are indicated. The password is changed by the user at the first login in accordance with the password policy. User accounts can be grouped with specific group attributes and permissions.

The following user account lockout mechanisms are:
– blocking by the administrator;
– blocking at the end of the set period of time for using the account;
– blocking after a period of a specified time of non-use of the account;
– blocking when exceeding unsuccessful login attempts;
– blocking when the number of parallel sessions is exceeded.

The account will be unblocked by the administrator or after the blocking timeout has elapsed (for example, when it is blocked due to exceeding the number of unsuccessful login attempts).

BarsUP.AM implements access control of subjects upon entering the IP. Each user or group of users in BarsUP.AM can be assigned roles and rights. Rights can apply to a specific system or to the entire domain that includes several systems (applications). Information about the role and rights is set by the administrator and is fixed in the form of access attributes.

Security Event Logging

BarsUP.AM implements the collection, recording and storage of information about security events during remote web access to IP. In particular, events related to changing user passwords, setting up and deleting user accounts, changing access control rules and user permissions are recorded.
Security events are logged in the event log. For each event, the date and time, type of event, the affected system, the user associated with the event, and the IP address of the node are recorded. An event logging server is used to store event logs.
Events are divided into categories, including security events and system events. The rights to view the event log are granted to the administrator.
The composition of security events to be recorded can be customized. The definition of security events to be recorded and their storage periods is recorded in the organizational and administrative documents for information protection

Total

The project took us 6 months, excluding the time of testing and the work of the certification body. Now, when implementing projects to ensure the protection of information in information systems, we don’t have a headache, what means to protect web applications.