When separate teams run application security and infrastructure security, attackers exploit the gap between them and you spend on the wrong risks. The technology has already merged the two domains, so what keeps them apart is now organizational, and closing that divide is where the work starts.
We need to expand our security toolbox beyond infrastructure to incorporate application security components. It’s difficult to bridge these disciplines in part because the people responsible for applications and infrastructure often reside in different groups. Also, the security skills related to developing and maintaining applications differ from those related to systems and networks.
Cloud-native architecture, infrastructure-as-code, and DevSecOps have since made the boundary harder to see, because the same code that provisions a server now ships alongside the application it supports. Bringing security into how software gets built is its own discipline, and it works best when security teams support the engineering teams rather than slow them down. Yet most organizations still split application security and infrastructure security across different teams.
Here are my recommendations for breaking down the walls between application and infrastructure security:
- Unify application and infrastructure security responsibilities under common leadership. If this is impractical in your organization, at least look for informal ways for the two teams to collaborate. Cloud and platform teams now own much of what used to be separate infrastructure, so a single owner keeps either team from assuming the other is handling a given risk.
- Include application and infrastructure components in your penetration testing projects. Attackers rarely stay on one side of the boundary, because someone who finds a flaw in your application can use it to reach the cloud account or network that runs it. Follow that path in your testing instead of stopping at the application’s edge.
- Include application logs as part of your log management or SIEM efforts. Incorporate security alerting and logging specs into your application development requirements to support this. Whether you rely on a SIEM or the extended detection and response tooling many teams now run, it can only spot attacks that cross both layers if it receives telemetry from each.
- Understand the role that your critical applications play in supporting business objectives. This may involve learning more about your organization’s business and will involve reaching out to non-techie business owners. Knowing which applications matter to the business also tells you which infrastructure matters most.
- Incorporate both application and infrastructure-related steps into your incident response plan. Many incidents now start with a vulnerable dependency or an exposed API in the application layer, and the attacker then pivots into the infrastructure, so your runbooks and responders need to handle both.
- Understand which application and infrastructure components affect the sensitive data that flows through your organization. This knowledge will help you understand security dependencies, so you know where to focus protective efforts. Your data now passes through third-party libraries, APIs, and managed services on both sides, so mapping the flow means accounting for components you didn’t build and don’t fully control.
Without somehow bringing infrastructure and application security disciplines together, you will probably spend more money on security than necessary or will focus your funding on the wrong risks. The tooling has started to converge, with cloud-native security products that combine application and infrastructure visibility in one place. The organizational walls are harder to remove, and that’s where this work has to start.
