Safety Hazards in Industrial Control Systems: Common Logic Vulnerabilities in PLC Programs and Security Reinforcement Measures

The safety issues in industrial control systems should not be underestimated. In my over ten years of maintenance experience with industrial control systems, I have found that many factory PLC programs have security vulnerabilities. These seemingly minor flaws can lead to equipment damage, production interruptions, and even safety accidents. Today, I will share common logic vulnerabilities in PLC programs and practical security reinforcement measures.

The Dangers of Missing Exception Handling

I once encountered a case where a chemical plant’s PLC control program did not handle temperature sensor failures. A loose sensor wire caused abnormal readings, and the system failed to issue an alarm and shut down in time, resulting in a small-scale material spoilage incident.

// Error example: Directly using sensor data without validity checks
IF Temp_Value > Max_Temp THEN
    Heating_Element := OFF;
END_IF;

// Correct example: Adding sensor fault detection
IF Sensor_Error THEN
    Heating_Element := OFF;
    Alarm := ON;
ELSIF Temp_Value > Max_Temp THEN
    Heating_Element := OFF;
END_IF;

Important Note: Any critical sensor data should undergo validity verification, including:

• • Whether the value is within a reasonable range
• • Whether the sensor communication is normal
• • Whether the rate of value change conforms to physical laws

Risks of Missing Interlock Logic

Interlocking is the foundation of safety in industrial control systems. Just as a household electric water heater does not heat when there is no water, industrial equipment also requires strict interlock protection.

A steel plant’s annealing furnace once experienced overheating because it lacked interlock logic between the fan and heater, causing the heater to continue operating when the fan failed. The correct ladder diagram should be:

|--[Fan Running Feedback]--+--[Other Conditions]--( Heater Start )--|
                  |
                  +--[Fan Failure]----( Heater Emergency Stop )--|
                  |
                  +--[Fan Failure]----( Alarm Output )--|

Interlock Design Principles:

• • Safety devices should usenormally closed contacts as condition inputs
• • Critical interlocks should have at least two levels of protection (software + hardware)
• • Interlock conditions should consider the startup and shutdown sequence of equipment

Missing Timeout Protection Mechanism

The most easily overlooked aspect in PLC programs istimeout protection. For example, a valve should normally open within 3 seconds; if feedback is not received after this time, it is likely that the valve is stuck or the feedback switch has failed.

// Timeout protection code example
IF Valve_Open_CMD AND NOT Valve_Open_Feedback THEN
    Timer_Valve.IN := TRUE;
ELSE
    Timer_Valve.IN := FALSE;
END_IF;

Timer_Valve(); // Timer function call

IF Timer_Valve.Q THEN // If the timer reaches the set value
    Valve_Fault := TRUE;
    Valve_Open_CMD := FALSE; // Safety handling: close control command
    Alarm_Code := 42; // Set specific fault code
END_IF;

In a water treatment project I participated in, adding such timeout protection prevented an overflow incident caused by actuator failure.

Defects in Emergency Stop Logic Design

Many PLC programs have overly simplistic emergency stop logic, merely cutting off the output. The correct emergency stop should be a complete process:

1. 1. Immediately stop dangerous actions
2. 2. Shut down related equipment in a predetermined safe order
3. 3. Place the system in a safe state
4. 4. Lock restart conditions until manually reset

For example, in an injection molding machine, the emergency stop should not directly cut power but should first stop injection, then lower the temperature, and finally cut power.

Common Mistakes in Emergency Stops:

• • Using regular I/O points instead of safety-rated I/O
• • Not considering the default state of the system after power loss
• • Ignoring mechanical inertia and residual energy

Inadequate Access Control

In a food factory, I once saw operators directly modifying critical parameters in the PLC, such as sterilization temperature and time. This is extremely dangerous! The correct approach is:

// Hierarchical access control example
IF User_Level >= SUPERVISOR_LEVEL THEN
    Allow_Parameter_Change := TRUE;
ELSE
    Allow_Parameter_Change := FALSE;
    IF Parameter_Change_Request THEN
        Access_Denied_Alarm := TRUE;
    END_IF;
END_IF;

Safety Recommendations:

• • Set at least three levels of access: operator, administrator, and maintenance personnel
• • Changes to critical parameters should have an audit mechanism
• • All parameter changes should be logged

Insufficient Cybersecurity Protection

Modern PLCs mostly support network communication, which brings new security threats. I have seen many factories’ PLCs directly connected to office networks, even the internet, without any isolation measures.

PLC Network Security Reinforcement Measures:

• • Use firewalls to isolate control networks from office networks
• • Disable unnecessary communication ports and services
• • Change default passwords and regularly update firmware
• • Consider unidirectional communication gateways (data flows out only, cannot be written to)
• • Implement network monitoring and anomaly detection

Missing Data Validation

When the PLC receives commands from HMI or upper-level computers, data validity verification should be performed. For example, setpoints must be within allowed ranges:

// Data validation example
Temp_Setpoint_Request := HMI_Temp_Setpoint;

IF (Temp_Setpoint_Request >= MIN_TEMP) AND (Temp_Setpoint_Request <= MAX_TEMP) THEN
    Temp_Setpoint := Temp_Setpoint_Request;
ELSE
    Invalid_Setpoint_Alarm := TRUE;
    // Keep the original setpoint unchanged
END_IF;

Data validation should include:

• • Range checks (upper and lower limits)
• • Rate of change checks (to prevent sudden changes)
• • Type checks (to prevent data type errors)
• • Checksums or CRC (for communication data integrity)

Practical Recommendations for Security Reinforcement

1. 1. Conduct risk assessments: Identify critical functions and potential threats in the system
2. 2. Adopt a “defense in depth” strategy: Multi-layered security measures, not relying on a single protection
3. 3. Regularly back up programs: Ensure recovery in case of program damage
4. 4. Implement change management: Record all program modifications and conduct audits
5. 5. Conduct regular security audits: Check for new security vulnerabilities in the system
6. 6. Design for fail-safe: The system should enter a safe state upon failure, not an unknown state
7. 7. Power failure protection: Consider how the system safely restarts after a power loss
8. 8. Train operators: Raise safety awareness and train for emergency response

Reinforcing system security is not a one-time task but a continuous improvement process. When writing new programs or modifying existing ones, incorporate safety checks into standard procedures, establish clear safety programming standards, and ensure that everyone on the team understands and follows these standards.

Safety should not be an afterthought but a core element considered from the design stage. By identifying and fixing these common logic vulnerabilities, the safety and reliability of industrial control systems can be significantly improved.