CISO strategies for overcoming weak organizational trust

Organizations have a CISO in place to set the risk tolerance tone for the firm. CISOs are responsible for protecting terabytes of sensitive data. They strategize the organization’s technical risk management within the overarching business objectives. They manage the risks that come with internal software assets and third-party vendors. They ensure that operations follow regulatory standards, and do it all with a shrinking budget. No pressure, right?

So, why are so many CISOs met with weak organizational trust? Here are five reasons why this is often the case and strategies to re-gain trust as a highly effective security leader.

Reason #1: Your security policies aren’t sticking internally.

Being proactive about security while keeping up with lofty organizational goals can be tough. There’s no denying that. It’s common to feel like board members and business leaders resist careful control implementations. It’s also common for employees throughout the organization to ignore or avoid policies for the sake of convenience.

Here’s how to turn things around.

Both employees and executives need to understand that controls are in place for a reason. The ability to circumvent them shouldn’t be an option. Allowing a business unit to jeopardize the rest of the organization is reckless. When it comes to security, business units don’t own the risk—the entire organization does. Security controls aren’t optional—they’re critical.

As CISO, your role is to educate stakeholders and employees about the risks affecting the portfolio. Communicate the importance by unifying the risk items and placing them in the context of external business drivers. This sets the bar for security. It also means that you need to understand the priorities and collective risks of each business unit. Based on the goals and risks, identify the types of malicious actors that could compromise your applications and underlying systems.

Reason #2: You’re out of sync with other operations.

The applications that a customer or regulator asks to test may not present the highest risk to business objectives such as profitability, user base, or brand equity. The biggest risks—in terms of impact—are actually the applications built before your firm had secure coding standards. And yet, your focus and spending involve web or mobile apps currently in development.

Perhaps you feel like you’re brought into the assessment process too late. This is the case if every assessment feels like a fire drill to your team. Once the assessment finally starts you don’t yet have a working environment, people in place for interviews, or credentials. Even when you establish an assessment schedule, you’re still not meeting deadlines and SLAs.

Here’s how to turn things around.

Be proactive about your critical assets and risk priorities. Your focus is on critical assets of today, but it’s still important to work through tomorrow’s threats. While you’re extinguishing a $10,000 fire, you may be neglecting a hazard that could lead to a $1,000,000,000 blaze.

Stay in sync with other operations by creating a testing policy and stick to it. If you strategize a testing schedule around a release, build, or new feature, ensure that you meet with product and development groups to understand their roadmaps and upcoming deadlines. Build the test schedule around these deadlines. Business objectives are critical. However, running out of time for security isn’t a realistic option for reasonable risk management. If you can’t test something before it goes into production, test it once it’s live. It’s better to fix an issue late than never.

If testing revolves around a timeline, publish a clear schedule based on all applications in your power. This keeps the testing schedule transparent to other teams within the organization. Also publish the testing prerequisites, inputs, and outputs. Engage with the development population and each of your CIOs. Invest time in educating these groups on your testing process. Don’t rely on the statistics from a tool to convey a real risk management message. Ensure that stakeholders understand the business case for frictionless partnership between development and security.

Reason #3: You aren’t risk ranking or prioritizing effectively.

A risk-based strategy is an effective way to deal with application security across your application portfolio. Perhaps you have a comprehensive application inventory and an inventory of your data at different classification levels across the organization. However, you aren’t risk ranking your high, medium, and low-risk applications. How do you know where to invest your team’s time if these aren’t established?

Similarly, do you find yourself arguing with your penetration testing vendor about the severity rating of each issue? Are you providing a reason and process to adjust the findings from all your assessment methods and tools to ensure that they are unified against an objective rule set for criticality? If not, something needs to change.

Here’s how to turn things around.

It’s time to make smarter risk-based testing decisions. One highly effective approach is to risk rank your entire portfolio with an objective questionnaire. First and foremost, maintain visibility in your portfolio. Have a process in place to track the status for your applications. A portal, for example, is a highly preferable resource to tracks where your applications are and what their status is in the project. There should be a dedicated team member to track the status within each application project.

