maxkabakov - Fotolia
Help your developers create a better IT security model
Developers need to be comfortable with their tools to create a strong security model in an organization. Don't overlook these areas or credentials can end up in the wrong hands.
Developers play a major role in the IT management strategy of any organization, but because they represent an edge case, they're often responsible for the launch of new services within the framework. Developers are responsible for creating other services used by employees for a myriad of reasons and also create or rescind credentials for new and outgoing employees. This can create security problems within the organization with access to internal and cloud services.
Developers often take shortcuts to avoid these kinds of issues, such as password sharing or placing credentials on GitHub repositories they consider to be private but that end up being shared. However, leaked security credentials are quite commonplace on GitHub repositories and represent major security vulnerabilities for these organizations.
GitHub's Token Scanning can help introduce some safeguards to prevent leaked credentials, and other tools, such as Amazon's git-secrets, can help scan and identify shared tokens that can create security issues. Developers should explore these tooling options to create a more holistic IT security model for their organization and tie up loose ends that can create major issues for their enterprise.
Improve workflow security
Matt Creager, co-founder and vice president of developer relations at Manifold, a cloud service management platform, decided to reimagine the developer service provisioning process while he was at Heroku, a cloud application platform. He was troubled by how slow the provisioning process was for the cloud infrastructure he needed to develop, test and deploy new apps.
"There was never a holistic view of all the services the development team was dependent on, be it internal or external," he said. Managed services would be introduced to the team by different people, so it was never clear who was responsible for the configuration, billing or key provisioning for each service. When new developers joined the team, it was a manual process to track down exactly who could issue access to each service. If someone left or there was a need to rotate the keys, no one seemed certain of the effect on the surface area of the IT security model.
Matt CreagerCo-founder and vice president of developer relations, Manifold
Tools like Docker, Terraform and Kubernetes are powerful and have dramatically improved the efficiency with which internal services are provisioned and orchestrated, but they don't make it simple to connect third-party services. If you want an easy transition from start to finish, you must find one that fits your needs first before you register, provision and then manually inject its configuration into every part of your application that will depend on it. However, this isn't often the case.
"That's too much overhead," Creager said. He believes developers should be able to define the services their application depends on in one place using existing tools.
Other tools he worked with provide some of this functionality. For example, the AWS Identity and Access Management infrastructure and single sign-on solutions, like Okta and Centrify, can help centralize credential management. Systems such as Okta and Centrify require some work on the behalf of development teams to set up and configure to get started and require specific knowledge and dedicated resources to operate them.
One of the goals of Manifold was to provide better integration into the developer workflow in a way that eliminated the need to see the keys directly. As a result, developers don't need to worry about what they will need to operate an application for a specific environment or how it evolves over time because the correct services are exposed automatically. "With third-party managed services, you get portability; you can simply bring your same interfaces along with you to new infrastructure," Creager said.
Create an access control tier
Security and ease of use are usually, if not always, competing forces in an IT security model. As developers integrate additional services into the stack, it's typically most challenging to restrict access to these services based on necessity or a developer's role in the organization, said Anurag Goel, founder and CEO of Render, a cloud hosting platform.
A lot of developer-friendly services don't support fine-grained role-based access control (RBAC) yet, so Goel's team ends up with all-or-nothing access patterns, which considerably increase the attack surface.
Another big challenge for Render is the enforcement of multifactor authentication (MFA) across the organization. Many services have a team or organization management structure but don't have the ability for the tool's administrator to say, "I want every member of the organization to use time-based two-factor authentication for this service," Goel said. The same applies to service access logs, which are not always accessible in a self-serve manner.
Goel has also found that almost all services lack support for detection of and alerts on unusual access patterns at the organization level. Most services limit this to access alerts from new IP addresses.
One strategy to secure services that don't offer this feature is to restrict access with an internal RBAC layer for service credentials with a tool such as HashiCorp Vault, which is RBAC-compatible. However, this requires nontrivial engineering resources and increases the complexity of internal tooling.
Regular manual audits to enforce MFA can also help find security vulnerabilities, but like any manual process, this is time-consuming and error-prone.
Another strategy is to restrict external service access by IP and instead only allow corporate or VPN IP addresses. This strategy requires developers to install and maintain VPN connectivity, which isn't always available depending on the type of device being used. Also, this approach doesn't allow the use of services from untrusted networks -- such as coffee shops or other public locations -- which often block VPN connections.
Goel likes to use on-premises versions of third-party services wherever possible. This is obviously only limited to services that offer on-prem versions. These add considerable maintenance costs and infrastructure complexity to the IT security model.