There is a widening gap between IT and engineering approaches to security, and bridging this gap is crucial for more thorough protection of our systems and infrastructures. To understand this gap, we should first define the security engineering mindset and the IT security mindset. Caution, there may be some broad generalizations made here.

Security engineer mindset IT security mindset
Expertise and experience usually in software development Expertise and experience usually in technology infrastructure build, deploy and manage (data centers, network)
Mindset is to build it and automate it Mindset is to buy it, staff it, operationalize it.
DevSecOps shift left mentality drives building security principles into the front-end of design, versus having to re-engineer and fix it later Security management platforms protect the business-critical applications and systems

When examining the disconnect between IT and security teams, there are several critical areas to consider:

  • The differing mindsets of IT and security regarding infrastructure and implementations.
  • The gap between purchasing security tools and effectively implementing them.
  • Engineering strategies to enable faster recovery.
  • The often-overlooked importance of runbooks.

Aligning IT and Security Mindsets: Infrastructure and Implementations

The disparity between IT and security mindsets can be narrowed by adopting an engineering “shift-left” approach. A key step is fostering a feedback loop between the two teams. IT should not be seen solely as the executor of security plans. Instead, security teams should integrate IT’s KPIs and goals into their own frameworks, developing shared metrics to measure mutual success. A critical evolution here is moving from “alert on everything” to a more refined “alert and act” strategy. Excessive, low-fidelity alerts overwhelm operations teams, leading to alert fatigue and eventual disregard. Transitioning to high-fidelity alerts focused on high-impact triggers improves efficiency and collaboration across teams.

Finding the sweet spot between security and IT also means aligning security approaches to the business, with consideration of customer requirements, both internal and external customers. Coming from the lens of IT, oftentimes security will implement a solution and lock down IT’s ability to perform its daily responsibility. A recent example is locking down local admin access to user end points, which inhibits IT resources the ability to change network settings or update device drivers. Both areas are critical for an IT admin to perform their jobs. There is a wide spectrum of security enablement, from NSA/government type of lock down all the way to practically no security controls and leaving the doors wide open. Security and IT should collaborate to find the appropriate middle ground for implementing a security posture which protects the company and its customers, while also taking the business requirements into consideration.

The Gap Between Buying and Implementing Security

Simply purchasing security tools does not equate to effective protection. Without proper implementation, configuration and management, even the most advanced tools are rendered ineffective. Aligning the security tool’s configurations to the goals of the security policies and governance programs is required to know the security tool is serving its purpose. Moreover, it’s essential to test these tools as a potential adversary would, ensuring they function as intended under real-world conditions. To close this gap, organizations should:

  • Modernize Application Engineering: Development practices must support network segmentation technologies and align with security principles. Tools such as web application firewalls (WAFs) are only effective when integrated into the development lifecycle.
  • Adopt an Offensive Security Mindset: After implementing controls, conduct penetration testing or other offensive security evaluations to identify vulnerabilities. This approach helps ensure that security measures are not merely obstacles that attackers can easily bypass.

Engineering for Faster Recovery

Recovery strategies must benefit from an engineering-first mindset, emphasizing simplicity and resilience. As a case study, solutions like CrowdStrike or Microsoft demonstrate how security tools impact IT’s ability to recover effectively. In the context of the CIA triad (Confidentiality, Integrity, Availability), security teams often focus on confidentiality and integrity, leaving availability to IT. However, when a security tool like CrowdStrike fails, it directly affects availability, making recovery an IT responsibility. Adding automation to the engineering approach helps maintain quality and better scalability of management of recovery efforts.

Over-engineered solutions often complicate recovery efforts, creating unnecessary delays and challenges. The goal should be to design streamlined systems that are easy to maintain and restore in the event of a failure.

The Critical Role of Runbooks

Runbooks are a foundational yet frequently overlooked component of recovery and response. They should be actionable, regularly tested, and updated to address edge cases and Black Swan events. While “unprecedented times” have become a cliché, the reality is that unforeseen scenarios are increasingly common.

Testing runbooks against extreme edge cases and simulating real-world attacks strengthens both IT and security teams’ preparedness. By adopting a hacker mindset, organizations can better anticipate and respond to threats, building a stronger bridge between IT and security priorities.

Building a Unified Approach

Bridging the gap between IT’s practical, implementation-driven approach and security’s design-focused strategies is crucial for developing robust security systems. Collaboration, shared metrics, and an emphasis on testing and simplicity can transform how organizations align IT and security goals, ultimately delivering more effective and resilient security outcomes.