Get best of the week

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

image

BarsUp.Access Manager (BarsUp.AM) - our software package for protecting 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 protection tools.

Order of the FSTEC of Russia No. 17 says that there should be a choice 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 regulator 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 the adjustment of design decisions are organized . We decided to develop and certify in FSTEC of Russia software 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);
  • 11 2013 . № 17 « , , » 11 2014 . « »;
  • 1 18 2013 . № 21 « ».

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:

image

At the stage of analysis, we collected requirements from the regulatory documents that can be implemented as a security tool for the web, then we worked together with the developers on the possibility of their implementation in terms of resources spent and time. When discussing the requirements, the language was translated from the normative documents into a language that was understandable to analysts and developers, they 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 tasks:

  • (SSO) ;
  • ;
  • ;
  • ;
  • ;
  • .
  • , ;
  • ;
  • () , TOTP ;
  • ;
  • ;
  • () ;
  • ;
  • ;
  • 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:

image

  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. , ;
  5. Response;
  6. , Response. Response .

The exchange of messages between the parties is in the form of SAML statements (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. Sent SAML messages, including AuthRequest and AuthResponse, are signed using SP and IdP digital certificates, respectively.

An AuthRequest message is signed with 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 identification 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:

image

  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. OP ;
  5. , OP RP . , Authorization Response, ;
  6. RP OP, (Token Request). TLS;
  7. , OP RP (ID Token, Access Token);
  8. RP .

BarsUP.AM web-


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 give the implementation of the basic security functions in software:

  • user identification and authentication;
  • access control;
  • security event logging.

User Authentication and Authentication


Identification 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 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 password;
  • minimum number of digits in a password;
  • minimum password length;
  • minimum number of lower case letters;
  • minimum number of uppercase letters;
  • minimum number of special characters;
  • password history length;
  • forced password change after a certain period of time;
  • The minimum number of characters changed 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, the name, e-mail 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:

  • administrator blocking;
  • 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 concurrent 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 failed 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, the type of event, the affected system, the user associated with the event, and the IP address of the node are recorded. The 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, how to protect web applications.

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles