| Category | Information Technology System | SCADA and ICS Systems |
| Performance Requirements | Non-real-time
Response must be consistent
High throughput is demanded
High delay and jitter maybe acceptable
| Real-time
Response is time-critical
Modest throughput is acceptable
Delay and/or jitter is not acceptable |
| Availability Requirements | Responses such as rebooting are acceptable
Availability deficiencies can often be tolerated, depending on the system's operational requirements | Responses such as rebooting may not be acceptable because of process availability requirements
Availability requirements may necessitate redundant systems
Outages must be planned and scheduled days/weeks in advance
High availability requires exhaustive pre-deployment testing |
| Risk Management Requirements | Data confidentiality and integrity is paramount
Fault tolerance is less important – momentary downtime is not a major risk
Major risk impact is delay of business operations | Human safety is paramount, followed by protection of the process
Fault tolerance is essential, even momentary downtime may not be acceptable
Major risk impacts are regulatory non-compliance, environmental impacts, loss of life, equipment, or production |
| Architecture Security Focus | Primary focus is protecting the IT assets, and the information stored on or transmitted among these assets.
Central server may require more protection | Primary goal is to protect edge clients (e.g., field devices such as process controllers)
Protection of central server is also important |
| Unintended Consequences | Security solutions are designed around typical IT systems | Security tools must be tested (e.g., off-line on a comparable ICS) to ensure that they do not compromise normal ICS operation |
| Time-Critical Interaction | Less critical emergency interaction
Tightly restricted access control can be implemented to the degree necessary for operations | Response to human and other emergency interaction is critical
Access to ICS should be strictly controlled, but should not hamper or interfere with human-machine interaction |
| System Operation | Systems are designed for use with typical operating systems
Upgrades are straightforward with the availability of automated deployment tools | Differing and possibly proprietary operating systems, often without security capabilities built in
Software changes must be carefully made, usually by software vendors, because of the specialized control algorithms and perhaps modified hardware and software involved |
| Resource Constraints | Systems are specified with enough resources to support the addition of third-party applications such as security solutions | Systems are designed to support the intended industrial process and may not have enough memory and computing resources to support the addition of security capabilities |
| Communications | Standard communications protocols
Primarily wired networks with some localized wireless capabilities
Typical IT networking practices | Many proprietary and standard communication protocols
Several types of communications media used including dedicated wire and wireless (radio and satellite)
Networks are complex and sometimes require the expertise of control engineers |
| Change Management | Software changes are applied in a timely fashion in the presence of good security policy and procedures.
The procedures are often automated. | Software changes must be thoroughly tested and deployed incrementally throughout a system to ensure that the integrity of the control system is maintained.
ICS outages often must be planned and scheduled days/weeks in advance |
| Managed Support | Allow for diversified support styles | Service support is usually via a single vendor |
| Component Lifetime | Lifetime on the order of 3-5 years | Lifetime on the order of 15-20 years |
| Access to Components | Components are usually local and easy to access | Components can be isolated, remote, and require extensive physical effort to gain access to them |
