Key Concepts and Terms

The Security Module defines the Users allowed to use or modify solution, and their Roles, Permission, and Security Policies. The definition of users can be created locally using the platform tools or executed in connection with external definitions such as Active Directory, LDAP servers, or external SQL databases.

Users

Anyone accessing the solution, either in engineering (Designer Tool) or in runtime mode (Displays).

Permissions

Permissions are set levels of access for each user that determine what they can or cannot do within the solution.

Policies

Policies manage requirements on User Identification and Session Control.

RuntimeUsers

These users are created and retrieved from an external encrypted SQL database or other identification servers.

Understanding the Security Module

What the Security Module Enables

User roles management

Managing user roles involves assigning a role to each user that defines their level of access to various components of the solution. Each role has its permissions, which can be customized to meet the security requirements of your organization.

Managing External Users (Runtime Users)

External Users in this context refers to users who are not part of the organization but need access to specific components of the project. This can include contractors, clients, or third-party vendors. These users are typically managed via RuntimeUsers or integration with Active Directory and LDAP.

Securing Solution Configuration

The platform provides several tools to secure the solution configuration itself.  By assigning Permissions and Policies, administrators can control which users have access to specific modules, editors and documents. This ensures that only authorized users can make changes on each part the solution configuration.

Securing Runtime Execution

Securing runtime involves managing user sessions in client displays by setting password requirements, session restrictions, and e-signature settings. The platform allows administrators to monitor client connections and manage active sessions.

Users, Permissions and Policies Summary

For a summary of the Security Configuration, go to Security OverviewModule (How-to Guide), which presents the basic configuration steps and properties for Users, Permission and Policies. 

The next section presents the configuration of those elements in further details.

Configuring the Security Module

The Security Module defines the Users allowed to use or modify solution, and their Roles, Permission, and Security Policies. The definition of users can be created locally using the platform tools or executed in connection with external definitions such as Active Directory, LDAP servers, or external SQL databases.

Configuration Workflow

Each User is assigned to a set of Permissions and a to a Session Policy.

RuntimeUsers

Runtime Users are either defined in an external database or created dynamically using the CreateUser method. They can log in and use remote operation displays similarly to users specified in the solution configuration.

→ Read more about RuntimeUsers.

AD/LDAP Integrations

Windows AD Integration

The platform can automatically execute user credentials validation and user connection identification using native Windows Active Directory integration, available for users connecting from Windows operating systems.

→ Read more about Windows AD / LDAP Server.

AD/LDAP Server Integration

When Windows AD integration is unavailable, automated identification can still be achieved using a business server-defined LDAP server.

→ Read more about Windows AD / LDAP Server.

# Redundancy and High Availability

## Overview
Provides fault-tolerant operation through hot-standby servers, database replication, and automatic failover.

## Key Features
- **Hot-Standby Servers** - Automatic synchronization and failover
- **Database Redundancy** - Replicated alarm and historian databases  
- **Network Redundancy** - Multiple physical network paths
- **Hot-Swapping** - Change project versions without downtime
- **Module-Level Redundancy** - All modules support redundant operation
- **Profile-Specific Settings** - Different redundancy for Dev/Test/Production

Working with the Security Module

Customizing Login Procedures

Modify the login page, fine-tune user validation, and incorporate custom logic into the client startup ScriptTask process for a tailored login experience.

Further User management can also be execute on Scripts.

→ Read more on Scripts, Handling Security

Applying Security to Displays

Regulate user access and interactions within displays, either by protecting the entire display, or specific commands or elements within each display.

Display Edit or Run Security

The configuration table Displays / List, has the columns EditSecurity and RunSecurity that allow to define the PermissionGroups allowed to configure, or open in runtime, each displays. 

Security within the Display

When drawing the solution User Interface, there is a Dynamic Property specifically to apply security to any Input the operator may do at the display.

→ Read more on Drawing User Interfaces / Dynamics and UI Elements, the Security Dynamic configuration. 

Security Runtime Attributes

The Securitynamespace contains all runtime information regarding the security system. The Clientobject has information about the current user logged at that client station.

→ Read more about Objects and Namespaces.

Anchor
BestPractices BestPractices

Best Practices and Troubleshooting

Best Practices and Recommendations:

• Regularly update your user list and their associated permissions to maintain security.
• Conduct periodic audits of user accounts and permissions, making necessary updates and removing inactive users.
• Enforce strong password policies to enhance security.
• Require complex passwords that include uppercase and lowercase letters, numbers, and special characters. Encourage regular password changes.
• Keep your system up-to-date with patches and updates.
• Regular updates often include security enhancements and fixes. Ensure your system is up-to-date to benefit from these improvements.

