2

In the "people, process and technology" security model popularized by Bruce Schneier - link

It is discussed how exploits/attacks can occur on any of these 3 broad levels.

For exploiting technology, that is relatively common. Pentests, exploiting bugs, etc.

For exploiting people, we see that via phishing, social engineering, etc. (there is some element of exploitation using technology involved)

In processes however, I am not sure how these are exploited.

My questions are thus:

  1. What does a "process" mean? Is it referring to some set of rules (like an algorithm) that people/technology follow?

  2. Theoretically, how would a process be exploited? (any theoretical example will do)

  3. Has a process ever been exploited in reality? If so, what was it and how was the process exploited?

alf3nso
  • 21
  • 1
  • I think you may be giving too much to technology. I think process talks about logical, protocol/logical errors (ie the infamous KRACK) vs technology being incorrect handling of security procedures (ie leaving RDP open on the default port with a weak password). If this seems correct to you let me know and I'll throw it in an answer but I'm not 100% familiar with this design. – Allison Oct 31 '17 at 02:19

1 Answers1

2

A process can refer to any set of policies or procedures you follow. It could be algorithmic, or it could simply be documented policies or procedures that have loopholes or flaws. That is, even if the people involved are doing their jobs to the letter, and the technology is doing what it is expected and supposed to, the process can be abused or exploited.

To give a simple example, say a company has a help desk ticketing system that is used to request permission and privileges. It's a common occurrence for additional information to be needed on the ticket, so users can edit tickets they've created, and you can only create a ticket as a logged in user. The process is as follows:

  1. A user creates a ticket, indicating what codebase or server they need access to.
  2. Someone from the security team checks that the requesting user is supposed to have those permissions, and adds a comment to the ticket or changes the ticket state to indicate it's approved
  3. Someone from the IT department processes the ticket, adding the appropriate permissions.

On paper, that might seem superficially secure, as long as people are doing their jobs (e.g. adding the right user to the right permission set) and the technology/ticketing system are secure.

But what if you come in as a user who is supposed to have permission to edit the help documentation, and after that gets approved in step 2, you edit the ticket to instead say you need permission to access source code that you aren't supposed to have access to, or a production database containing sensitive information, etc? The IT department user in step 3 may look at the ticket, look at the approval, and you now have permissions you aren't actually supposed to have.

What you have is a failure of process, because the official/documented policy doesn't take into account the ability to edit tickets. You might fix the policy by not allowing ticket edits after approval, or by requiring the IT user in Step 3 to look at an edit history of the ticket - but as documented and followed, the process is fundamentally insecure.

To explain how that ties into the blog post you linked - technology and automation could clean up the loophole in the procedure itself. Maybe when security approves it, they directly tie the ticket into the repository that you're supposed to have permission to, and it's forwarded to the IT department as a new ticket, or automated entirely. That removes both one of the human factors for error (IT admin misreading a safe and unedited ticket, or selecting the wrong username), and the process loophole (no verification between steps 2 and 3).

Chris
  • 81
  • 2