Skip to content
Alex DowJan 29, 20206 min read

One of the Biggest Cyber Risks to the Public Sector is Not What You Think

The public sector is under constant cyber attack. Most are treasure troves of (our) data, running essential and sometimes critical services and are generally struggling to keep up with the ever evolving threat landscape. A week doesn’t go by without a public sector organization suffering a ransomware attack or discovering thousands of their/our records stolen by cyber criminals.

And those are just the breaches that were detected.

While I could pontificate on the usual: the public sector needs more technology, more staff, more training and obviously, more budget. That would just be contributing to the echo chamber. Instead, I want to hone in on something much more sinister, that is plaguing the public sector and threatening their services and our data: the RFP procurement process.

 

Why are RFPs a Cyber Risk?

I have spent literally days and weeks responding to Requests for Proposals (RFP) over the course of my career. When I worked at a large organization, I somewhat enjoyed telling my story and vision of how my team would solve the stakeholders’ problems. And arguably RFPs suit a purpose: define requirements up front, get a good grasp on market offerings and understand the supplier’s vision of success. However, there is a difference between private and public sector RFP processes and I believe the latter is inhibiting the public sector’s ability to manage cyber risk and in fact increasing it! Let’s dive in.

 

Agility

Public sector RFPs are typically issued in a reactive manner to address a past, near-miss or current “situation”. From the point the cyber risk stakeholder(s) identify a need, it usually takes a couple of months to aggregate secondary, tertiary and beyond stakeholder requirements before finalizing RFP documentation and soliciting responses. The tender period is typically another couple months, followed by at least a month of assessing responses before awarding the contract. From identification of need to authorization to procure, we are talking 5-6 months!

Considering that the cyber threat landscape changes approximately every 6-12 months, these processes are essentially crippling the public sector to ever be able to respond to cyber threats and appropriately defend themselves.

 

Good, Fast, Cheap: Choose One?

RFPs usually have a scoring system which includes methodology, the execution team and various other requirements. However, more often than not, the pricing of the proposal is heavily weighted. This is understandable considering public sector is using public funds and needs to be accountable of their spending. However, there is a risk in having too much weight on price.

First and foremost, the large RFP responders have intimate knowledge of the public sector’s pricing thresholds and set their offerings accordingly. RFPs are typically won by these large companies who “figure out” resourcing and execution after award. This typically results in under scoped and under resourced projects with failure close behind. (See Federal Government projects like ETI and Phoenix.)

Secondly, while the RFP will have a list of experts and thought leaders ready to solve your cyber risk management problems, you are not likely to see them after the RFP response or initial kick off meetings. This bait and switch tactic is overly common by the larger firms, especially when price is a determining factor.

 

Good Talent Likely Won’t Respond

Large system integrators (SI) respond to RFPs. They have RFP response teams and seasoned accounts people who have developed “a home field advantage” through their years of working with the public sector’s procurement processes. System integrators typically do not specialize in cyber security but rather in selling the dream, selling the boxes and finding the experts to implement, post award. More often than not, those experts are not employees of the SI but rather, independents and sub-contractors.

On the other hand, boutique consultancies such as Mirai Security, are where the true cyber security talent resides. We run lean/mean teams, typically with one or less sales staff and most of the time do not have the bandwidth to compete against a seasoned SI with a potentially stacked deck. In fact, there is a growing movement within the boutique consultancy space to just not respond to RFPs all together. And this is not because we do not want to help solve the public sector’s cyber risk problems, but rather we are already well fed with clients who are not hindered by arduous procurement processes.

 

Informing The Enemy

Lastly, while discussing this RFP with Mirai Security’s Sandy Buchanan, he pointed out another great concern: information disclosure. More often than not an RFP will contain a lot of details about the project and environment. As an example: a simple RFP for security testing can be filled with details on physical locations, the technology stack, stakeholders, known gaps and much more. All juicy tidbits for an attacker to plan their next attack.

In addition, RFPs usually have a period where potential bidders can ask questions back to the stakeholders. This is an excellent wolf in sheep’s clothing problem where the attacker can pose as an interested party and socially engineer more sensitive information through the Q&A process. Are procurement officers trained to prevent these risks?

 

Is There a Fix?

Gary Perkins, CISO of the Province of British Columbia and the Don Quixote of cyber security in the public sector has nobly set out to raise the cyber security water level. I’ve coined Gary as the Don Quixote with the utmost respect; I believe his quest is noble and altruistic, however it will be fraught with challenges, apathy and resistance.

As the story goes, Gary set out to improve cyber security in the public sector and identified three problems:

  • Public sector was stuck using the complex and arduous tool of RFP to procure small tactical security support which was creating huge delays in results

  • Boutique consultancies were excluded from pre-existing supplier agreements resulting in the public sector’s inaccessibility to the true cyber security talent

  • Lack of competition keeps prices high

In an effort to fix what I like to call “procurementitus”, Gary established the “Corporate Supply Agreement” or CSA. This procurement vehicle was intended to enable two things:

  • Level the playing field and invite boutique consultancies to the party

  • Eliminate the need to go to RFP for small/non-complex projects and procurements

So, did Gary Quixote save the day? Well, the CSA has been in existence for about two years now. It has been feverishly campaigned to public sector stakeholders as a tool to help expedite cyber security relief. And… Regrettably it does not seem to be moving the security needle much at all due to two problems:

  • Many cyber risk owners and buyers still are not aware of the CSA and how it can speed up getting much needed cyber security help

  • Procurement teams don’t like procurement tools that make themselves obsolete and have discouraged the use of the CSA

The lack of uptake in the CSA program may result in it being shut down. This will force the public sector back to the arduous process of RFPs, resulting in latency in solving the cyber problems and higher costs. I put this article together hoping it will be shared with the public sector’s cyber risk stakeholders as a last ditch effort to increase awareness of the CSA and enable easier access to cyber security help.

However, as I am writing this I am now questioning “am I the Don Quixote of cyber security”?

 

Conclusion

RFPs have their purpose, especially for large scale, high-risk and complex projects. However, I stand firm that I believe they are a death sentence for organizations that need cyber security help now, not in 6 months. The public sector has been plagued by “procurementitus” which has clearly resulted in the stagnation of cyber security maturity across the public sector and consequential security breaches.

RFPs were meant to manage risk, not increase it.

COMMENTS

RELATED ARTICLES