1. Introduction 

1.1 Purpose of the document

With the following document, we would like to provide you with a comprehensive overview of the system hardening practices followed by us when it comes to imc Cloud Services. This document will describe all the essential components, functions, and processes followed during system hardening.

System hardening is the practice of securing a system by reducing its surface of vulnerability. This process involves various measures and best practices designed to minimize potential security risks and ensure robust defence mechanisms against attacks. NIST SP 800-152 defines hardening as a process intended to eliminate a means of attack by patching vulnerabilities and turning off nonessential services.

System hardening encompasses a range of activities, including the removal of unnecessary software, disabling non-essential services, enforcing strict user access controls, and applying security patches and updates regularly. By systematically addressing these elements, organizations can significantly enhance the overall security posture of their IT infrastructure.

1.2 Scope and applicability

 2. System Hardening Principles 

 2.1 Secure by design and default 

Secure by design and default is a fundamental principle in system hardening that emphasizes building security into systems from the ground up. This approach ensures that security measures are not merely added as an afterthought but are integral to the system's architecture and functionality.

By prioritizing secure coding practices, robust access controls, and stringent data protection mechanisms during the design phase, organizations can mitigate potential vulnerabilities and minimize attack surfaces. Additionally, configuring systems with security settings enabled by default further strengthens their defence against unauthorized access and exploits. This proactive stance on security fosters a resilient IT environment that can better withstand the evolving threat landscape. 

2.2 Least privilege principle 

The least privilege principle is a key security concept that dictates that users, applications, and systems should only be granted the minimum level of access necessary to perform their functions. By enforcing this principle, organizations can significantly reduce the potential for unauthorized access and limit the damage that can be caused by compromised accounts or malicious activities. This approach minimizes the risk of privilege escalation attacks, where attackers attempt to gain higher levels of access to exploit system vulnerabilities.

Implementing the least privilege principle involves carefully assessing and assigning permissions, regularly reviewing access controls, and ensuring that accounts and services operate with the lowest possible privileges. This creates a more secure environment by preventing excessive access and containing potential threats within restricted boundaries.

2.3 Defence-in-depth

Defence-in-depth is a comprehensive security strategy that involves implementing multiple layers of defence to protect against potential threats and vulnerabilities. Instead of relying on a single security measure, this approach integrates various protective mechanisms, each designed to address different aspects of the system's security. These layers can include firewalls, intrusion detection systems, antivirus software, encryption, and user authentication protocols.

By employing a diverse set of security controls, Defence-in-depth ensures that even if one layer is compromised, other layers continue to provide protection, thereby reducing the overall risk of a successful attack. This strategy creates a robust and resilient security posture, capable of withstanding a wide range of cyber threats and minimizing the potential impact of security breaches. 

3. Security Standards 

 The following security standards and best practices are met by the Learning Suite 

3.1 SSL/TLS 

Imc Cloud Services offers the possibility to encrypt the communication between client and server with SSL. This allows different encryption algorithms to be implemented, and the certification key can be selected according to the security requirement. Extended Validation SSL Certificates (EVSSL) are also supported. For an EV-SSL certification, the client must undergo further inspection by a certification body. Identity and business address of the client are checked amongst other things. Websites with EV-SSL-certification are identified in the browser by green highlighted company name in the address bar. EV certificates are used, for example, in online banking. 

3.2 SHA256 

imc Cloud Services uses the SHA256 process for functions that require one-way encryption. With one-way encryption, a text is simply encrypted but no longer decrypted. In this way, it can be determined whether a user is in possession of a certain text to be encrypted (e.g. password). The password check compares the encrypted hash values of the entered and stored passwords. The procedure is further secured by multiple use of security mechanisms. 

 3.3 Key Vault 

In imc Cloud Services keys, and secrets such as passwords can be securely stored and managed in a Key Vault. In the case of hosting by imc AG, Microsoft Azure Key Vault is used. For on-premises installations of the system, the software HashiCorp is additionally supported as a Key Vault solution. A Key Vault uses an authorisation concept to control the access and use of keys. For imc express Customers keys are stored in AWS Key Managment Service. 

With the use of Key Vault, our customers can store their keys themselves without imc being involved in this process or having to transfer the keys in the event of support. 

3.4 OWASP 

The Open Web Application Security Project (OWASP) is a non-commercial Organisation. The aim of OWASP is to improve software security. OWASP draws attention to frequent vulnerabilities and enables these to be combated. Further, OWASP defines standards for secure development and application of software.

An important OWASP publication is the Top 10 of the most serious security flaws of web applications. imc considers the OWASP standards in the further development of the Learning Suite. The tools and libraries recommended by OWASP are used to adapt security to the required standards. 

4. System Hardening Checklist NIST SP 800-53/171 