If you don’t have an inventory, make that your top priority. Once you have your list of applications, you know who is using them, what exposure they have, the type of data they handle, and any additional aspects of importance to your organization, it’s time to translate the answers to these objective questions into a risk score that you can then use to effectively rank your portfolio.

With your newly ranked inventory, define or update your software security methodology to apply security activities throughout the SDLC. The frequency and depth of each activity should be explicitly tied to risk. For example, low-risk applications may only get automated testing, while high-risk applications get a deeper manual review over several weeks.

Reason #4: You’re having budget troubles.

Perhaps you weren’t able to get the budget approved to conduct all the great projects you proposed. No budget. No progress. No security. This isn’t all that unusual, believe it or not. But, wait. You were clear about budgetary needs. After all, accountability still falls to you. You included all the specifics like static analysis tool licenses and penetration testing needs in your budget proposal. You were clear that your team needs these things to better secure internal applications and compliance requirements. Still, critical budgetary items weren’t approved.

Are you waiting for an audit finding to fix specific issues in your organization, because that is the only way to get funding and support for what needs to be done? Or, perhaps a breach completely annihilates your original budgeting goals and now you’re now scrambling to figure out how to undo the damage, where else you might be at risk, and how to prevent another.

Here’s how to turn things around.

You need to manage the risk in internal applications to protect your business. To do that, it’s critical that you clearly communicate the actual cost of securing your applications, and the potential consequences of not securing them, so that stakeholders can make educated, beneficial budgetary decisions.

Frame risk management and risk appetite in the context of your business objectives. The board and/or CEO probably isn’t all that concerned with why you need to buy static analysis tool licenses. They may better understand the need to conduct penetration testing for compliance, but “we need to do this” isn’t a compelling enough reason for them to blindly sign off on your budget requests.

If you wait for customers or regulators to ask you for something specific, you can remind your board that they are firmly committed to doing the bare minimum for security for their company to stay afloat. If they are comfortable with this level of risk tolerance, then you might be OK. If you carry this message to them clearly and consistently and they continue to insist they are dedicated, remind them that regulatory compliance only makes up a small percentage of their portfolio.

When stakeholders claim that “security is important to us,” ask why that’s the case and to what level. Whether you make or buy applications, they need to serve a business purpose, and so should their security strategy. This is the heart and soul of your argument to have a suitable budget approved.

Reason # 5: You’re riding the wave.

You claim that you “do” something as a company. In reality, perhaps you hire one person to do that thing, or you only have a few individual team members responsible for that thing left to their expertise and experience. Others on your team may even follow the leader, but that individual or team is thriving on tribal knowledge. If anyone gets sick or quits, you’re stuck until you can hire another purple unicorn.

If this is the case, your process is weak, at best. Perhaps you see that but haven’t gotten around to resolving it. This can be true for penetration testing, code review, architecture analysis, creation of secure components, training, etc. Putting a body in a seat is a weak strategy. You can do better.

Here’s how to turn things around.

Define a process so you don’t put yourself in this position in the first place. Write down an actual process for each of your security activities that includes a formal definition of what goes in and what comes out. If you need to adopt someone else’s process, do it. But, any two people doing the same activity should come to mostly the same conclusion and output so that you can actually scale these efforts across your portfolio.

Summing it all up.

You can continue to be ineffective and get no trust or empowerment from your organization. You can keep pushing the blame to uncooperative development teams, recalcitrant business units, or even clueless stakeholders. Or, you can set the tone for risk management for your organization and take the time to translate stakeholder business objectives into tangible, actionable risk management. This could be a presentation to the board or executives that clearly spells out exactly what needs to be done, with a very clear business justification explaining why.

Avoid the common misstep of the absence of a basic attack modeling capability. Consider what your top attackers might be like, what assets they might be after, what their likely path of entry would be, and which software they may compromise along the way. If you’ve let other people dictate your biggest risks based on their needs, you’re not managing risk, you’re simply a firefighter fielding incoming calls for one-off tactical challenges.

Instead, be on top of your risk so that when you solve your tactical risk challenges, you know exactly where they fit into the bigger picture.

Transform your risk management strategy.