Author Topic: [FAQ] ReHIPS failsafe mechanisms and mitigations (part 3)  (Read 30 times)

fixer

  • Administrator
  • Hero Member
  • *****
  • Posts: 1414
[FAQ] ReHIPS failsafe mechanisms and mitigations (part 3)
« on: March 06, 2019, 07:38:17 am »
5. Several ways are implemented to achieve the same goal. For some critical or important actions several ways are usually implemented. If the first way fails, ReHIPS tries the second and so on. Fo example to get process name ReHIPS tries to find it in internal cache at first, then it tries to resolve it by process file handle and then it resorts to getting process name by process handle. I haven't seen both 1+2 fail, but it's nice to have a third option as a backup plan. Or for example when ReHIPS deletes a file, it makes several tries. Why? File system is a shared resource, a lot of processes may work with it. For example some antivirus may be inspecting the file right the moment we try to delete it and we fail. So it's always a good idea to double check these actions. We don't want to leave any trash files behind, we want to have a clean PC, right?

6. All critical resources are secured. ReHIPS itself uses a lot of internal resources for internal purposes. For example, it uses files to store databases, lots of communication channels for different components to interface with each other and so on. All these resources are properly secured. As definitely you don't want for example isolated programs to read database with other isolated users passwords or some isolated program to interface with driver and tell it to allow all programs. As corporate ReHIPS allows remote control, this also includes securing network channel which includes authentication and channel encryption. And even with these measures isolated users passwords aren't send over the network. Because Control Center doesn't need them and just in case.