Troubleshooting and Common Issues:

• User Cannot Log In: Ensure the user is entering correct login credentials. Check if the user's account is active and not blocked or flagged as deleted. If the problem persists, contact your system administrator.
• Permission Denied Error: Check the user's assigned Permissions. Ensure they have the necessary access rights to perform the desired action. Update their Permissions or assign them to a different user group if necessary.

In this section:

Diagnostic Architecture

Logging Infrastructure

Image Added

Scalability Factors

Enterprise Unlimited (Distributed) (*2)
100,000+

Enterprise Unlimited (Stand-alone)
15,000-100,000 I/O (*)

Enterprise Scaled
1,500 to 15,000 I/O

MachineHMI
Up to 1,000 I/O

Security Highlights

Security and Reliability

We prioritize stability and security throughout our platform's design, from technology selection to module architecture.

Easy Configuration and Maintenance

Our platform offers secure, straightforward configuration and maintenance for various scenarios, ensuring scalability and consistency.

Operational Stability

Operational stability is guaranteed with our platform's 100% managed code implementation, featuring robust exception handling and seamless failure recovery.

Redundancy and Availability

For high availability, our platform offers redundancy with a proven hot-standby system for real-time databases, alarms, and historians, catering to diverse network setups.

FDA 21 CFR Part 11 and NERC

The software platform has a range of security and compliance features that can be used to help organizations meet the requirements of FDA 21 CFR Part 11. It is important to note that compliance is an ongoing process, and therefore, organizations should regularly monitor and update their systems and policies to ensure adherence to the standards established by the FDA.

The platform was also designed following the applicable recommendations from NERC CIP, such as the CIP-007-1 - Cyber Security-System Management.

Title 21 CFR Part 11 is the part of Title 21 of the Code of Federal Regulations that establishes the United States Food and Drug Administration (FDA) regulations on electronic records and electronic signatures (ERES).

Part 11, as it is commonly called, defines the criteria under which electronic records and electronic signatures are considered trustworthy, reliable, and equivalent to paper records.

Listed below and described are some security-related features available in the product:

• Access Control: Security technique that regulates who or what can view or use resources in a computing environment.

• Password Encryption: System administrator does not possess access to the user password. They are encrypted before being stored.

• Maximum and Minimum Age for Password: A feature that imposes a minimum password age before allowing its change, and a maximum age before expiring.

• Required Password changing: Forces the user to alter his password after the first login has been made.

• User Name and Password Minimum Length: Establishes minimum requirements for passwords.

• Block on Invalid Login Attempt: Blocks User after reaching maximum number of invalid logins attempted.

• Store Password History: A range of the last 0-5 passwords can be stored to make sure User does not repeat an already used one.

• Auto Log Off: User is logged off the system for inactivity or expiration date.

• Audit Trail Data: Security-relevant chronological record, set of records, that provide documentary evidence of the sequence of activities that have affected at any time a specific operation.

For detailed Explanation on how to add security management in project consist with these rules, go to the page FDA 21 CRT Compliance page.

For addition information on NERC CIP-007-1 - Cyber Security-System Management, go to the page NERC CIP Overview.

Built-in .NET Security

FrameworX development is built on the .NET framework, following strict security protocols. Each module adheres to specific guidelines aligned with its function, such as FDA compliance for the Alarms module and adherence to standards like IEC61850 for modules handling electrical device communications.

Below are the main security topics along with essential details about each.

Security at the Core Level

Security implementation is ingrained at the core level rather than being applied externally. The platform's modules incorporate built-in security components designed from their very core.

For more detailed insights into security in .NET, refer to Microsoft's documentation available at: Microsoft .NET Security Information

Web Client Communication Security

HTML5 provides flexibility in choosing between "http" or "https/ssl" protocols.

The production servers will use HTTPS, but the allowing http connection on development, simplifies the early state of the projects.

The HTTPS uses TLS security. 

The TSecureGateway is a crucial part of our platform, enabling smooth data transfer across different security network zones. It serves as a bridge, moving data from lower levels, like the factory floor (Level 2), to higher levels such as the enterprise (Level 4).

Acting as a protective barrier, the TSecureGateway shields internal networks from insecure traffic. Enterprises rely on it to guard employees and users against potential threats from malicious web traffic, websites, viruses, and malware.

Files and Execution Protection

License/Softkey

The "License/Softkey" feature employs the .NET class System.Security.Cryptography.Rijndael, utilizing symmetric encryption with a key size of 256 bits.

Digital signature

All assemblies created by Tatsoft are signed digitally.

Project format (Configuration protection) 

