General Infrastructure (GIR)
Risks related to process errors and inefficiencies of the general infrastructure.
General infrastructure risks:
ID | Risk Group | Risk Vectors | Risk Vector Description |
---|---|---|---|
GIR1 | Infrastructure | Not granular enough role-definitions for access control | Internal employees and external hackers may gain access to too many systems if they manage to have a highly privileged role |
GIR2 | Infrastructure | Token lifetimes are too wide | Authentication information does not expire timely and can be used later. |
GIR3 | Infrastructure | Fix versions on every deploy | Downtime if a system needs to be just re-started if newest version is accidentally pulled |
GIR4 | Process | Insufficient monitoring/logging | - Inability to learn from incidents - Late detection of incidents - insufficient automation to react to incidents |
GIR5 | Process | Insufficient off-boarding controls, e.g. by too many authentication mechanisms around. | terminated employee can remain having access to systems and do harm |
GIR6 | Process | No password rotation | - Leak of passwords - brute force |
GIR7 | Process | Use of direct auth | Authentication information does not expire timely and can be used later. |
GIR8 | Process | No Input validation | Buffer overflow attacks |
GIR9 | Infrastructure | Failure to properly perform network segmentation | No container/node should be openly accessible from the internet from all IP addresses. This increases the attack vector enormously |
GIR10 | Infrastructure | Lack of encrypted traffic between services and deployment scripts | Anyone on the network can sniff out packages with secrets included, and may be able to steal passwords and tokens in this way |
GIR11 | Infrastructure | No separate tests and staging environments | Improper change management and testing of software updates "in production" |
GIR12 | Infrastructure | General architectural flaws | General risk category that can cause downtime, slashing, etc. This includes, but is not limited to: - Non-scalable deployments - Use of tools not made for this purpose - Lack of robustness/redundancy - Bad change management - Bad container isolation |
GIR13 | Infrastructure | High Blast radius of software bug in overall system | A small error affects the whole system and all clients right away, instead of being caught early with limited effect on the whole system. |
GIR14 | Infrastructure | Low Infrastructure provider security | Hacks through the apis of the infrastructure provider |
GIR15 | Infrastructure | CVE Monitoring | Attack on the system suddenly possible once published |
GIR16 | People | Human error | Anything a human can touch can go wrong |
GIR17 | Process | Use of non-hardened images | Attack on the system using the weakest link of a given node/container |
GIR18 | Process | Insufficient change management mechanisms in place | - Downtime on update - Slow down in reaction time to incident |
GIR19 | Process | Lack of automation for deloyment | - Downtime on update - Slow down in reaction time to incident |
GIR20 | Process | Lack of testing (software and infrastructure) | - Downtime on update - Slow down in reaction time to incident |
GIR21 | Process | Lack of enforced code review | - Downtime on update - Slow down in reaction time to incident |
GIR22 | Process | Lack of Security training (password hygiene, phising attacks, ...) | Employees spill secrets |
GIR23 | Process | Make-shift container orchestration procedures | Failure when e.g. failover is actually needed to be performed |
GIR24 | Software | Third party software and vendors | Suboptimal third-party software practices |
GIR25 | People | Centralized knowledge | If the infrastructure knowledge is not shared across the team, this could lead to a heavy dependency on a single person |
Last updated