# General Infrastructure (GIR)

<figure><img src="https://3935398949-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxTRnDyIanlwU7cCKcAju%2Fuploads%2FLwON7SatwgHnIIcYkdeq%2FDALL%C2%B7E%202024-01-04%2012.23.25%20-%20A%20digital%20artwork%20depicting%20the%20risk%20of%20operational%20compromises%20in%20infrastructure.%20The%20image%20illustrates%20a%20complex%20system%20of%20machinery%20and%20control%20pan.png?alt=media&#x26;token=51a13dd3-3513-434e-8498-052e666da8d8" alt=""><figcaption></figcaption></figure>

General infrastructure risks:

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://duck-initiative.gitbook.io/d.u.c.k.-knowledge-base/risk-framework/risks/general-infrastructure-gir.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.