All project settings, including security measures like cryptography, power recovery, and user/password protections, are stored in a relational database (.dbsln file). The source code and compiled binaries for Scripts and Displays are also stored in this file. This centralized storage method streamlines project management and deployment, making access and maintenance easier.

User Authentication and Permissions

User Authentication

Our platform offers integration with various systems for user authentication:

• Microsoft Active Directory and Windows Authentication
• LDAP server connection
• Built-in Users Database
• External databases or user authentication servers

Active-Directory / Windows Authentication

Enabling Windows Authentication bypasses the project's configured user list, relying on Windows policies instead. Windows manages user authentication directly, utilizing the currently logged-in Windows user for system access.

LDAP

When LDAP is used, the project ignores its configured user list and relies on policies managed by Windows and the LDAP Server. Authentication is handled by both Windows and the LDAP Server, with the external user logged into the LDAP Server being utilized within the system.

Runtime Users

The system dynamically generates users and stores their credentials in SQL databases. It seamlessly integrates with Active Directory or third-party systems to retrieve users, enabling integrated security and unified login capabilities.

Roles, Permission and Policies

Group and User Permissions

Our users have complete flexibility to define privileges based on groups or specific individuals. Permissions can be set globally or linked to particular displays, objects, or input actions, offering granular control over access levels.

User Policies

Our platform offers a comprehensive array of user management features, including identification policies, session duration control, automated logoff mechanisms, electronic signature capabilities, and robust audit-trail functionality.

Database Injection Protection

In database operations involving stored procedures, there is a significant concern about SQL injection. SQL injection can occur if parameters are passed as plain text within SQL statements, which could allow malicious code to be executed. To prevent this, we use the .NET API, where parameters are added to a command object’s parameter list. This approach makes SQL injection impossible by safely handling user input.

Security External Validation

Regularly the platform is accessed by Veracode, or third-party companies, on penetration testing report, gap analysis, and various other topics.

Any issues that would prevent a 100% approval are corrected.

Security & Users

Overview

Security & Users management in FrameworX 10.1 provides comprehensive access control, authentication, authorization, and audit capabilities to protect your industrial systems. This guide covers user management, role-based security, integration with enterprise authentication systems, and cybersecurity best practices following industry standards including ISA-99/IEC 62443.

Security Architecture

Defense in DepthSecurity Zones (ISA-99/IEC 62443)

Image Added

User Management

User Account Types

SecureGateway module simplifies connecting Level 3 and Level 4 opeartoins 

Creating Users

Manual User Creation

1. Navigate to Security → Users
2. Click New User
3. Configure user properties:

User Configuration:
??? Identity
?   ??? Username: john.smith
?   ??? Full Name: John Smith
?   ??? Email: jsmith@company.com
?   ??? Employee ID: EMP001
??? Authentication
?   ??? Type: Forms / Windows / Certificate
?   ??? Password: (if Forms)
?   ??? Domain: COMPANY (if Windows)
??? Authorization
?   ??? Role: Operator
?   ??? Groups: [Production, Maintenance]
?   ??? Areas: [Line1, Line2]
??? Settings
    ??? Account Enabled: Yes
    ??? Password Expires: 90 days
    ??? Session Timeout: 20 minutes
    ??? Concurrent Sessions: 1

Bulk User Import

csv

# Users.csv format
Username,FullName,Email,Role,Groups,Password
jsmith,John Smith,jsmith@company.com,Operator,"Production,Line1",TempPass123!
mjones,Mary Jones,mjones@company.com,Supervisor,"All",TempPass456!
bwilson,Bob Wilson,bwilson@company.com,Engineer,"Engineering",TempPass789!

Import process:

1. Prepare CSV file
2. Security → Users → Import
3. Map columns
4. Validate and import
5. Force password change on first login

Password Policies

Password Requirements Configuration

Password Complexity Rules

Requirements (3 of 4):
? Uppercase letters (A-Z)
? Lowercase letters (a-z)
? Numbers (0-9)
? Special characters (!@#$%^&*)

Additional Rules:
? Cannot contain username
? Cannot contain common words
? No sequential characters (123, abc)
? No repeated characters (aaa)

Role-Based Access Control (RBAC)

Predefined Roles

Administrator (Level 0)
??? Full system access
??? User management
??? Security configuration
??? All operations

Engineer (Level 100)
??? Solution configuration
??? Display design
??? Script development
??? No user management

Supervisor (Level 200)
??? All operator functions
??? Setpoint changes
??? Alarm management
??? Report generation

Operator (Level 300)
??? View displays
??? Acknowledge alarms
??? Basic control
??? No configuration

Viewer (Level 999)
??? View only
??? No control
??? No acknowledgment
??? No configuration