Here’s a checklist comparing NIST system hardening guidelines (primarily derived from NIST SP 800-53 and SP 800-171) that align with ISO/IEC 27001 controls.  

4.1 Checklist: NIST System Hardening vs. ISO/IEC 27001 

 5. Implementation Overview 

 This section covers detailed information of system hardening procedures based on the System Hardening Checklist from Checklist: NIST System Hardening vs. ISO/IEC 27001 . The key item on the checklist is carefully reviewed and brief explanations on the implementation of the processes are provided where necessary. 

5.1 Access Control 

5.1.1 Enforce least privilege principles 

The rights for handling objects of all kinds (persons, groups, catalogues, learning content, etc.) in the LMS system are precisely controlled by the release for each individual object and recorded in the Access Control List. In this way, users and group-specific access rights can be assigned in detail and independently of each other. Rights can either be assigned directly to individual users or combined in rights clusters for entire user groups or clients. The ACL allows you to provide a tailor-made range of functions for each user group in the system. 

Imc Express offers its users role-based access control (RBAC) and uses AWS IAM Roles to restrict access to each microservice to other resources. 

Internally, access to imc AG premises in Saarbrücken is controlled by means of an electronic access key in addition to a uniform zoning concept and behavioural patterns within these zones. 

5.1.2 Regularly review and update access permissions vulnerabilities 

The system audit of imc AG is carried out every six months. The following is reviewed during a system audit:

• Log evaluation

• Check up-to-datedness of internal IT documentation

• Access right review

• Virus Scanner Report

• Check configurations of systems and services

• License management

• Data loss Prevention

• MDM Device Compliance Check

• Checking our network quality: e.g. traffic flow analyses, availability measurements)

• Checking customer Jira Accounts

• Checking access control in Saarbrücken (Zone 3 & 4) 

5.1.3 Implement strong authentication mechanisms 

The LMS supports various authentication procedures (including local logon, SSO via SAML2 or OIDC), which can be set per client. Access to client-specific portal pages can be implemented via own URLs or via parameters (client). For local login via the LMS, specific password policies can be defined that deviate from the standard configuration. This concerns the password complexity, the duration of password validity, the options for generating passwords and, if applicable, the use of a 2FA procedure. In addition, it must be considered whether authentication procedures must be configured in an environment-specific manner. This is particularly necessary for SSO procedures, as a productive environment and a test environment require different return points for the SSO procedure.

Imc Express is connected to the LMS via OIDC and thus utilises the authentication mechanism of the LMS via a secure standard (OpenID Connect). 

5.2 System and Communication Protection 

5.2.1 Encrypt sensitive data at rest and in transit 

imc Cloud Services provide the opportunity to encrypt the communication between client and server using TLS. This allows different encryption algorithms to be implemented. Moreover, the certification key can be selected according to the security requirement. 

The Advanced Encryption Standard (AES) is a FIPS- approved encryption standard that can be used to protect electronic data (FIPS-197 AES, 2001). 

imc Learning Suite uses AES amongst others to create encrypted URLs for content access (“securedata”). Regarding the AES configuration imc Learning Suite follows recommendations of BSI (TR-02102-2, 2021) and NIST (SP800-38A, 2001) using AES/CBC/PKCS5PADDING as default with a key length of 128-Bit. 

Imc Express uses signed URLs (AWS v3) to restrict access to content. A signed URL includes additional information, for example, an expiration date and time, that gives you more control over access to your content.

5.2.2 Disable insecure protocols and services 

This is at the discretion of the customer (system administrator). From the list of defined HTTP request methods, we do not block/prohibit any by default. For our REST API endpoints, only the valid and defined methods are allowed. The corresponding others are disabled, resulting in an HTTP error 405. 

In our REST API documentation, everything that is not documented is prohibited.

5.3. Configuration Management 

5.3.1 Maintain an inventory of approved hardware/software 

We use Azure/AWS which has a list of all the cloud assets belonging to as customer, and they can be tracked using the same but in case of on-premise setup it's up to the customer. Internally, we use Microsoft Intune that covers servers, appliances and mobile devices.

Additionally, we have an asset management that documents all the assets in the JIRA. 

5.3.2 Apply baseline configurations to all systems 

We use microservices based on Docker images running Alpine Linux. Since the 14.8.0.0 release, the LMS can be deployed as a set of container images. These container images are started together to form an isolated network of containers where only the required http ports can be made accessible to the host system. These ports cannot be used to access the application from the host by default. Instead, a dedicated gateway microservices controls which request should be forwarded to the respective internal services. 

Imc Express also uses minimal Alpine Linux Container Images. These containers run in an isolated AWS EKS Cluster and are only accessible via AWS WAF -> Load Balancer -> Ingress Controller.  

5.3.3 Use automated tools for configuration monitoring 

We use Git version control to have a versioned configuration for Kubernetes deployments and the configuration files of the software itself. Audit logs can also be used to track any changes in configurations. 

