Introduction
FrameworX was designed to enable applications on mission critical systems, in various segments, including Energy, with NERC requirements, Oil&Gas, Pharma with FDA requirements, and various other segments. Independently of regulations requirements, all applications, small to large, HMI to IoT, benefits from the stable, reliable infra-structure and strong security protections inherent. to the platform. This section will address some of those features.
On this page:
Security and Reliability
Flexibility is a feature; Security and Reliability are mandatory and foundational requirements.
We built the platform design selection of technologies and the architecture of the modules to have stability and security at its core.
Easy and Secure Configuration and Maintenance
We created our platform thinking in different scenarios and topologies, from a local interface on an embedded panel to fault-tolerant servers that serve multiple projects and clients. The platform's development tools and project components are scalable, reusable, and consistent.
Operational Stability
Our platform's 100% managed code implementation provides unmatched operational stability since its intrinsically safe software architecture includes execution threads isolation, exception control, failure recovery, modular deployment, hardware abstractions, and operating system independence.
Redundancy and High Availability
For high availability systems, the platform can have a real-time database, Alarm and Historian servers, and data acquisition deployed as a redundant hot-standby system, with no project changes required.
The hot-standby redundancy is field-proven with hundreds of devices in the network and multiple clients.
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, 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: <<<<add info>>>>
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, under the chapter Security, Users and Roles.
Built-in .NET Security
The FactoryStudio development is based on .NET, using managed code, following security guidelines, where the development with .NET managed code must follow the .NET rules. There are specific guidelines followed for specific modules. For example, the Alarms adherence to the FDA guidelines are followed, for Electrical device communications with the IEC61850, or the other IEC are followed. Below are the main FS-Security topics and some basic information about them.
Link to Microsoft information about Security in .Net:
https://docs.microsoft.com/en-us/dotnet/standard/security/
Security at the Core Level
Security must be implemented at the core, not applied externally. The Platform Modules' have built-in security related components designed from the core.
Communication Security
Communication between modules
The cryptography between external modules — processes out of TServer: ScriptTaskServer, DataAccess, Devices, TRichClient, SmartClient, ModuleInfo, TraceWindow, PropertyWatch, etc — and TServer uses basically two classes:
a) System.Security.Cryptography.RSACryptoServiceProvider (Asymmetric, KeySize: 1024): Performs asymmetric encryption and decryption using the implementation of the RSA algorithm provided by the cryptographic service provider (CSP).
b) System.Security.Cryptography.Rijndael (KeySize: 256).
Note 1: No external program gets access to the TServer without validation/authentication. TServer answers to external programs only after validation/authentication via user/password or Windows Authentication.
Note 2: "RSACryptoServiceProvider" is used to generate "private/public keys"; "Rijndael" is used to encrypt/decrypt the data and it uses "private/public keys" described above.
Note 3: The data are only compressed if block size is over 16000 bytes. The compression is GZIP". "ModuleInformation" displays estimated values of each connection. WCF adds some bytes while sending data, so the values in "ModuleInformation" are estimated.
Note 4: ".NET Framework applications should use the TLS version the operating system (OS) supports." FS does not manually set the TLS version using the configuration of the operating system (OS).
Note 5: Remote access by WebAccess services (third-party program or modules) will use http or https consuming the web services available.
Communication with web clients
HTML5 can use "http" or "https/ssl". The compression will be configured on "IIS" and it will be GZIP".
Further, you can setup your application to have mandatory long, as well various forms with custom authorization, like IP filterer, or Location, among other.
Secure WebGateway
The TWebGateway is a tool included in the platform to allow to route data across different security Network zones, like moving that from the Level 2, the factoryFloor, to Level 4, the enterprise.
It also prevents unsecured traffic from entering an internal network of an organization. It is used by enterprises to protect their employees/users from accessing and being infected by malicious web traffic, websites and virus/malware.
Files and Execution Protection
License/Softkey
"License/Softkey" uses the .NET class System.Security.Cryptography.Rijndael (symmetric, KeySize: 256).
Digital signature
All assemblies created by Tatsoft are signed digitally.
Project format (Configuration protection)
All project configuration is stored in a relational database (.tproj file) with all security and protections like cryptography, power recovery and Users/passwords. The Scripts and Displays have the source and the compiled binaries stored in the same .tproj file. It makes the project easy to manage and deploy.
User Authentication and Permissions
User Authentication
The platform supports Integration with various systems:
- Microsoft ActiveDirection, Widows Authentication
- Connection with LDAP server
- Using the built-in Users Database
- Connection with external Databases or User Authentication servers
Active-Directory / Windows Authentication
When using Windows Authentication, the project will not use the User list configured in the project, only the policies, and this management is controlled by Windows. The Windows User that is logged into the computer will be the one used in the system.
LDAP
When using LDAP, the project will not use the User list configured in the project, just the policies and this management is controlled by Windows and the LDAP Server. The External User that is logged in the LDAP Server will be the one used in the system.
Runtime Users
Dynamically create users and store credentials in SQL databases. Get users from Active-Directory or third-party system for integrated security or unified login.
Roles, Permission and Policies
Group and User Permissions
Total flexibility to define privileges based on groups or specific users. Permissions can be global or tied to a specific display, object, or input action.
Database Injection Protection
In the database, calling Stored Procedure, there is a great concern about this part of "injection", because if parameters are passed as plain text in SQL Statement, the "injection" could be possible. Against this we use the .NET API where parameters are added to a list, making it impossible to code injection.
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.
In this section...