IT Governance and Version Control: What You Need to Know
Version control is critical for addressing IT governance, risk, and compliance (GRC). Monitoring your change history and having proper documentation and tracking across versions allows you to:
- Keep your data safe
- Improve risk management
- Easily perform audits
Insufficient version control processes can create system failures and disrupt business operations. And mistakes have serious consequences. For instance, a developer could deploy the wrong version into production — or worse, into a hardware device. This could damage finances, reputations, or even lives and property.
Not to mention these processes can open the door for cyberattacks. Security breaches — resulting in stolen source code, data corruption, or ransomware — of course, come at a high cost.
Without proper versioning practices, companies can experience rippling financial impacts. Even in the absence of catastrophes, the direct cost in terms of lost productivity can be high. Also, there is a slightly less tangible cost to a company’s reputation due to unhappy customers. A delayed release or product recall could be too much for a company to overcome. As a result, it’s almost always less expensive to:
- Implement governance and compliance
- Set up appropriate security controls
- Embrace auditing
Beyond legal requirements, implementing GRC is a solid business requirement. Every organization can benefit from improving security and implementing auditing policies.
Better Risk Management With the Right VCS
The first step towards compliance is securing your VCS. For most version control systems, this means implementing firewalls. With a VCS deployed in a cloud — like Amazon Web Services (AWS) — you control access via security groups and access control lists (ACLs).
Firewalls and cloud settings are essential. The question is, can your VCS be made to enhance GRC and satisfy auditing requirements — and make life easier for your admins and business professionals?
All version control systems are not equal when it comes to addressing these needs. Some that are very popular with developers fall short on their ability to support these enterprise requirements.
Governance with Git
Git is one of the most popular systems for version control. Developers typically download product source code to their machines to modify it. But using Git means developers must download entire repositories with full history in order to get that source code. This may be a security concern for any company, especially if they are looking to audit and maintain compliance.
If you plan on using Git, the recommendation to improve auditability and compliance is to break up projects/products into many repos. Then you can assign permissions only to the repos containing the specific files developers are working on. This will make it easier to audit, but you will still have challenges achieving the transparency needed to satisfy all of an audit’s requirements. The cost of this approach is that cross repository dependencies make it harder to develop, manage, and build your systems.
Although Git is a distributed version control system (DVCS), you are going to need a central server to secure your intellectual property (IP). There is no magical way to secure everyone’s workstation effectively. Even implementing Machiavellian technologies — like making developers work on VDI (desktop virtualization) — will only go so far in minimizing your risk.
To secure build machines using Git for Continuous Integration/Continuous Delivery (CI/CD), you can set up firewalls or cloud-based security settings, like those described above. Those machines would logically sit next to the Git server. Their dedicated network access paths would need to be locked down. But setting all of this up and managing it in production, although necessary, can be time-consuming for administrators.
Setting Up Security to Improve Risk Management
A good way to approach VCS security is to study the concept of defense in depth. You are going to need to employ multiple layers of security controls throughout your network and systems. This provides redundancy in the event that a particular security control fails or a vulnerability is exploited. Security controls can be implemented on the personnel, procedural, technical, and physical level.
Helix Core— version control software from Perforce — gives administrators many granular ways to control access to code and non-code assets for compliance and governance. Let’s review some of the security layers you can set up with Helix Core.
Compliance Strategy for Organizing Intellectual Property Assets
In a large organization with many developers, you should establish appropriate naming conventions and hierarchy design across your code repositories. This yields one of the most productive and cost-saving benefits to large development organizations, especially if code is shared across teams.
Establishing a naming convention in Helix Core will help when deciding to restrict and/or grant permissions. Permissions can be refined down to the individual file level if required.
This has an impact on GRC because, as we know, not all code should be shared. It also helps with administrative overhead. Admins and security teams can easily see who has access to what assets and assign access to new users. If there is a problem or a mistake, they do not have to run around playing detective to see what created the issue.
Simplify metadata collection and naming conventions to help meet auditing needs. It improves your security and streamlines work for your admins.
Refining Helix Core Permissions and Policies
When implementing security policies, review who can access what in your VCS. Understanding what users can see and do helps determine what permissions are necessary. Using the principle of least privilege (PoLP), only grant access to the data and processes necessary for people and programs to complete their work.
There are a couple of ways to do this:
- Use transport layer security (TLS, the newer version of SSL) to secure communication over an internal/external network between servers, machines, and applications.
- Require users to be authenticated via AD/LDAP/MFA.
- Lock down version control servers to prevent internal tampering.
Helix Core can take your security a step further. The P4 protections table can help you refine access rights for users, groups, and programs. You can define permission levels by:
Define users access level such as list, read, write, admin, or super user.
User / Group
Define whether the permission applies to a single user, or a group of users (groups is recommended).
Define the specific TCP/IP address — either an individual IPv4 or IPv6 address, a range in CIDR notation, or use wildcards. This allows different permissions to be granted when accessing the server from the LAN or WAN, for example.
Define a folder tree or even specific file to which the access applies (powerful wildcards available).
Securing Your DevOps Pipeline for GRC
You can also secure your DevOps pipelines using Helix Core. When using Jenkins or other CI/CD automation tools, you should strictly control access to the build server. Make sure to regulate access between the build server and the version control system server. Isolating the servers helps ensure that intruders won’t get in. Just as important, it also prevents them from using those servers as a jumping off point to other resources.
When refining access for these programs/accounts:
- Ensure build machine accounts are non-login, which disables anyone else from logging into the account.
- Use multiple accounts for permission delegation, instead of just granting some programs “administrative access.”
- Control access and traffic using subnets. This isolates automated processes in a subnet so they won’t have access to the entire network.
- Check how often clients and programs connect and rotate TLS tickets on a regular basis.
Version Control For IT Governance and Compliance
See for yourself how Helix Core can help you with IT governance and compliance.