5.4 Vulnerability Management 

5.4.1 Conduct regular vulnerability scans 

We perform regular scans to detect vulnerabilities in our service/software. These include the following activities/ checks:

• Software composition analysis (SCA) - For software composition analysis, we do use regular scans (min. daily) integrated into the git pipelines for all relevant repositories. This scan currently bases upon two approaches:  

• • Container image scanning - All the container images of all microservices belonging to a release are scanned. These scans include operating-system-level packages as well as application-level components. Individual images are scanned daily while a full scan of all images together is run on a high frequency, every fortnight at least. 

• • Additionally, we also apply application-level dependency scanning (including third-party dependencies).

• Static application security testing (SAST) - We use SonarQube with a custom ruleset (including OWASP Top 10 and CWE Top 25 rules) to scan the code for quality and security issues. The full scan of the main branches of all development projects using this ruleset is done every night

Using the SonarLint plugin which developers use in their integrated development environments (IDEs), we also provide feedback on most of the rules before commit and during code review (“shift left principle” (apply security already in coding phase)) 

5.4.2 Track and remediate identified vulnerabilities 

Vulnerabilities identified during the above scans or during other testing / QA activities are tracked using our internal JIRA ticket system. To optimize remediation efforts, vulnerabilities must be prioritized based on the risk that they pose to the organization.

The vulnerabilities are classified following the CVSS standard rating categories of CRITICAL, HIGH, MEDIUM, LOW, INFO. 

If it is a bug for which we are responsible, then fixing measures are initiated. In the case of external sources (such as vulnerabilities from Microsoft), it is checked whether there are corresponding patches that are promptly applied by Microsoft or whether risk mitigation measures are in place.  

As a rule, CRITICAL and HIGH vulnerabilities are either processed as direct hotfixes or, if still in the mitigation time, are also included in the next available patch. Fixes for vulnerabilities in the other categories are usually included in the next patches. 

5.4.3 Maintain a record of vulnerability remediation actions 

Fixes are always retested, taking care to recreate the test scenario in which the vulnerability occurred. All related steps of this process are documented within the corresponding Jira ticket. 

5.5 Application Hardening 

5.5.1 Secure application configurations 

The application can only be accessed via HTTPS. If needed, we can also apply IP-based request filtering. We apply best-practice security response headers and encryption protocol hardening where we test that no deprecated encryption protocol is active on the installation 

5.5.2 Perform code reviews and penetration tests 

Please see the subsection Conduct regular vulnerability scans. 

imc also has penetration tests (extensive security tests) carried out on a regular basis. The aim of this security test is to reveal weaknesses and errors, to increase security and to confirm IT security by third parties. The results and security updates are automatically delivered to customers in new patches. Thus, long-term security of the system is guaranteed. 

5.5.3 Remove unused or insecure components from applications 

We remove any unused libraries or dependencies from the application. 

5.6 Monitoring and Logging 

We currently don't have 24/7 monitoring, but our architecture offers the possibility to collect the console output and all log files of every service in a central location. This task is performed by a dedicated service, the Logging Service. The Logging service includes an Elasticsearch instance for log file aggregation and a Kibana instance for logfile visualisation and analysis. Together with Logstash, which is a small application that is part of every service image, centralized logging is realized.  

On the hosting side, the logs are monitored by Azure or AWS. In case of any security breaches reported by them, our team takes over and initiates the necessary steps as part of incident management.  

If this is a requirement, we could discuss this further and provide this service separately.

The LMS can log the following things (Audit logs):  

• Authentication success and failures (including privilege flag) and logout  

• User data changes

• User data export by admin user

• Group membership changes

• Access right changes

• Password change requests or changes (by learner)

• Report access and export by admin user

• System configuration

• Data access without access rights

• Dashboard access by admin user

• Client Administration

• Notification changes and monitor access

• Meta element access and changes

As a general guideline for the retention period, the logs are retained for a maximum of 4 weeks. They can be stored longer if required but it needs to be requested separately by the customer. 

5.7 Backup and Recovery 

Database backups are set up to be geo-redundant which means backups are synchronously copied three times within a single physical location in the primary region. Then the backup data is copied asynchronously three times to a single physical location in the paired secondary region. 

This results in: 

• Three synchronous copies in the primary region. 

• Three synchronous copies in the paired region that were copied over from the primary region to the secondary region asynchronously 

 imc AG runs a failover strategy. The risks can be reduced by a failover data centre. In this case, all the required information is constantly synchronized to a second data centre and, in the event of a failure of the first data centre, the second data centre takes over the productive operation. In this failover scenario, imc offers two possible solutions: hot standby and cold standby. 

The hot standby constantly runs as a complete copy in a secondary data centre. If the primary data centre fails, only the architecture in the secondary data centre is switched active (as primary). This can be done automatically or manually. Manual switching prevents possible switching between primary and secondary. Hot standby although doubles the hosting costs. 

