Else-net there was a discussion on how “security” is generally seen as a blocker; they’re seen as gate keepers and people who just say “no”, or who may be focused on regulatory compliance and not actual security.
Who needs Mordac, the Preventer Of Information Services when you have a security team?!
The thing is, “security” isn’t a monolith, and it’s not a one way street.
Many teams
I’ve only really seen security from a megacorp perspective, both from the companies I’ve worked for and the people from other companies I’ve spoken with over the years.
And there is no one security team in these situations; there’s a whole diverse group of teams; maybe all under the CISO, maybe not!
So there might be
- a team of risk managers (look at gaps, evaluating them, documenting risks, track remediation).
- a team for firewall governance (ensure there’s no free-for-all access in/out of the company)
- a team handling application security (enabling shift-left, if they’re good!)
- … handling email security
- … for encryption
- … for network security (honeypots, deception, packet flows, etc etc)
- … WAFs
- … Identity and Access Management
- … data loss protection
- … data discovery
- … SOC
- … Incident response
… and more.
Each company will have its own structure, of course. It’s not fixed in stone.
Regulatory compliance is really a small part of all of this, and may not even be under the CISO. In my opinion, a company focused on compliance isn’t a company that cares about security. They will be breached because they see it as a box ticking exercise.
Now some of those teams may run their own technology, others may use tools provided by the core technology area (e.g. firewall governance team may merely control the rulesets with the technology network team actually running the firewalls).
I work in security architecture. I’m a generalist. Part of that job is to ensure these security teams are doing things that further the security goals of the company and that all those teams aren’t duplicating efforts (‘cos strict delineation of areas isn’t really possible; there’s always overlap; e.g. email security team has a DLP requirement for outgoing email), and to provide consulting services (e.g. to the risk managers to help them understand the problems so they can provide better evaluations).
And, of course, in a megacorp for some teams are better than others.
Which leads to another part of my job; working with the business units (BUs) to assist them in building suitable solutions.
Over the years I’ve found there are two main types of BU teams; those that want to do the right thing, and those that just want to deploy as fast as possible and just see security as a hindrance.
The first kind I work well with; I can explain my logic, they can explain their solutions, we can work out what needs to be done to be secure (rather than just compliant). I rarely need to point at the standards and rules with these teams because they care. And we build good solutions together. We have a virtuous circle; they’re more willing to come to me early in their design cycle and we get better results, faster. A recent comment from BU team member was long the lines of “Thanks for the long and detailed response; that makes perfect sense, and I think I can see a solution path for our use case”. I’ve had an SVP from one of those teams call me the best security person he’s ever worked with. But this only works because they are willing to take that extra step.
The other type of team, though… they’re a problem. If it’s not in the standards they won’t do it. They push back because it might be hard, because it’ll cost money, because they just want to meet deadlines, because they’ve never been held to account before and they have over a decade of “do their own thing”. These teams I sometimes have had to rule by dictate. If they’re not willing to work with me to help define a better outcome then I have to be the blocker. This is a vicious circle, and one I dislike.
In some ways we can classify these teams as those following the spirit of the law (“we need to protect our data and systems”) vs those that follow the letter of the law (“we need to be compliant”). I so much prefer the first.
At the end of the day my goal is to help the BUs operate in a secure manner; I’m not here to block, I’m here to help. But I’m not able to force them to engage constructively; “tell me where in the standards I have to do this” is not conducive to a meaningful discussion. In the past I’ve joked that my job is saying “Don’t be stupid; don’t be stupid; I said don’t … oh God, you were stupid weren’t you?“.
Every mega corp will have both types of team. Fortunately the second type is getting less prevalent, as technology changes. For example, teams that are refactoring for cloud or for k8s or for automation tend to want to use modern CI/CD processes and want to do it correctly from the start.
Hide behind security
Sometimes teams blame security even when it’s nothing to do with us; it might be an easy way of punting work that’s hard, for example.
Or teams may interpret requirements in the worst way and assume there’s nothing they can do; “We can’t do FOO because the standard says BAR”. That’s even worse when that team provides services to other teams (e.g. central technology teams providing services to BUs) because the impact is magnified.
Security can also be the front man for other teams; rules and requirements can come from legal and compliance teams (who aren’t security). We get the blame for stuff because we’re the ones who have to implement it; “No you can’t record Zoom meetings because security said turn it off”; it was legal who said turn it off ‘cos Zoom recordings didn’t meet their records retention policies, we just had to implement it for them.
Security can end up getting the blame for things that aren’t our fault.
Summary
I tell people I don’t really care too much about compliance; good security practices (mostly) result in compliant solutions anyway! So I try to push for good security practices. Okay, I do keep some primary stuff in mind (e.g. PCI) but most of that is baseline bare minimum; you can be PCI compliant but not secure.
But I can’t do it alone.
Security can only collaborate with teams that want to collaborate. I need teams to work with me; a “help me help you” type scenario.
Maybe it’s not all my fault, after all!