Audio version of the article
Restrictions must be placed on access to the program’s source code. Access to program source code and associated items (such as designs, specifications, verification plans and validation plans) should be strictly controlled. There should be strong controls on who has access to program source code and related materials (such as designs, specifications, verification plans, and validation plans). If a program’s source code is not appropriately safeguarded, an attacker has a strong opportunity to gain access to the system in a covert manner. This is especially true if the source code is critical to the company’s success. Program source code can be vulnerable to attack if not adequately protected and can provide an attacker with a good means to compromise systems in an often covert manner. If the source code is central to the business success it’s loss can also destroy the business value quickly too.
Control
Read and write access to source code, development tools and software libraries should be appropriately managed.
Purpose
To prevent the introduction of unauthorized functionality, avoid unintentional or malicious changes and to maintain the confidentiality of valuable intellectual property.
ISO 27002 Implementation Guidance
Access to source code and associated items (such as designs, specifications, verification plans and validation plans) and development tools (e.g. compilers, builders, integration tools, test platforms and environments) should be strictly controlled. For source code, this can be achieved by controlling central storage of such code, preferably in source code management system. Read access and write access to source code can differ based on the personnel’s role. For example, read access to source code can be broadly provided inside the organization, but write access to source code is only made available to privileged personnel or designated owners. Where code components are used by several developers within an organization, read access to a centralized code repository should be implemented. Furthermore, if open-source code or third-party code components are used inside an organization, read access to such external code repositories can be broadly provided. However, write access should still be restricted. The following guidelines should be considered to control access to program source libraries in order to reduce the potential for corruption of computer programs:
- managing the access to program source code and the program source libraries according to established procedures;
- granting read and write access to source code based on business needs and managed to address risks of alteration or misuse and according to established procedures;
- updating of source code and associated items and granting of access to source code in accordance with change control procedures and only performing it after appropriate authorization has been received;
- not granting developers direct access to the source code repository, but through developer tools that control activities and authorizations on the source code;
- holding program listings in a secure environment, where read and write access should be appropriately managed and assigned;
- maintaining an audit log of all accesses and of all changes to source code.
If the program source code is intended to be published, additional controls to provide assurance on its integrity (e.g. digital signature) should be considered.
Other information
If access to source code is not properly controlled, source code can be modified or some data in the development environment (e.g. copies of production data, configuration details) can be retrieved by unauthorized persons.
Organizations must confirm that there is appropriate segregation of duties between the staff responsible for moving a program into production and the staff responsible for developing a program. In addition, organizations must consider whether or not changes are performed in a segregated and controlled environment. To fulfill this requirement, administrators must ensure that logins to source code repositories and the permissions assigned to these users are appropriate for the tasks that they are allowed to perform. Users with overlapping permission sets should indicate a compromise in the segregation of duties control consideration. Administrators should also review the process to request and grant access to systems and data and confirm that the same person does not perform these functions.To prevent the introduction of unauthorized functionality and to avoid unintended changes, and to maintain the confidentiality of valuable intellectual property, it is necessary to strictly control access to source code and related items (such as designs, specifications, verification plans, and validation plans). For program source code, this can be achieved by controlling the central storage of such code, preferably in program source libraries. In order to minimize the potential for misuse of computer applications, the following guidelines will then be considered to control access to these source libraries:
- Where appropriate, software source libraries should not be kept in operating systems;
- The source code of the program and the source library of the program should be administered according to procedures;
- Support staff should have restricted access to program source libraries;
- The updating of program source libraries and related objects, and therefore the issuing of software sources to programmers, should be carried out only after sufficient authorization has been received;
- The program listings should be stored in a safe environment;
- The audit log of all accesses to program source libraries should be maintained;
- Strict change control procedures may refer to the management and copying of software source libraries.
A source code management system that allows organisations to centrally administer access to and their amendment of source code across its ICT estate. It asks organisations to consider access to source code along a set of strict read and/or write privileges, based on the nature of the source code, where it’s being accessed from, and who is accessing it. When seeking to control access to source code, organisations should:
- Control access to source code in line with published procedures.
- Provide read and/or write access to source code in conjunction with a set of clearly defined business requirements on a case-by-case or user-by-user basis.
- Adhere to a clear set of change management procedures when administering access to source code, including proper authorization based on a range of access variables (user type, business case etc).
- Prevent the direct access of source code by developers, and instead provision access through a series of development tools that provide a top-down view of access rights and read/write privileges.
- Provision a secure space to store program listings and read/write privileges.
- Maintain a concurrent audit trail of all source code related activities, including user access timestamps and change-related activities.
- Ensure that digital signatures are used for any piece of code that is to be published outside of the organisation.
Securing Source Code
1. Create a source code protection policy
Set up a source code protection policy by defining a set of rules, requirements, and procedures for handling and protecting code. This policy will help safeguard software and devices from threats such as reverse engineering and code tampering. It should also cover source code development processes and personnel involved in code development. Include secure access and use of source code repositories. Your source code protection policy should also involve documentation and training on secure coding practices and the incorporation of secure development methodologies into the software development lifecycle (SDLC).
2. Prevent the use of insecure source code
Use source code security analysis tools, such as Static Application Security Testing (SAST), to detect security flaws and other issues during development.
3. Access control
Define who’s allowed to access source code, code base and source code repositories. There’s little to no reason that anyone other than hands-on employees work with your source code, but even for those that do, set up two-factor authentication. In this way, you can ensure that no suspicious characters find their way into your source code. Through authentication and authorization, access control policies ensure that users are who they say they are and that they have appropriate access to company data.
4. Use encryption and monitoring
Make sure you have the ability to encrypt sensitive data both in transit and at rest. It’s also important to monitor your data at all times and be alerted when any suspicious activity comes to light. In this way, you can be ready to act swiftly, whether it is about tracking, limiting, or reversing the damage. You can also prevent it before any actual harm happens.
4. Deploy network security tools
Implementing network security solutions such as firewalls, Virtual Private Networks (VPN), anti-virus, and anti-malware software count as basic protection. These solutions safeguard your source code from external exploits of hackers and ensure secure data sharing between employees and data sources.
5. Don’t forget about endpoint security
Secure your endpoints or entry points of end-user devices such as desktops and laptops from risky activities and malicious attacks with endpoint security software. Data Loss Prevention (DLP) solutions can efficiently prevent your source code from leaving the endpoint and stop source code ex filtration. These tools can protect sensitive information both in physical and virtual environments, regardless of the endpoint’s physical location and whether it’s connected to the internet or not.
7 Pay attention to patents & copyright
Make sure that all your concepts and inventions related to software are protected by copyright law and necessary patents. A major difference between these two is that while patents protect the idea, copyright safeguards the written code. As software-related inventions are increasingly popular, you should treat this proprietary information just like other intellectual property.