With cold standby, only a minimal architecture is operated in the secondary data centre. Cold standby is also constantly synchronized, but when the primary data centre fails, scaling must happen in addition to activation. This takes more time than hot standby and must be supported manually. However, the costs are significantly lower for cold standby. 

Please refer our Business Continuity Plan for more information. 

If your database is encrypted with TDE, backups are automatically encrypted at rest, including LTR backups. All new databases in Azure SQL are configured with TDE enabled by default.

5.8 Endpoint Security 

Microsoft Defender for Azure storage or Amazon’s Guard Duty can be deployed as antivirus protection. Regular update of the security tool definitions is managed by the cloud service provider. We also provide an antivirus microservice inside the K8s cluster installation based on ClamAV. 

5.9 Network Security 

5.9.1 Segment networks based on trust levels 

Customer is provided with a dedicated system environment. The system is logically separated into different namespaces Test, Production, Development, etc as desired. Only the hosting has access to the Kubernetes cluster which is in the cloud using namespaces. 

5.9.2 Use firewalls and intrusion detection systems 

WAF, IDS/IPS and other security extensions are supported by the chosen cloud hosting provider, but they need to be requested separately. 

5.9.3 Regularly update network device configurations 

This is taken care of by the cloud hosting provider like AZURE, AWS, etc. 

5.10 User Awareness and Training 

5.10.1 Conduct regular security awareness training 

Every imc employee must successfully complete our security awareness training. This is performed annually, hosted through our own internal LMS for employees. This includes for GDPR, information security and other topics covering data protection and is done on imc's own LMS. 

5.10.2 Provide role-based security training 

An individualized training program on secure development guidelines is available in the internal Learning Management System (LMS). This program is designed to cover essential security knowledge, with a focus on industry-recognized standards for identifying and mitigating common software vulnerabilities.  

This training is mandatory for all developers within the scope of secure development guidelines. Additionally, quality assurance (QA) personnel and downstream development teams, such as Technical Services and Customization teams (not directly in scope), are also required to complete this training. The training is conducted on an annual basis to ensure continuous education on emerging threats and updated best practices. 

The course content includes:

OWASP Top 10: The ten most critical security risks identified by the Open Web Application Security Project (OWASP), emphasizing common application vulnerabilities and best practices for mitigation. 

CWE Top 25: The top 25 most dangerous software weaknesses, as outlined by the Common Weakness Enumeration (CWE) project, which highlights errors that are often easy to exploit and can lead to serious vulnerabilities in software. 

5.11 Physical Security 

Physical security available at the Microsoft data centres is provided in detail at Microsoft. 

5.12 Incident Response 

As part of our ISO 27001 certification, we have implemented a process to respond to security events and incidents. Upon detection of a security breach, our notification process is activated to ensure compliance with applicable laws. The process includes: 

• Immediate investigation of the breach - Our IT security team, including the Data Protection Officer, is immediately deployed to assess the scope and impact of the breach. This team works to contain the breach and identify the data affected.

• Legal and regulatory review - Our IT security team consults with our DPO to comply with the specific notification requirements of applicable breach notification laws relevant to the data affected. This ensures that all legal obligations are met.

• Timely notification - Notifications are made without undue delay, typically within the timeframe required by applicable government laws (within 72 hours of discovery of the breach).

• Content of notifications - Notifications to the customer (the controller as defined by the GDPR) will include details of the breach, the type of information affected, the steps taken to secure the data after the breach, etc. imc will only notify the controller. Further communication to those affected will only take place with the controller's explicit authorization.

• Ongoing communication with the controller.

• Documentation and review – All breaches and the countermeasures taken are thoroughly documented. This documentation helps verify compliance and improves our future response strategies. As part of this step, we are working on further improvements to our IT security measures to avoid or minimize the risk of recurring security breaches.

5.13 Remote Access Security

Our employees use the secure HTTPS protocol when connecting to Azure portal and are required to use multi-factor authentication for remote connections using Microsoft Authenticator for accessing resources.

6. Ongoing Updates and Revisions 

 This document is intended to be a dynamic and evolving resource, reflecting advancements in security technologies, industry standards, and emerging risks. The information contained herein is provided solely for informational purposes and does not constitute a binding commitment, representation, warranty, or guarantee of any kind. The recommendations and guidance set forth are of a general nature and may be subject to modification to accommodate customer-specific requirements, unique system configurations, or newly identified risks and vulnerabilities. This document is neither exhaustive nor definitive, and reliance on its content is at the user’s own discretion and risk. Updates may be made periodically and at the sole discretion of imc, without notice or obligation. Users are strongly advised to consult the most current version of this document and to undertake independent assessments to determine the relevance and applicability of its contents to their specific circumstances and requirements.