Integrating a Security-First Approach into Your Team
April 5th, 2021
by Aphinya Dechalert
It’s easy to let your security standards slip, especially when deadlines are looming and your team becomes pressed for time. However, what many teams don’t realize is that security is an ongoing task. It’s not a once-off implementation that we can just set and forget about.
When it comes to security, we often think about the code and the data. We implement checks, filters, rules, and various backstops to prevent data leakages. In reality, there’s more to it than just the code.
Integrating a security-first approach is something that many technical teams can overlook because it is not always directly related to the code. Sometimes, it can sit on the infrastructure level, dealing with resource accessibility and permissions into different digital assets such as code repos. Here are four overlooked security vulnerabilities and how to solve them for your team.
1. Unprotected Git Branches
Many of us use Git to manage our code repository. For smaller teams, it is easy to have everything in a single repo. On the surface, it makes sense – having a single repo means less work trying to keep multiple repos up to date, prevent syncing issues, and potentially stop the code from becoming out of step from each other.
However, having a single repo also proves to be a security risk. While different versions and developers working on the code can be separated through branches, there is a lot of trust that team members don’t accidentally merge and push to the wrong branch.
I once worked on a project where the master production branch was accessible to all developers – juniors and new members of the team included. This meant that untested features and unmoderated code could easily be pushed into production. Why? Because there were no protections against such actions in place.
An easy and quick solution to this is to put ‘locks’ on specific and important branches such as production and pre-production branches. While there is no way to do it directly in Git itself, code hosting repositories like GitHub and Azure Repos have blocks you can implement through permissions and rules.
In GitHub, this ability is called “Branch Protection Rules.” In Azure Repos, it is called “Branch Policies.” For both providers, this functionality can be found under the settings option. From here, you can set accessibility and code reviewers to check the validity of the merge request before it is added to the branch.
2. Admin Credentials for Cloud Services
Sometimes developers also play the role of the infrastructure person. This can occur in spaces like startups where developers are often also DevOps by organizational design. While the cloud has its benefits, like the ability to provide infrastructure as a service, it also comes with a high level of risk.
When booting up new services from your console, security keys are required to access the infrastructure resources. Sometimes it can be a hassle to give permissions to every possible and required service to a developer because of how interlinked booting up one service is to the rest of the cloud ecosystem.
For example, if you wanted to create a new EC2 instance on AWS, you might also need access to CloudWatch services, databases, connected Lambdas, logs, and IAM roles. It gets murkier if you have other services running and you want to connect them. For many, it’s easy to default to the admin role so that a developer can have free reign over it.
However, if the developer is not versed in security protocols, they can easily make the key accessible to outsiders of the organization. It can be as easy as accidentally pushing the access keys to a public repo or sharing it in spaces they are not supposed to. In this kind of scenario, the security risk is a human one. While it sounds far fetched, it has happened before.
The first step to preventing this from occurring is to ensure that the developer understands the extent of his accessibility powers. Education and frequent security reminders are the only way to increase personal awareness.
The second step is to put alerts in place for suspicious activity. Suspicious activity can be based on resource size and quantity against the account type. This can be done through external services such as Cisco’s AppDynamics and BMC TrueSight Pulse. Having a third-party monitoring tool means that you are not completely reliant on one platform to deliver your alerts and logs. It also means that if something did happen, the third-party monitoring and alert system remained independent from the attacked account.
3. Default Passwords and Document Sharing
Managing passwords and document sharing can be a pain, especially when it comes to security. When you head into an organization where security is a priority, you will find that there is no such thing as a default password and minimal communal document sharing.
It’s easy to pass around important information through email chains and Google Docs. However, it is not the most secure methodology. I’ve seen teams put everything into a document and share it with their team members. Then links get shared where permissions are hazy and it’s hard to track who has access to what. Over time, these sharing links find their way outside of the organization such as third-party developers, consultants, and even collaborators who are not working directly on the project. When this happens, you are relying solely on trust to remain secure.
A good practice is to ensure that everyone has their own access account, where a clear admin has control and a birds-eye view over accessibility at all times. Access keys should be unique and assigned to only one individual. This prevents the human layer from leaking security access and can be traced to the source if it does occur. If passwords need to be set, it should be done in confidence and by the person who is using them. Sometimes, the admin sets a default password that doesn’t get changed until a security breach has occurred.
If documents do need to be created, they should not contain any sensitive data. Revoking access should be done immediately if someone leaves a team, and a clean-up of accessibility should occur when this happens.
4. Undocumented Procedures and Unclear Hierarchies
In order to have a security-first approach, your team needs to have a clear understanding of the procedures and hierarchies. For small teams, this can feel like overkill. However, it doesn’t have to be a complicated document.
Rather, the procedures should be a living document that can be actively followed and enforced. This means that things such as security access and code merge procedures are clear to everyone on the team. While it’s easy to set procedures at the beginning of the project or when forming a new team, implementing it can reveal issues with the processes.
When this occurs, rather than making exceptions, the procedures should be reviewed instead. This allows your security processes to evolve with your team’s changing needs, keeping it relevant while ensuring that your security awareness and requirements are still valid. This includes having a clear hierarchy of accessibility and access grants.
Undocumented procedures may seem much more flexible in the beginning, but as teams grow and change, this knowledge can be easily lost through time or personnel changes. Externalizing your procedures ensures that everyone is under the same expectations and understanding when it comes to security protocols and how to perform them in conjunction with their day-to-day tasks.
Having a security-first approach is about more than just the code. It’s also about educating the people behind the code and making sure that they are aware of the powers and risks they wield as developers. It is also about looking at security risks from every angle and setting up the required procedures to standardized the expected outcome and prevent security risks before they happen.
It’s easy to let a private key slip into a repo that it is not supposed to or accidentally share accessibility because it is unmonitored. At the code level, it can be as easy as protecting your branches to prevent accidental merges. At the infrastructure level, it can be as simple as keeping third-party watches on your resources and actively reviewing accessibility keys.
On the human level, it is more about bringing awareness and actioning educational sessions to ensure that everyone remains updated with what is expected from them.
Aphinya Dechalert / About Author