I don’t think this is my first time writing about this, but it’s what’s on my mind these days.
Marching Orders for the CTO
More often than not, it seems to me, that a CTO will be driven by the business to get the application built, functionality enhanced, and availability maximized. Indirectly, sales are facilitated so the company can grow, and all this, come hell or high water, is what they will see done. Oh, and if, heaven forbid, a hacker can weasel their way in somehow, the crack in the wall will be quickly patched, and the miscreant will be rendered inert.
“What about insider threat?” you ask. Well, don’t we trust our staff? We vetted them when we hired them, and with all the interviews, we felt they were family material, right? You trust your family, right? What’s wrong with you?
To this oil, let us add some water (or vinegar, if you like) and look at the role of security in the organization.
Marching Orders for Security
Security is driven to ensure the confidentiality of data, identities, and intellectual property, uninterrupted availability of the application and the facilities to produce work, and verifiable integrity of all the above (among other things). Part and parcel with these are risk and vulnerability management. For the simplicity of this post, I’ll put them together as just ‘risks.’
Risks
These are risks to the application code, the development process, the libraries used by the developers, and the security awareness training offered to the developers.
These are risks to the underlying infrastructure and configuration, considering security patches to the servers hosting the infrastructure, serving the application, storing the application and customer data, and the availability of the infrastructure and application in the event of a disaster or critical incident.
These are risks to the devices used by the staff, the applications that can be installed, the choices available to the staff and where they can move data to/from, and the operating systems running on the machines.
These are risks to the physical facility, who has access to what spaces, who can access sensitive areas by themselves, the safety of the occupants in times of emergency and disaster, and what kind of digital evidence can be utilized in the event of suspected misbehavior.
There are risks to the reputation of the organization and the trust of the customers and potential customers. The organization must abide by regulating bodies and laws to do business in various environments or situations. Failure to meet these regulations and laws may incur penalties designed to prohibit the organization from continuing to do business, which is a considerable risk.
Compliance
To that last point (reputation, regulations, and laws), we have the giant ball of wax that is compliance. How do you know if you’re compliant with something? Well, identify all the requirements and then check against what you have or are doing. If you don’t have ‘it’ or are you aren’t doing ‘it’ you’re not compliant.
What drives compliance? Governance.
Governance
Governance is all the policy work. The policies drive everything done in security — addressing all the risks listed above and covering incident response, business continuity, disaster recovery, monitoring of All The Things, acceptable use, etc.
I like to think of Governance (and all of GRC) as the skeleton that supports the muscles and sinew of security.
The Friction
So the CTO is driven to produce and expand. Security is to make sure everything is….well….secure. Sometimes that means you have to take time to patch servers. You have to take time to go back and fix code. You have conduct security awareness training. You have to take time to answer customer questionnaires. You have to do all this, and NOT SLOW DOWN the product development and inhibit sales. I have been told, “we do not have the time to patch, we have a deadline to migrate the data from X to Y.” I’ve said, “if we are going to pass our audit coming up in a few months (compliance), we need to find the time.” Surprisingly, it was after this conversation that I found myself on the job market again.
To quote the brilliant Dawn-Marie Hutchison, why do we put brakes on cars? Most people instinctively think it’s to stop or slow down. While that is what happens when you use the brakes, you put brakes on a car so you can go faster. The faster you want to go, the better brakes you need. If you don’t have those brakes, you may not be able to control the car as much as you’d like if you encounter something unexpected on your way.
Security Is The Brakes
Holding to this metaphor, as a security leader, I could encase the axle in concrete and chain the vehicle to underground anchors, making sure the wheels would never turn. And in so doing, I have rendered the vehicle dead. That’s not how we do it.
In security, we need to create the guardrails and (try to) control as many of the variables as we can to ensure the business has everything it needs to move as fast as possible. I know this, I think we all know this.
So How Do We Do This?
How do we negotiate this with the CTO? How do we get them to balance the need for speed with the need for safety (security)? I’m sincerely asking, because clearly I’m not getting it right. When the CTO says, “We don’t have time,” how do we impress upon them the time must be found, if not now, then later? Technical debt is a real thing, and it demands attention. Data sprawl, access sprawl, and development sprawl (when the CEO says, “Look what AI can do! Everyone! Start using it however you want! It’ll make you faster!”) are all real things, and they become harder to address the longer they’re given free reign. How do you get the CTO to see this and give it the attention it calls for? Or am I just up in the night and we need to shut up and bide our time?
Honorable Mentions
While I’ve been writing this post, I’ve been thinking back on some of the superstars I’ve had the pleasure of working with. If you’ve read this far, I want you to check them out, as they deserve your attention, and you should do all you can to work with them.
- Jeremiah Talamentes (JT) is one of the best application/product security engineers I’ve ever worked with, and he’s a security leader of the highest caliber.
- Sean DePalma, and Cassandra Woodcox are two of the greatest GRC engineers I’ve ever worked with.
- Jackson Ronnow, Natasha Zeigler, Britney Juman, Hilary Finch, and Sarah Alaguratnam are among the finest Threat Hunters/SOC Analysts you’ll find.
0 thoughts on “How Do We Fix the CTO/Security Friction?”