One of the most frequent cybersecurity binary thinking curses is that just because senior leadership in organizations won’t do every single thing the security team wants then that must mean leadership obviously doesn't care about security. The reality is, of course, more nuanced. I’ve never seen any organization, irrespective of sector, geography or scale where leadership literally doesn’t care about security. Even if they don’t assert security being a priority in terms the security team may use they do assert the importance in other ways. This can be in terms of availability, privacy, reliability, trust and other goals that are core to serving their customers, running their business or supporting their mission.
In reality any disconnect between senior leadership and the wider security team is more complex and typically associated with what might be described as: tone at the top and buzz at the bottom vs. muddle in the middle. We talk a lot about the importance of the "tone at the top". This is normally manifested in how much senior leadership (and the Board) assert security as a priority and for most organizations this is often good. There is also often great "buzz at the bottom", that is a great sense throughout the organization among newer employees that security is important and interesting to solve for. There is often a sense of pride in defending the organization and its customers or users. However, where things can often go wrong is what might be described as “muddle in the middle” at various layers of management that have to prioritize and drive security enhancements. To be clear, this is not a criticism of the people in those positions and this is not a unique issue to security. Various management roles have significant and parallel priorities from revenue growth, business / product enhancements, wider risk and compliance objectives, expansion, business structural changes, efficiency drives and so on. Sometimes these priorities can be in conflict or there may simply not be enough resources: people, money or time to do them all, including the necessary security. Often the job of the security team is to apply prioritization pressure at these layers through metrics/transparency, top down sponsorship of efforts and significant ongoing escalation. Many security teams get good at this and often do it with great support from the various management layers. But the truly great security teams also use additional tactics to get things done. Let’s take a look at some.
1. Timing of Control Improvements
How the security team selects the right moment to drive some control improvements can make a big difference. Aligning improvements as other work is happening or at other times when the organization is more naturally receptive to prioritize the upgrade is key. For example:
Incidents. When an incident, near-miss, or incident at a peer organization has occurred, then people are ripe to prioritize upgrades. These are usually times when risk tolerances are reexamined and when previously lower priority efforts can be pushed forward.
Upgrades. When other upgrades are happening or when systems are being reengineered is a good opportunity to address security issues. This can be simply taking advantage of doing work while “the hood is open” or it can be to better align security controls with the other objectives of the change. Taking advantage of these moments requires the security team to be close to or intertwined with the organization's planning process. This is another reason why it is often very useful to have the security team be a full part of the IT/Engineering organization.
Process Reengineering. Similarly when business processes are being adjusted there is an opportunity to improve a variety of end to end controls not just those in the underlying technology implementation. Here is where strong partnership with business line operating risk, compliance or other teams involved in other risk mitigation activities is crucial since there may be common controls to mitigate multiple risks.
Customer / Employee Experience Changes. A subset of process reengineering, but one worth highlighting, is to seize any opportunity where customer or user experiences are being adjusted. In a lot of organizations the limiting factor for security enhancements are real (or perceived) impacts to customer experience (employee experience and productivity impact is a significant matter as well). If such an experience is being reimagined then that is a great time to address necessary improvements around issues like authentication strength, anomaly detection, delegated authorization and credential resets.
2. New Builds
All of the above applies even more so in new business projects, new products or new application/infrastructure. Working on such efforts from the beginning is an opportunity to get security built in correctly. It is important to feed security into the project's requirements so that such features are appropriately prioritized vs. having a whole separate set of requirements that might be outside of the business units own tracking process.
3. Shaping Economy of Effort (Perception and Reality)
Another reason it is important to drive security enhancements when changes or new builds are occurring anyway is that often adding X (e.g. 5%) of work to something that is already funded is easier to process than budgeting 10X to do the security uplift on its own. This is largely because a lot of the cost and effort of security is the “start-up” cost of getting the environment ready to be changed or upgraded regardless of whether it’s a security change.
4. Creating Frameworks and Seeking Process Integration
One of the prime goals of the security team is to make the secure path the easier path for all employees. This is especially true for development teams. Creating frameworks, APIs, or tooling to mitigate whole classes of attacks not only will have an outsize effect in reducing security risk but also saves effort and improves developer productivity. The creation of such centrally maintained frameworks gives an ongoing point of leverage for more economic future improvements. Similarly, seek the right places to integrate security into business and technology processes so that it slipstreams with them.
5. Joint Goals and Unified Controls
It is useful to team up with peer risk and control teams (including compliance and audit) to use work they might be driving to find common controls to jointly mitigate risks. For example, it might be a compliance or audit goal to introduce some business process separation of duties for various reasons. This might entail enhancing overall privilege management tooling and processes. It might be that security has already flagged such issues and unifying effort will mean all the teams' goals can be achieved in a more systematic way, ultimately reducing the burden on those businesses and employees.
6. Control Upgrade Approach
At some point, though, the needed security upgrade might be so pervasive or so important that it has to happen and cannot wait to be slipstreamed into other activities. For enterprise wide improvements it is important to plan for either a breadth first or depth first deployment.
The chart above shows we can think of controls as needing breadth (pervasiveness of deployment) and/or depth (stringency and maturity of control) yielding 4 combinations:
Low breadth / low depth: controls that are being piloted or tested or are not significant and only need a narrow deployment.
High breadth / low depth: get basic control needs covered quickly across the enterprise before maturing the control to be progressively more effective.
Low breadth / high depth: cover a specific risk or sophisticatedly targeted exposure against a specific asset really well more quickly.
High breadth / high depth: ideal state especially when high depth is commoditized (raise the baseline by reducing the cost of control).
In reality you’ll likely never want to go from Low/Low to High/High directly, simply because it will take too long (e.g. a highly stringent control deployed everywhere will need a lot of testing and development) or it will be operationally risky. You therefore need to decide what reasons you would take the Low/Low to Low/High (depth first) or High/Low path (breadth first).
Bottom line: senior leadership do care about security but you might have to slipstream the needed improvements into other activities as they are happening. Be conscious of the wider organization pressures and look for opportunities, align with commercial goals and speak the language of business impact not technical countermeasures. In other words, senior leadership absolutely do care but you have to keep the engagement threshold low enough to translate care to action. This can be done by the security team being engaged in the wider organization’s work and using new projects and enhancements as opportunities for improvement. This requires a degree of forward planning, a lot of hustle and a large element of organizational scrappiness to achieve.
コメント