Security: Getting to “Yes, Please!”

Watch Matthew Todd, principal consultant at Full Scope Consulting LLC, present his insights at the “Cybersecurity Insights: Security in the Digital Era” online event.

Matthew Todd, principal consultant, Full Scope Consulting LLC

For many years, I was the CISO of a public financial services company (with over $1 trillion in assets under contract and over 10 million individual users’ financial records). Not only was our business highly regulated, but our clients included some of the largest and similarly regulated US firms. That meant undergoing a lot of audits with companies whose auditors’ idea of a good time was spending weeks reviewing our security and risk management practices. At the same time, we had to fend off the usual litany of cyber threats, from phishing and denial of service attacks to potential insider threats.

As good as my team was at managing security threats and client demands, we still had to work with the rest of business. It took time, effort and innovations in security technology to become true partners.

The Department of “No”

Like most security departments, my team’s relationship with the rest of the business got off to a rough start. I know this was in no small part caused by the sheer difficulty of managing a secure environment. It seemed like everything was manual and hand-built. There were hardly any opportunities for automation, especially when resources were tight and good security tools were practically nonexistent.

Change was hard. Frankly, so much of our time was spent fighting fires at this stage that we hardly had time to think proactively about change. The only way we could ensure security was to limit access and operations to explicitly authorized activity, which meant that “no” was far too often the answer to a request for something new.

Thankfully, our “Department of No” was relatively short-lived—so, for most of the company, not around long enough to become a part of the culture. But that’s not the case for many organizations. New employees often bring their own experiences of serious “no” departments to new jobs.

I specifically remember one meeting with a relatively new product manager. It was the first time we sat down to discuss one of her projects. I had just approved it and happily offered to help her project succeed. She was shocked, and sheepishly told me that she’d been avoiding me, admitting, “I just knew you’d say no.”

The Department of “Yes, but…”

Only 10% of surveyed enterprises fall into the security trailblazer category.

Read the Forbes Insights 2019 State of Cybersecurity Report.

When a security team gets some room to breathe, it gets more opportunities to say “yes.”

As tools, technologies and techniques improved, my security team was better equipped to handle requests while maintaining a secure environment. This was the stage where we hired a third-party managed security service provider (MSSP) to help with routine things like log analysis and threat detection. Off-loading these kinds of mundane tasks gave my team and me time to work on some more proactive measures. Still, true automation was largely unavailable, and every new system or application had to be carefully assessed and secured—each in its own way.

At this stage, with the fires a little less frequent, I could say “yes” a lot more often to the business. But sometimes, regretfully, I had to add hefty caveats, such as limiting the requested access in some way or adding weeks to the project while the risks were analyzed and the necessary security controls built. I had overcome saying “no” all the time, but I hadn’t quite gotten to the point where the rest of the company was eager to engage with my team.

The Department of “Yes, and…”

We struggled in the “Yes, but…” stage with third-party applications and tools for in-house developers that rarely worked well together. Over time, the tools and technologies became more standardized, easier to integrate and more effective.

This gave my team and me the luxury of time—and more time meant we could be even more proactive:

  • My team began to work closely with the engineering team to develop secure coding standards that gave developers room to experiment while ensuring security requirements were met.
  • We took the time to thoroughly plan, document and test things like breach response, disaster recovery and legal holds.
  • I was able to analyze standards, regulations and privacy and breach laws, and come up with practical solutions that mitigated legal risks, while maximizing effective testing and experimentation for the rest of the business.
  • We looked for ways to remove annoying user technical barriers, like countless passwords and access methods to help employees be more productive.

Time-saving standardization and easier integration translated into a new reality. Now, when someone came to my team to request something new, we could say, “Sure! And not only that, but we’ll help.”

The Department of “Yes, Please!”

The biggest changes came about when true security and infrastructure automation came along. Enabled by virtual and cloud-based environments and concepts like Infrastructure as Code (IaC), this was the beginning of security engineering where security could be built into the bare metal (or virtual metal, anyway).

Cybersecurity Insights Online Event

Join top security leaders as they discuss how organizations can re-think their approach to cybersecurity to drive competitive advantage.

IaC and software configuration automation tools like Puppet, Chef and Ansible gave us the ability to create secure building blocks for developers and other teams to use. Powerful and flexible Identity and Access Management (IAM) products allowed for easy integration of new software and tools for all teams. This allowed us to centralize user access control and identification, which made everyone’s job a little easier.

With sophisticated and secure building blocks available, our security team could be truly proactive for teams like engineering and IT. They didn’t have to ask for something new. We could simply make the tools and infrastructure available with security built in. We became true partners to the engineering team, and SecOps engineers were part of the IT organization.

This was when I was really able to take advantage of the unique position a CISO can have. I could now analyze technical, operational and legal risk, and devise technical solutions that could help mitigate risks of all kinds while meeting the needs of the business.

For example, as a CISO, I was in an ideal position to interpret privacy law and formulate technical and operational policies and controls that met our privacy obligations. There are subtle differences between anonymization and pseudonymisation that the legal team won’t want to tackle, and the engineering team couldn’t be bothered with because it took time away from delivery. But as a CISO, I could work with counsel to understand the law, work with IT to mitigate the risk and still make sure we had “production-like data” for realistic application testing.

The Modern Security Team

No single CISO or security team will ever be just one of the “Departments” I’ve described. Even the best CISO will still occasionally need to say “no,” but should do so only with the most careful consideration. There’s almost always room for “yes,” and a good CISO will be able to come up with creative solutions that move the business forward.

Increasingly available tools, techniques and technologies are allowing CISOs and security teams to be better enablers and enhancers of the business. IaC lets us provide basic building blocks to engineering teams that ensure the security and reliability of operations. Machine learning promises to greatly improve our ability to identify and react to threats, further liberating security teams everywhere to mitigate real business risks, well beyond the traditional data security threats of yesteryear.

So what’s your answer going to be when the business comes calling?