A Change Request from a client (in the commercial sense of the word) to an organisation supplying an IT system to that client, can add or modify requirements for that system. Are there any known examples where the content of such a Change Request has been tampered with by a malicious third party and the additional or modified behaviour has been implemented in that system without knowledge or consent of the client?

For IT systems where security is a priority, is it necessary to authenticate such Change Requests, or is that just too paranoid?

  • 2
    Nice catch. Due to inherent laziness of IT workers, such requests will usually be met by procrastinating feedback, so the malicious scheme would have to be a bit more involved. – Deer Hunter Jun 13 '13 at 10:35

Usually Change Requests Workflows have well-defined steps, e.g.:

Plan: Implementor create the Change Request Ticket and fill it with the implementation details (scripts or whatever technical information is needed to fully implement the change)

Discussion and 1st level approval: A technical committee analyzes the proposed change and approve or request it to be re-planned. After this step is impossible to change the contents of the proposed change.

Final Approval: The pre-approved requests are send to a second committee, this time the customer is directly approving the proposed changes.

Implementation: The approved change is implemented and evidence is collected.

Revision and closure: The evidence of the change is reviewed and finally the change is closed.

This cycle would prevent someone tampering with a request due to several opportunities to spot it (either before and after the implementation)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.