One of the biggest responsibilities of any Software/IT Department is to develop the product with a high level of security technology for the consumers and ensure that the product data is properly protected. The examples of the consumer’s products can be open/closed source software products like e.g Microsoft Office, WordPress, Drupal, Magento, SFTP Cerberus, etc.
The software security technology can be an end to end cryptography, two-level authentications, or can be any third-party tools.
The Risk of breaches in software product security is very real and the effects can be crippling to a consumer’s business. Many Software/IT departments tend to direct their focus and attention toward external threats such as hackers. However, more and more companies are realizing that internal sources, such as software developers, testers or code reviewers, may present the biggest security risks to the company.
To manage the above risk, it can be solved in two ways:
a) Segregation of Duties with the addition to new security positions in software product development who directly reports to the CISO of the Company.
b) The independent third-party security software product reviewers that can get into the details of the product code and communications to look for the malicious code set by the internal product developers.
After applying both or just one of the steps may produce a lot of business security in terms of availability. (Legal liabilities may take the company out of the business)
The whole idea is to license the product code version that it’s been reviewed by the Security specialist and/or the independent third party product security company and it’s been cleared from the malicious code.
It will protect both the consumers and the software product company by providing some sense of security to the software product consumers that the specific product is validated and it’s safe to use them.
The following list is about the backdoors created by internal employees for the well-know Software companies. Some of the links include the companies that tended to get into the consumer’s data to collect the required information for illegal financial gains.
The Joomla Backdoor:
WordPress isn’t the only major CMS that’s experienced backdoor issues with plug-ins. Joomla installations have been victimized similarly — for instance, via a free plug-in the code for which was modified after the fact. Such sneak attacks are generally performed as a means for getting back into a website that’s been hacked, as few think twice about checking whether a CMS plug-in was the point of entry of an attack.
https://blog.sucuri.net/2015/11/exif-php-joomla-backdoor.html
The Borland Interbase backdoor:
This one’s guaranteed to raise hairs. From 1994 through 2001, Borland (later Inprise) Interbase Versions 4.0 through 6.0 had a hard-coded backdoor put there by Borland’s engineers. The backdoor could be accessed over a network connection (port 3050), and once a user logged in with it, he could take full control over all Interbase databases. The kicker, and a sign of strange programmer humor at work, was the credentials that were used to open the backdoor. Username: politically. Password: correct
https://www.infoworld.com/article/2606776/hacking/155947-Biggest-baddest-boldest-software-backdoors-of-all-time.html#slide8
The Linux backdoor:
Back in 2003, someone attempted to insert a subtle backdoor into the source code for the Linux kernel. The code was written to give no outward sign of a backdoor and was added to the Linux source by someone who broke into the server where the code was hosted. Two lines of code were changed — and might have breezed past most eyes. Theoretically, the change could have allowed an attacker to give specific, flagged process root privileges on a machine. Fortunately, the backdoor was found and yanked when an automatic code audit detected the change. Speculation still abounds about who might have been responsible. Perhaps a certain three-letter agency that asked Linus Torvalds to add backdoors to Linux might know.
https://www.infoworld.com/article/2606776/hacking/155947-Biggest-baddest-boldest-software-backdoors-of-all-time.html#slide9
Backdoor in your hardware:
Having a backdoor in your hardware product is bad enough; promising to fix it, but only covering up its existence is even worse. That’s what happened at the end of 2013 with several DSL gateways that used hardware made by Sercomm, all of which sported a manufacturer-added backdoor on port 32764. A patch was later released in April 2014 to fix the problem, but the “fix” only concealed access to the port until a specially crafted packet (“port knock”) was sent to reveal it. We’re still waiting for a real fix.
https://www.infoworld.com/article/2606776/hacking/155947-Biggest-baddest-boldest-software-backdoors-of-all-time.html#slide11
NSA TAO Backdoor:
Never let it be said that the NSA doesn’t have some clever tricks up its sleeve. Recent revelations about its TAO (Tailored Access Operations) program show that one of the NSA’s tricks involves intercepting hardware slated for delivery overseas, adding backdoors to the device’s firmware, and sending the bugged hardware on its merry way. Aside from network gear, the NSA also apparently planted surveillance software in the firmware for various PCs and even in PC peripherals like hard drives.
https://www.infoworld.com/article/2606776/hacking/155947-Biggest-baddest-boldest-software-backdoors-of-all-time.html#slide12
Another NSA Backdoor:
Yet another from the NSA, perhaps the sneakiest yet: a deliberate, stealthy weakening of a random number generator commonly used in cryptography. Theoretically, messages encrypted with the Dual_EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generator) standard, ratified by NIST, had a subtle weakness that could allow them to be decrypted by an attacker. Only after Edward Snowden leaked internal NSA memos did it come to light that said the agency had manipulated the approval process for the standard to allow the backdoor to remain in the algorithm. Fortunately, plenty of other random number generators exist, and NIST has since withdrawn its recommendations for Dual_EC_DRBG. Small wonder people speculate what else the NSA may have hidden up its (and other peoples’) sleeves.
https://www.infoworld.com/article/2606776/hacking/155947-Biggest-baddest-boldest-software-backdoors-of-all-time.html#slide13
The ProFTPD Backdoor:
ProFTPD, a widely-used open source FTP server, nearly had a backdoor planted in it as well. Back in 2010, attackers gained access to the source code hosting server and added code that allowed an attacker to spawn a root shell by sending the command HELP ACIDBITCHEZ. Irony abounded in this case: The attackers used a zero-day exploit in ProFTPD itself to break into the site and plant the malicious code!
https://www.infoworld.com/article/2606776/hacking/155947-Biggest-baddest-boldest-software-backdoors-of-all-time.html#slide7
What kind of employee does this?
Qing Hu, an Iowa State University professor and chair of the logistics, operations, and management information systems department, began researching at Florida Atlantic University in 2003 to better understand the human factors that should be considered in security initiatives. What he found was that many times companies were having security problems not because they didn’t have sophisticated technology to protect their information, but because employees were not following procedures, or the company had a few bad apples eager to gain access to confidential documents for personal financial gain.
Hu recently set out with colleagues in the United States, China, and Finland to try to identify what induces employees to commit internal fraud or restrains them from doing so. The study surveyed approximately 200 employees to find out what personality and psychological profiles would make people likely to commit an act of internal abuse.
Each participant was first asked personality questions, then asked to pretend during three scenarios: Would you look up payroll data to negotiate a better salary, steal a commercial secret and sell it, or help a friend in the company by accessing restricted information? The participants were each given varying levels of potential punishment if they were caught, and then asked if they would partake in each of the acts of internal misconduct. Then, Hu said, the responses were associated with the personalities to build the personality profile of someone likely to answer he or she would commit the act.
The results were quite surprising to the researchers.
Up to that point, the philosophy of management was to deter employees from committing internal fraud through punishment.
“But what we found in this study is that it is not the punishment that deters people, it is how attractive or how benefiting it is if I conduct a breach,” Hu said. “So it is a positive motivation, not the negative deterrent, that most likely induces people to commit security fraud.”
The study showed Hu that two personality traits characterize people who overestimate the benefits of conducting computer fraud: low moral beliefs and low self-control.
“We know of some people that have real strong self-control, which means they don’t do things impulsively, they don’t take the risk without careful calculations,” Hu said. “And there are types of people that have very low self-control, and will decide without much thinking.”
Low self-control, Hu said, coupled with low moral beliefs makes someone more likely to commit fraud because they are less likely to even consider the punishment that serves as a deterrent to someone who does consider the risks.
“So that tells me that punishment does not solve the problem,” Hu said. “And if you just have strong policies that say we are going to fire you or send you for a criminal prosecution, then that will not solve the problem.”
What is Risk in terms of Information Technology?
There are many definitions in the world for the risk but according to the ISACA, the Risk is a possibility of occurrence of the event, which will have an undesirable effect on a given organization and its information systems.
In the terms of IT systems security, the risk of IT systems is an overall measure of probability and seriousness of the situation, in which a given threat uses specific weakness, causing loss or damage of system assets, therefore an indirect or direct loss for the organization.
Risks can come from various sources including uncertainty in financial markets, threats from project failures (at any phase in design, development, production, or sustainment life-cycles), legal liabilities, credit risk, accidents, natural causes and disasters, deliberate attack from an adversary, or events of uncertain or unpredictable root-cause. There are two types of events i.e. negative events can be classified as risks while positive events are classified as opportunities.
IT risk is the threat that Information Technology applied in a given organization
− Does not fulfill business requirements,
− Does not ensure appropriate integrity, security, and availability,
− Was not appropriately implemented and does not work according to assumptions.
What is Risk Management?
Risk management is the identification, evaluation, and prioritization of risks (defined in ISO 31000 as the effect of uncertainty on objectives) followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of opportunities.
What are the Risks to the software company from product consumers?
1) Creates Trust issues on the product and affects the reputation of the organization.
2) It can put the organization legally accountable for consumer data loss and Financial loss.
How to stop the silent code hack threats from the product developers within the organization?
IT security governance is the system by which an organization directs and controls IT security.
IT security governance should not be confused with IT security management.
IT security management is concerned with making decisions to mitigate risks; governance determines who is authorized to make decisions.
Governance specifies the accountability framework and provides oversight to ensure that risks are adequately mitigated, while management ensures that controls are implemented to mitigate risks.
Management recommends security strategies. Governance ensures that security strategies are aligned with business objectives and consistent with regulations.
Separation/Segregation of Duties SoD or Separation of power is the concept of having more than one person is required to complete the task.
In the Business separation of Duties and to maintain internal control is done by sharing the single task process into more than one person to avoid error and fraud.
Separation of Duties is commonly used in a large organization to prevent unauthorized access and unauthorized activities by any object (Can be machine or human). Role-based Access control is been frequently used in a large organization to control employee access by providing them access level where they can perform their duties.
Below is the example of the IT company/ Software Department that has Strict internal control of software and data changes that will require the following roles to commit the software changes to production:
1) Identification of a requirement (or change request); e.g. a business person requested a change in software to the IT Company.
2) Authorization and approval; e.g. an IT governance board or manager will make sure that the request is coming from the right business person and the request is legitimate.
3) Design and development; e.g. a developer will make sure that the request has been made by his manager and will start work on the task.
4) Code Review, inspection, and approval; e.g. another developer or architect will review the developer code and authorizes that this code will work and it’s correct.
5) Software Security Reviewer: This position will determine that the product doesn’t have any malicious code or any back door.
5) Implementation in production; typically, a software change or system administrator.
6) Software project Test: Smoke test by Manager/Team Lead to make sure the requirements of the customer have been met as requested and its function on the production.
7) There should be timely validation of the production code each day/week to make sure the code never changed since it was moved to the production.
This is not an exhaustive presentation of the software development life cycle, but a list of critical development functions applicable to the separation of duties plus an addition to the development with a security layer.
Above was just an example of the separation of duties with the security layer that we can set during the SDLC.
All the above steps of SDLC repeat if any change requests approved on the software.
The Role of an IT Security Governance will be, to assign a role-specific access level to each phase of SDLC.
e.g. Developer should have access to the code, not the Production server files.
and as an IT Security Management point of view, there should be an audit or review process on each phase before the input goes into the next phase.
e.g. Developer finishes his task of developing a feature of the software and his Team lead reviews the code and makes sure the code has required functionality.
Then the Development manager makes sure that the timelines are met and the request was implemented as it was requested.
Governance specifies the accountability framework and provides oversight to ensure that risks are adequately mitigated, while management ensures that controls are implemented to mitigate risks.
The solution will be combinations following risk management tools:
Risk Transference:
Recommending a Third-party audit of the product code and go through the code changes product lifecycle. After the product, code review issues a license.
No Code will go to the production environment without the license that has been issued by the Third-party Software product audit company.
After the code has been released the production code has been validated that it is the same as the licensed code.
This will bind the third party liable for any backdoors that have remained in the software product.
Risk Mitigation:
By applying governance controls or Risk Transfer will automatically reduce the risk from the internal team and it will also help to identify the fraudulent employees in advance that have or have plans to do a fraudulent activity. The research paper is focusing on a very unique area that has been never thought of like a big potential risk. The whole idea is how to protect product consumers from fraud and to Mitigate the Risk for software product company from unwanted malicious code by there own team and providing a couple of ways to the organization to transfer the risk or/and setting up a governance with addition to the security layer in the Software development team of the Organization.