Everybody within an organization needs to take a cyber security first approach to everything they do and every decision they make. Organizations have rolled out very basic cyber security awareness training that’s required pretty regularly, but I’ve found that the IT practitioner’s, the ones designing and building solutions for the enterprise, seem to still be generally lacking in intermediate and even basic security knowledge regarding security and threat mitigation.
We often see that in discussions amongst practitioners where ideas like basic authentication, API keys, SAS tokens are given credence, weakness introduced to overall security posture isn’t identified or known, and special security attention isn’t given to all facets of what’s being produced.
Often solutions will be designed that have cloud platform limitations requiring public endpoints to the cloud in order to use certain technology or patterns. Architects should know this going in and in such cases discuss viability with the security team, but sometimes they miss it or they misunderstand the security implications and it flies under the radar.
We’ll even see architects put together a solution with a complete and intentional disregard for security controls in order to meet a timeline. That’s bad.
Security teams have to provide gating here, but a poorly thought out solution that doesn’t take security seriously should never be presented to security teams to begin with.
It’s up to individual practitioners to seriously up their security game and it’s up to orgs to help incentivize this and maintain a higher baseline of overall security knowledge across its practitioners. Adding security engineers and security architects into cross functional teams may also help improve the baseline.
That being said, non-security team members shouldn’t be making authoritative decisions that affect security postering without consultation from security teams and security experts. There’s a different between having security knowledge and being a security expert (as we expect Security architects and security engineers to be). To be an effective practitioner absolutely requires building solid relationships and keeping open lines of communication with your security experts.
Program sponsors and project managers also need more awareness and to understand that “security” is an on-going activity. If a project has met all security requirements 5 years ago, it doesn’t mean they meet the security requirements today, and thus need to work that in to their timeline and cost projections.
“I thought security was done already?”.
—No, it’s never done. Did you budget for on-going security posturing? No? Why not?
You can certainly understand the perspective of different stakeholders who want to deliver and want some predictability of what’s required from a security perspective, and that can be done but alignment and expectations need to be set as early as possible, so that it can be incorporated into plans.
How long can organizations continue to operate on a model that requires security risk acceptance upon security risk acceptance because proper care and due diligence related to security wasn’t undertaken or budgeted for at the right moment?