Reflection and connection Assignment
Running head: Security Concept 1
Security Concept
Security Concept
Gaurav Venkatesh
Over the last 3 weeks, I have had a chance to look into the different aspects of Operation security and the one security concept that resonated with me from the class was the Separation of Duties. Separation of duties is an internal security control that essentially breaks down one task into multiple sub-tasks and then assigns the task to different departments and ensuring that more than one individual is required to complete a task. At first glance, it may sound like we are creating unnecessary choke points in the organization by requiring many people to complete a single task and that a task that requires one person requires three. However, the trade-off for this efficacy is security. Also if only one individual can make a task happen, he can easily be blackmailed or threatened to perform an action from either an internal or external source. At the financial organization that I work as a Software developer at, the Separation of duties is a well-versed subject and constantly put in practice. There have been multiple situations where I was frustrated that I need approvals from different departments including Quality Assurance (QA), User Acceptance Testing (UAT) and finally change approval board(CAB) in order to get my code change into production. However, it is vital to understand that any change that is introduced must be vetted before going into an environment with which users interact. As a developer, I only unit test the happy path of my code, i.e, if the code produces the desired effect of the requirements. The QA and UAT departments ensure that the change in introducing doesn’t break any other part of the application. They also check if there are security vulnerabilities, any cached cookie that could be exploited, or any SQL injection that could be introduced. The CAB ensures that my change doesn’t affect another team and also that other teams are aware of the change and are unphased by my change. More importantly it is an essential yet simple fraud deterrent control. A rogue employee can single-handedly create a backdoor or loophole in the application and exploit it as he wants to; situations like this can easily be avoided as the QA team would find this issue and prohibit the code from going to production.
It also is a good way to stop any accidental errors as it would get reviewed by more than one department in order to reach completion. As a developer if I make a mistake while development and my code accidentally takes an input and doesn’t add the right number of decimals to an amount field, and if a customer attempts to send $500.00 to another customer but the application sends $50,000 instead, it would be a devastating loss for my organization.
As I would like to move into a security position in the financial organization that I work at, I would like to enforce a larger breakdown of tasks as I see a lot of potential issues that can happen with the creation of ACH(Automated clearing house) files that essentially goes through FED to move money between one financial institute and another. By introducing separation of duties, we are ensuring that there are checks and balances in place that would avoid any team from abusing their power. At a physical level, Separation of duties can also protect against the deletion of live data, subsequent backup data, and most importantly access logs that would indicate who caused the issue in the first place. On a logical level, it can protect your credentials, access and authorization to different objects in your network. Separation of duties can also gain protection against malicious ransomware/crypto-locker attacks and prevent operator errors and sabotage attempts. Overall Separation of duties is a compliance measure that should not be taken for granted.
References:
Separation of Duties. (n.d.). Retrieved from https://www.b4restore.com/it-security-and-compliance/separation-of-duties